Halaman ini diterjemahkan oleh Cloud Translation API.

Memigrasikan cluster admin ke ketersediaan tinggi (HA)

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

1.29: Pratinjau
1.28: Tidak tersedia
1.16: Tidak tersedia

Cluster admin dengan ketersediaan tinggi (HA) memiliki tiga node bidang kontrol dan tanpa node add-on. Cluster admin non-HA memiliki satu node bidang kontrol dan dua node add-on.

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:
- Munculkan cluster eksternal (Kind) dan pastikan cluster admin non-HA saat ini dalam status yang responsif.
- Buat bidang kontrol cluster admin baru menggunakan spesifikasi ketersediaan tinggi (HA) dan VIP bidang kontrol baru.
- Nonaktifkan bidang kontrol cluster admin yang ada.
- Mengambil snapshot etcd dari cluster admin yang ada.
- Pulihkan data cluster admin lama di bidang kontrol ketersediaan tinggi (HA) baru.
- Rekonsiliasi cluster admin yang dipulihkan untuk memenuhi status akhir cluster admin HA.

Notes

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

Sebelum dan sesudah 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	Tetapkan 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 perlu menentukan empat alamat IP tambahan:

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

Anda juga perlu mengubah beberapa kolom lain di file konfigurasi cluster admin.

Tentukan alamat IP

Di file konfigurasi cluster admin, isi bagian network.controlPlaneIPBlock. 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"

Isi bagian hostconfig. Jika cluster admin Anda menggunakan alamat IP statis, bagian ini sudah terisi. 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

Tetapkan adminMaster.replicas ke 3:

adminMaster:
 replicas: 3
 cpus: 4
 memoryMB: 8192

Hapus kolom vCenter.dataDisk. Hal ini karena untuk cluster admin HA, jalur untuk tiga disk data yang digunakan oleh node bidang kontrol otomatis dihasilkan pada direktori root 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 masing-masing dari tiga alamat IP node bidang kontrol baru yang Anda tentukan di bagian network.controlPlaneIPBlock, konfigurasikan pemetaan ini di load balancer:

(controlPlaneVIP:443) -> (NEW_ ditemukan_IP_ADDRESS:lama controlPlaneNodePort)

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 file kubeconfig cluster admin.
- ADMIN_CLUSTER_CONFIG: jalur file konfigurasi cluster admin
Perintah tersebut menampilkan progres migrasi.

Saat diminta, masukkan Y untuk melanjutkan.
Setelah migrasi selesai, file kubeconfig cluster admin akan otomatis diperbarui untuk menggunakan VIP bidang kontrol baru. Sementara itu, VIP bidang kontrol lama masih berfungsi, dan juga dapat digunakan untuk mengakses cluster admin dengan ketersediaan tinggi (HA) yang baru.

Membersihkan secara manual sisa resource jika diperlukan

Selama migrasi, gkectl tidak menghapus VM bidang kontrol cluster admin. Sebagai gantinya, sistem hanya mematikan VM, bukan menghapusnya dari vSphere. Jika Anda ingin menghapus VM bidang kontrol lama setelah migrasi berhasil, Anda harus melakukan penghapusan secara manual.

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

Pastikan VM master admin non-HA gke-admin-master-xxx sudah dimatikan.
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.
Bersihkan file sementara yang disimpan di /home/ubuntu/admin-ha-migration/[ADMIN_CLUSTER_NAME]/.

Berikut adalah perintah govc jika menggunakan cli lebih disukai:

  // 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