Memigrasikan cluster admin ke HA

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:

  1. Tingkatkan keyVersion di file konfigurasi cluster admin.

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

  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 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 migrasiSetelah migrasi
Replika node bidang kontrol13
Node add-on20
Replika Pod bidang kontrol
(kube-apiserver, kube-etcd, dll.)
13
Ukuran disk data100GB * 125GB * 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 checkpointDiaktifkan secara defaultTidak 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

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

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