Memigrasikan cluster admin ke HA

Pratinjau

Fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dalam Persyaratan Khusus Layanan. Fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Halaman ini menunjukkan cara bermigrasi ke cluster admin ketersediaan tinggi (HA) dari cluster admin non-HA pada versi 1.29.

Catatan: Jika cluster Anda berada di versi 1.30 atau yang lebih tinggi, sebaiknya gunakan pendekatan yang disederhanakan yang dijelaskan dalam Merencanakan migrasi cluster ke fitur yang direkomendasikan.

1.29: Pratinjau
1.28: Tidak tersedia

Sebelum dan sesudah 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 meningkat 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 yang selalu aktif diaktifkan di cluster admin pada versi 1.14 atau yang lebih lama, Anda harus memutar kunci enkripsi sebelum memulai migrasi. Jika tidak, cluster admin HA baru tidak akan dapat mendekripsi secret.

Untuk memeriksa apakah cluster mungkin 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 memutar kunci enkripsi.

"GeneratedKeys":[{"KeyVersion":"1","Key":""}]

Mengganti kunci enkripsi secara rutin jika perlu

Jika langkah-langkah di bagian sebelumnya menunjukkan bahwa Anda perlu memutar kunci enkripsi, lakukan langkah-langkah berikut:

1. Tambahkan keyVersion di file konfigurasi cluster admin.

2. Update 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 dengan aman. Semua secret baru berikutnya dienkripsi menggunakan kunci enkripsi baru.

Peringatan: Jika Anda memulai migrasi tanpa merotasi kunci enkripsi, hubungi Dukungan Google.

Ringkasan prosedur

Migrasi ini melibatkan langkah-langkah utama berikut:

1. Edit file konfigurasi cluster admin.

2. Jalankan gkectl update admin. Perintah ini melakukan hal berikut:

   • Memunculkan cluster eksternal (Kind) dan memastikan cluster admin non-HA saat ini berada dalam status yang baik.

   • Membuat bidang kontrol cluster admin baru menggunakan spesifikasi HA dan VIP bidang kontrol baru.

   • Menonaktifkan panel kontrol cluster admin yang ada.

   • Mengambil snapshot etcd dari cluster admin yang ada.

   • Memulihkan data cluster admin lama di bidang kontrol HA baru.

   • Menyelaraskan cluster admin yang dipulihkan untuk memenuhi status akhir cluster admin HA.

Catatan

• Selama migrasi, tidak ada periode nonaktif untuk beban kerja cluster pengguna.

• Selama migrasi, akan ada periode nonaktif untuk bidang kontrol cluster admin. (Periode nonaktif kurang dari 18 menit, berdasarkan pengujian kami, tetapi durasi sebenarnya bergantung pada setiap lingkungan infrastruktur).

• Persyaratan untuk cluster admin HA tetap berlaku untuk migrasi non-HA ke HA. Misalnya, cluster admin HA tidak mendukung Seesaw sehingga jika Anda menggunakan load balancer Seesaw untuk cluster admin non-HA, Anda harus terlebih dahulu bermigrasi ke MetalLB, sebelum bermigrasi ke cluster admin HA.

• Setelah migrasi berhasil diselesaikan, resource yang tersisa seperti VM master admin non-HA, sengaja disimpan untuk pemulihan kegagalan.

Sebelum dan setelah migrasi

Tabel berikut menunjukkan 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 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

Mengedit 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.

Menentukan alamat IP

1. 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"
   

2. 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
   

3. Ganti nilai loadBalancer.vips.controlPlaneVIP dengan VIP baru. Contoh:

   loadBalancer:
    vips:
      controlPlaneVIP: "172.16.20.59"
   

Memperbarui kolom konfigurasi tambahan

1. Tetapkan adminMaster.replicas ke 3:

   adminMaster:
    replicas: 3
    cpus: 4
    memoryMB: 8192
   

2. Hapus kolom vCenter.dataDisk. Untuk cluster admin HA, jalur untuk tiga disk data yang digunakan oleh node platform kontrol dibuat secara otomatis di direktori root anthos di datastore.

3. 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 dari tiga alamat IP node bidang kontrol baru yang Anda tentukan di bagian network.controlPlaneIPBlock, konfigurasikan pemetaan berikut di load balancer:

(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 buat karena kolom tidak dapat diubah. Setelah Anda mengonfirmasi bahwa perubahan sudah benar, update cluster.

1. 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

2. Perintah ini menampilkan progres migrasi.

   Jika diminta, masukkan Y untuk melanjutkan.

3. Setelah migrasi selesai, file kubeconfig cluster admin akan otomatis diperbarui untuk menggunakan VIP bidang kontrol baru. VIP platform kontrol lama terus berfungsi dan juga dapat digunakan untuk mengakses cluster admin HA baru.