Halaman ini menunjukkan cara bermigrasi ke cluster admin ketersediaan tinggi (HA) dari cluster admin non-HA di versi 1.29.
1.29: Pratinjau
1.28: Tidak tersedia
Sebelum dan setelah migrasi, cluster admin memiliki tiga node:
- Cluster admin non-HA memiliki satu node bidang kontrol dan dua node add-on.
- Cluster admin HA memiliki tiga node bidang kontrol dan tidak ada node add-on, dan ketersediaannya ditingkatkan secara signifikan.
Mempersiapkan migrasi
Jika versi cluster admin Anda adalah 1.29.0-1.29.600 atau 1.30.0-1.30.100, dan jika enkripsi rahasia selalu aktif diaktifkan di cluster admin pada versi 1.14 atau yang lebih lama, Anda harus merotasi kunci enkripsi sebelum memulai migrasi. Jika tidak, cluster admin HA baru tidak akan dapat mendekripsi rahasia.
Untuk memeriksa apakah cluster dapat menggunakan kunci enkripsi lama:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'
Jika output menampilkan kunci kosong, seperti dalam contoh berikut, Anda harus merotasi kunci enkripsi.
"GeneratedKeys":[{"KeyVersion":"1","Key":""}]
Merotasi kunci enkripsi jika diperlukan
Jika langkah-langkah di bagian sebelumnya menunjukkan bahwa Anda perlu merotasi kunci enkripsi, lakukan langkah-langkah berikut:
Tingkatkan
keyVersion
di file konfigurasi cluster admin.Perbarui cluster admin:
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG
Tindakan ini akan membuat kunci baru yang cocok dengan nomor versi baru, mengenkripsi ulang setiap secret, dan menghapus secret lama secara aman. Semua secret baru berikutnya dienkripsi menggunakan kunci enkripsi baru.
Ringkasan prosedur
Migrasi ini melibatkan langkah-langkah utama berikut:
Edit file konfigurasi cluster admin.
Jalankan
gkectl update admin
. Perintah ini melakukan hal berikut:Memunculkan cluster eksternal (Kind) dan memastikan cluster admin non-HA saat ini dalam kondisi baik.
Membuat bidang kontrol cluster admin baru menggunakan spesifikasi HA dan VIP bidang kontrol baru.
Menonaktifkan bidang kontrol cluster admin yang ada.
Mengambil snapshot etcd dari cluster admin yang ada.
Memulihkan data cluster admin lama di bidang kontrol HA baru.
Menyesuaikan cluster admin yang dipulihkan agar sesuai dengan status akhir cluster admin HA.
Catatan
Selama migrasi, tidak ada periode nonaktif untuk workload cluster pengguna.
Selama migrasi, bidang kontrol cluster admin akan mengalami waktu non-operasional. (Periode nonaktif kurang dari 18 menit, berdasarkan pengujian kami, tetapi durasi sebenarnya bergantung pada lingkungan infrastruktur masing-masing).
Persyaratan untuk cluster admin HA tetap berlaku untuk migrasi non-HA ke HA. Misalnya, cluster admin HA tidak mendukung Seesaw, jadi jika Anda menggunakan load balancer Seesaw untuk cluster admin non-HA, Anda harus bermigrasi ke MetalLB terlebih dahulu, sebelum bermigrasi ke cluster admin HA.
Setelah migrasi berhasil diselesaikan, resource yang tersisa seperti VM master admin non-HA, sengaja dipertahankan untuk pemulihan kegagalan.
Sebelum dan setelah migrasi
Tabel berikut menunjukkan perbedaan utama dalam cluster sebelum dan setelah 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 secara otomatis di direktori: /anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk |
Load balancer untuk VIP bidang kontrol | Ditetapkan oleh loadBalancer.kind dalam 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 |
Edit file konfigurasi cluster admin
Anda harus menentukan empat alamat IP tambahan:
- Tiga alamat IP untuk node bidang kontrol cluster admin
- VIP bidang kontrol baru untuk load balancer cluster admin
Anda juga harus mengubah beberapa kolom lain dalam file konfigurasi cluster admin, seperti yang dijelaskan di bagian berikut.
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 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
Tetapkan adminMaster.replicas ke
3
:adminMaster: replicas: 3 cpus: 4 memoryMB: 8192
Hapus kolom vCenter.dataDisk. Untuk cluster admin HA, jalur untuk tiga disk data yang digunakan oleh node bidang kontrol dibuat secara otomatis di 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, selesaikan bagian ini. Jika tidak, lewati bagian ini.
Untuk setiap tiga alamat IP node bidang kontrol baru yang Anda tentukan di bagian network.controlPlaneIPBlock, konfigurasi pemetaan berikut di load balancer Anda:
(old controlPlaneVIP:443) -> (NEW_NODE_IP_ADDRESS:old controlPlaneNodePort)
Pemetaan ini memastikan bahwa VIP bidang kontrol lama berfungsi selama migrasi.
Memperbarui cluster admin
Tinjau perubahan konfigurasi yang Anda lakukan karena kolom tidak dapat diubah. Setelah Anda mengonfirmasi bahwa perubahan sudah benar, perbarui cluster.
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 ini menampilkan progres migrasi.
Jika diminta, masukkan
Y
untuk melanjutkan.Setelah migrasi selesai, file kubeconfig cluster admin akan diperbarui secara otomatis untuk menggunakan VIP bidang kontrol baru. VIP control plane yang lebih lama akan terus berfungsi dan juga dapat digunakan untuk mengakses cluster admin HA baru.