Cluster Anthos di VMware kini menjadi Google Distributed Cloud (khusus software) untuk VMware. Untuk mengetahui informasi selengkapnya, lihat ringkasan produk.

Halaman ini diterjemahkan oleh Cloud Translation API.

Memigrasikan cluster pengguna ke Controlplane V2

Dokumen ini menunjukkan cara memigrasikan cluster pengguna versi 1.29 atau yang lebih baru menggunakan {i>kubeception <i}ke {i> Controlplane V2<i}.

1.30: GA
1.29: Pratinjau
1.28: Tidak tersedia

Tentang bidang kontrol cluster pengguna

Sebelum menggunakan Google Distributed Cloud versi 1.13, bidang kontrol untuk cluster pengguna berjalan pada satu atau beberapa {i> node<i} di cluster admin. Bidang kontrol semacam ini yang disebut sebagai {i>kubeception<i}. Pada versi 1.13, Controlplane V2 diperkenalkan untuk klaster pengguna baru. Jika Controlplane V2 diaktifkan, bidang kontrol untuk cluster pengguna akan berjalan di cluster pengguna itu sendiri.

Manfaat Controlplane V2 mencakup hal berikut:

Isolasi kegagalan. Kegagalan cluster admin tidak memengaruhi cluster pengguna.
Pemisahan operasional. Upgrade cluster admin tidak menyebabkan periode nonaktif untuk cluster pengguna.
Pemisahan deployment. Anda dapat menempatkan cluster admin dan pengguna domain gagal atau situs geografis. Misalnya, sebuah cluster pengguna di lokasi edge dapat berada di situs geografis yang berbeda dari admin .

Persyaratan

Untuk memigrasikan cluster pengguna ke Controlplane V2, cluster pengguna harus memenuhi persyaratan berikut:

Cluster pengguna harus versi 1.29 atau yang lebih tinggi. Cluster admin dan kumpulan node dapat memiliki satu atau dua versi minor lebih rendah dari cluster pengguna. Jika yang diperlukan, upgrade cluster.
Cluster pengguna harus memiliki Pesawat Data V2 mengaktifkan pembuatan versi. Kolom ini tidak dapat diubah, jadi jika Dataplane V2 tidak diaktifkan pada , Anda tidak dapat memigrasikannya ke Controlplane V2.
Cluster pengguna harus dikonfigurasi untuk menggunakan MetalLB atau manual dengan load balancer Jaringan Passthrough Eksternal Regional. Jika cluster pengguna menggunakan load balancer SeeSaw, Anda dapat memigrasikannya ke MetalLB.
Ulas Dokumen perencanaan alamat IP, dan pastikan Anda menyediakan alamat IP yang cukup untuk pengguna node bidang kontrol cluster. Node bidang kontrol memerlukan alamat IP statis, dan Anda akan memerlukan alamat IP tambahan untuk IP virtual (VIP) bidang kontrol baru.
Cluster pengguna harus menonaktifkan enkripsi secret yang selalu aktif, yaitu, bagian enkripsi secret kosong, atau secretsEncryption.generatedKey.disabled ditetapkan ke true. Jika tidak, Anda dapat menonaktifkan fitur ini dan mengaktifkannya kembali setelah migrasi selesai.

Memperbarui file konfigurasi cluster pengguna

Buat perubahan berikut pada file konfigurasi cluster pengguna yang ada:

