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 admin ke ketersediaan tinggi (HA)

Dokumen ini menunjukkan cara bermigrasi ke cluster admin dengan ketersediaan tinggi (HA) dari cluster admin non-HA.

1.30: GA
1.29: Pratinjau
1.28: Tidak tersedia

Cluster admin non-HA memiliki satu node bidang kontrol dan dua node add-on. HA cluster admin memiliki tiga node bidang kontrol dan tidak memiliki node add-on, sehingga jumlah VM yang diperlukan oleh cluster admin HA belum berubah, tetapi ketersediaannya meningkat secara signifikan.

Ringkasan prosedur

Berikut adalah langkah-langkah utama yang diperlukan dalam migrasi:

Edit file konfigurasi cluster admin.
Jalankan gkectl update admin. Perintah ini akan melakukan hal berikut:
- Buat cluster eksternal (Kind) dan pastikan cluster admin non-HA saat ini dalam status responsif.
- Buat bidang kontrol cluster admin baru menggunakan spesifikasi HA dan VIP bidang kontrol baru.
- Nonaktifkan panel kontrol cluster admin yang ada.
- Ambil snapshot etcd dari cluster admin yang ada.
- Pulihkan data cluster admin lama di bidang kontrol HA baru.
- Rekonsiliasi cluster admin yang dipulihkan untuk memenuhi status akhir admin HA .

Catatan

Selama migrasi, tidak ada periode nonaktif untuk workload cluster pengguna.
Selama migrasi, ada beberapa periode nonaktif untuk bidang kontrol cluster admin. (Periode nonaktif <18 menit berdasarkan pengujian, tetapi durasi sebenarnya bergantung pada lingkungan infrastruktur individual).
Persyaratan cluster admin dengan ketersediaan tinggi (HA) masih berlaku untuk migrasi non-HA ke HA. Artinya, jika Anda menggunakan load balancer Seesaw untuk cluster admin non-HA, Anda harus terlebih dahulu bermigrasi ke MetalLB, lalu bermigrasi ke cluster admin HA. Hal ini karena cluster admin HA tidak mendukung Seesaw.
Setelah migrasi berhasil dilakukan, akan ada resource yang tersisa (misalnya, VM master admin non-HA) yang sengaja kami simpan untuk pemulihan kegagalan. Anda dapat membersihkannya secara manual jika diperlukan.

Sebelum dan setelah migrasi

Berikut adalah perbedaan utama dalam cluster sebelum dan sesudah migrasi:

	Sebelum migrasi	Setelah migrasi
Replika node bidang kontrol	1	3
Node add-on	2	0
Replika Pod bidang kontrol (kube-apiserver, kube-etcd, dll.)	1	3
Ukuran disk data	100GB * 1	25GB * 3
Jalur disk data	Ditetapkan oleh vCenter.dataDisk dalam file konfigurasi cluster admin	Dibuat otomatis pada direktori: `/anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk`
Load balancer untuk VIP bidang kontrol	Ditetapkan oleh loadBalancer.kind di file konfigurasi cluster admin	`keepalived` + `haproxy`
Alokasi alamat IP untuk node bidang kontrol cluster admin	DHCP atau statis, bergantung pada network.ipMode.type	3 alamat IP statis
Alokasi alamat IP untuk node bidang kontrol cluster pengguna kubeception	DHCP atau statis, bergantung pada network.ipMode.type	DHCP atau statis, bergantung pada network.ipMode.type
File checkpoint	Diaktifkan secara default	Tidak digunakan

Mengedit file konfigurasi cluster admin

Anda harus menentukan empat alamat IP tambahan:

Tiga alamat IP untuk node bidang kontrol pada cluster admin
VIP bidang kontrol baru untuk load balancer cluster admin

Anda juga perlu mengubah beberapa kolom lainnya di konfigurasi cluster admin .

Tentukan alamat IP

Di file konfigurasi cluster admin, isi network.controlPlaneIPBlock bagian. Contoh:

controlPlaneIPBlock:
 netmask: "255.255.255.0"
 gateway: "172.16.20.1"
 ips:
 – ip: "172.16.20.50"
   hostname: "admin-cp-node-1"
 – ip: "172.16.20.51"
   hostname: "admin-cp-node-2"
 – ip: "172.16.20.52"
   hostname: "admin-cp-node-3"