Setel enableControlplaneV2 ke true.
Jika ingin, buat bidang kontrol untuk cluster pengguna Controlplane V2 sangat tersedia (HA). Untuk beralih dari cluster non-HA ke cluster HA, ubah masterNode.replicas dari 1 hingga 3.
Menambahkan alamat IP statis (atau alamat) untuk bidang kontrol cluster pengguna node ke network.controlPlaneIPBlock.ips bagian.
Isi netmask dan {i>gateway<i} pada network.controlPlaneIPBlock bagian.
Jika bagian network.hostConfig kosong, isi.
Jika cluster pengguna menggunakan load balancing manual, konfigurasikan load balancer Anda seperti yang dijelaskan di bagian berikutnya.
Jika cluster pengguna menggunakan load balancing manual, tetapkan loadBalancer.manualLB.controlPlaneNodePort dan loadBalancer.manualLB.konnectivityServerNodePort ke 0 karena tidak diperlukan saat Controlplane V2 diaktifkan.
Ubah loadBalancer.vips.controlPlaneVIP dengan alamat IP baru untuk VIP bidang kontrol. Perhatikan bahwa perintah itu harus berada di VLAN yang sama dengan IP node bidang kontrol.
Semua kolom sebelumnya tidak dapat diubah, kecuali saat mengupdate cluster untuk migrasi. Pastikan untuk memeriksa kembali semua setelan.
Jalankan gkectl diagnose cluster, dan memperbaiki masalah apa pun yang ditemukan perintah itu.
```
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --cluster-name=USER_CLUSTER_NAME
```
Ganti kode berikut:
- ADMIN_CLUSTER_KUBECONFIG: jalur admin file kubeconfig cluster.
- CLUSTER_NAME: nama cluster pengguna.

Menyesuaikan konfigurasi load balancer manual

Jika cluster pengguna Anda menggunakan load balancing manual, lakukan langkah-langkah di bagian ini. Jika tidak, lewati bagian ini.

Serupa dengan mengonfigurasi load balancer untuk cluster pengguna CPv2, untuk setiap dari tiga alamat IP node kontrol-platform baru yang Anda tentukan di bagian network.controlPlaneIPBlock, konfigurasikan pemetaan di load balancer Anda:

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)

Mengupdate cluster

Jalankan perintah berikut untuk memigrasikan cluster ke Controlplane V2:

gkectl update cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Ganti kode berikut:

ADMIN_CLUSTER_KUBECONFIG: jalur cluster admin {i>kubeconfig<i}.
USER_CLUSTER_CONFIG: jalur cluster pengguna file konfigurasi Anda.

Perintah tersebut melakukan hal berikut:

Buat bidang kontrol cluster baru dengan ControlPlane V2 diaktifkan.
Hentikan bidang kontrol Kubernetes dari cluster kubeception.
Ambil snapshot etcd dari cluster kubeception.
Matikan node bidang kontrol cluster pengguna dari cluster kubeception. Perhatikan bahwa demi pemulihan kegagalan, yaitu kembali ke cluster kubeception, node tidak akan dihapus hingga migrasi selesai.
Pulihkan data cluster di bidang kontrol baru dengan snapshot etcd yang disebutkan di atas.
Hubungkan node kumpulan node pada cluster kubeception ke bidang kontrol baru, yang dapat diakses dengan controlPlaneVIP baru.
Rekonsiliasi cluster pengguna yang dipulihkan untuk memenuhi status akhir cluster dengan ControlPlane V2 yang diaktifkan.

Catatan

Selama migrasi, tidak ada periode nonaktif untuk workload cluster pengguna.
Selama migrasi, akan ada beberapa periode nonaktif untuk bidang kontrol cluster pengguna. Lebih spesifiknya, bidang kontrol tidak tersedia antara langkah 2 dan penyelesaian langkah 6. (Periode nonaktif kurang dari 7 menit berdasarkan pengujian kami, tetapi durasi sebenarnya bergantung pada infrastruktur Anda).
Di akhir migrasi, node bidang kontrol cluster pengguna dari cluster kubeception akan dihapus. Jika cluster admin memiliki network.ipMode.type yang disetel ke "statis", Anda dapat mendaur ulang beberapa IP statis yang tidak digunakan dengan menghapusnya dari file konfigurasi cluster admin dan menjalankan gkectl update admin. Anda dapat membuat daftar node cluster admin objek dengan kubectl get nodes -o wide untuk melihat IP yang sedang digunakan.