Isilah hostconfig bagian. Jika cluster admin Anda menggunakan alamat IP statis, bagian ini sudah telah diisi. Contoh:
```
hostConfig:
 dnsServers:
 – 203.0.113.1
 – 198.51.100.1
 ntpServers:
 – 216.239.35.12
```
Ganti nilai loadBalancer.vips.controlPlaneVIP dengan VIP baru. Contoh:
```
loadBalancer:
 vips:
   controlPlaneVIP: "172.16.20.59"
```

Memperbarui kolom konfigurasi tambahan

Setel adminMaster.replicas ke 3:

adminMaster:
 replicas: 3
 cpus: 4
 memoryMB: 8192

Hapus vCenter.dataDisk kolom tersebut. Hal ini karena untuk cluster admin HA, jalur untuk ketiga {i>disk<i} yang digunakan oleh {i>node<i} bidang kontrol secara otomatis dihasilkan di bawah {i>root<i} anthos di datastore.
Jika loadBalancer.manualLB.controlPlaneNodePort memiliki nilai bukan nol, tetapkan ke 0.

Menyesuaikan konfigurasi load balancer manual

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

Untuk setiap dari tiga alamat IP node bidang kontrol baru yang Anda tentukan di bagian network.controlPlaneIPBlock, konfigurasikan pemetaan ini di load balancer Anda:

(controlPlaneVIP lama:443) -> (NEW_NODE_IP_ADDRESS:controlPlaneNodePort lama)

Hal ini dilakukan agar VIP bidang kontrol lama akan berfungsi selama migrasi.

Mengupdate cluster admin

Mulai migrasi:
```
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG
```
Ganti kode berikut:
- ADMIN_CLUSTER_KUBECONFIG: jalur kubeconfig cluster admin .
- ADMIN_CLUSTER_CONFIG: jalur konfigurasi cluster admin file
Perintah tersebut akan menampilkan progres migrasi.

Saat diminta, masukkan Y untuk melanjutkan.
Saat migrasi selesai, file kubeconfig cluster admin diperbarui secara otomatis untuk menggunakan VIP bidang kontrol baru. Sementara itu, VIP bidang kontrol lama masih berfungsi, dan juga dapat digunakan untuk mengakses cluster admin HA baru.

Membersihkan resource yang tertinggal secara manual jika diperlukan

Selama migrasi, gkectl tidak menghapus bidang kontrol cluster admin Pesan Suara. Sebaliknya, ia hanya mematikan VM, bukan menghapusnya dari vSphere. Jika Anda ingin menghapus VM bidang kontrol yang lama setelah migrasi berhasil, harus melakukan penghapusan secara manual.

Untuk menghapus VM platform kontrol lama dan resource terkait secara manual:

Pastikan VM master admin non-HA gke-admin-master-xxx sudah dinonaktifkan.
Hapus VM master admin non-HA gke-admin-master-xxx dari vSphere.
Hapus template VM master admin non-HA gke-admin-master-xxx-tmpl dari vSphere.
Hapus disk data admin non-HA dan file checkpoint admin.
Hapus file sementara yang disimpan di /home/ubuntu/admin-ha-migration/[ADMIN_CLUSTER_NAME]/.

Berikut adalah perintah govc jika Anda lebih memilih menggunakan CLI:

  // Configure govc credentials
  export GOVC_INSECURE=1
  export GOVC_URL=VCENTER_URL
  export GOVC_DATACENTER=DATACENTER
  export GOVC_DATASTORE=DATASTORE
  export GOVC_USERNAME=USERNAME
  export GOVC_PASSWORD=PASSWORD

  // Configure admin master VM name (you can find the master VM name from the "[HA Migration]" logs)
  export ADMIN_MASTER_VM=ADMIN_MASTER_VM_NAME

  // Configure datadisk path (remove ".vmdk" suffix)
  export DATA_DISK_PATH=DATADISK_PATH_WITHOUT_VMDK

  // Check whether admin master is in "poweredOff" state:
  govc vm.info $ADMIN_MASTER_VM | grep Power

  // Delete admin master VM
  govc vm.destroy $ADMIN_MASTER_VM

  // Delete admin master VM template
  govc vm.destroy "$ADMIN_MASTER_VM"-tmpl

  // Delete data disk
  govc datastore.ls $DATA_DISK_PATH
  govc datastore.rm $DATA_DISK_PATH

  // Delete admin checkpoint file
  govc datastore.ls "$DATA_DISK_PATH"-checkpoint.yaml
  govc datastore.rm "$DATA_DISK_PATH"-checkpoint.yaml