Memigrasikan cluster admin ke fitur yang direkomendasikan

Ringkasan

Halaman ini menunjukkan cara memigrasikan cluster admin versi 1.30 atau yang lebih tinggi ke fitur yang direkomendasikan ini:

• Konfigurasi load balancer:

  • Konfigurasi load balancer F5 BIG-IP terintegrasi ke ManualLB.

    atau

  • Load balancer Seesaw yang dibundel ke MetalLB.

• Migrasikan ke cluster admin ketersediaan tinggi (HA) dari cluster admin non-HA. Ketersediaan meningkat secara signifikan dengan cluster admin HA saat menggunakan jumlah VM yang sama. Cluster admin non-HA memiliki satu node bidang kontrol dan dua node add-on. Tiga node cluster admin HA adalah node bidang kontrol tanpa node add-on.

Halaman ini ditujukan untuk administrator dan Operator IT yang mengelola siklus proses infrastruktur teknologi yang mendasarinya. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten, lihat Peran dan tugas pengguna GKE umum. Google Cloud

Untuk mengetahui informasi selengkapnya tentang perencanaan migrasi, lihat Merencanakan migrasi cluster ke fitur yang direkomendasikan.

Praktik terbaik

Jika Anda memiliki beberapa lingkungan seperti pengujian, pengembangan, dan produksi, sebaiknya migrasikan terlebih dahulu lingkungan yang paling tidak penting, seperti pengujian. Setelah Anda memverifikasi bahwa migrasi berhasil, ulangi proses ini untuk setiap lingkungan, dengan memigrasikan lingkungan produksi Anda terakhir. Hal ini memungkinkan Anda memvalidasi keberhasilan setiap migrasi dan memastikan bahwa workload Anda berjalan dengan benar, sebelum berpindah ke lingkungan yang lebih penting berikutnya.

Persyaratan

• Cluster admin harus menggunakan versi 1.30 atau yang lebih tinggi.
• Semua cluster pengguna yang dikelola oleh cluster admin harus sudah dimigrasikan ke fitur yang direkomendasikan, seperti yang dijelaskan dalam Memigrasikan cluster pengguna ke fitur yang direkomendasikan.

Merencanakan periode nonaktif selama migrasi

Untuk migrasi, rencanakan beberapa periode nonaktif bidang kontrol yang terbatas. Akses Kubernetes API tidak tersedia untuk cluster admin non-HA selama sekitar 20 menit, tetapi bidang kontrol Kubernetes tetap tersedia untuk cluster admin HA dengan F5. Selama migrasi, bidang data Kubernetes terus berfungsi dalam kondisi stabil.

Catatan: Beban kerja pengguna hanya boleh berjalan di cluster pengguna, yang tidak terpengaruh saat memigrasikan cluster admin.

Dari	Ke	Akses Kubernetes API	Workload pengguna
Cluster admin HA dengan F5 BIG-IP	Cluster admin HA dengan ManualLB	Tidak terpengaruh	Tidak terpengaruh
cluster admin non-HA dengan MetalLB atau ManualLB	Cluster admin HA dengan jenis load balancer yang sama	Terpengaruh	Tidak terpengaruh
Cluster admin non-HA dengan F5 BIG-IP	Cluster admin HA dengan ManualLB	Terpengaruh	Tidak terpengaruh
cluster admin non-HA dengan Seesaw	Cluster admin HA dengan MetalLB	Terpengaruh	Tidak terpengaruh

• Terpengaruh: Terjadi gangguan layanan yang terlihat jelas selama migrasi.
• Tidak terpengaruh: Tidak ada gangguan layanan atau gangguan tersebut hampir tidak terasa.

Mempersiapkan migrasi

Jika cluster admin Anda adalah non-HA, bersiaplah untuk bermigrasi ke cluster admin HA dengan mengikuti langkah-langkah di bagian ini. Jika cluster admin Anda sudah HA, lanjutkan ke bagian berikutnya, Bersiap untuk migrasi load balancer.

Mengalokasikan alamat IP tambahan

Saat memigrasikan cluster admin dari non-HA ke HA, alokasikan empat alamat IP tambahan. Pastikan alamat IP ini berada di VLAN yang sama dengan node cluster admin yang ada dan belum digunakan oleh node yang ada:

• Alokasikan satu alamat IP untuk VIP bidang kontrol baru, untuk kolom loadBalancer.vips.controlPlaneVIP dalam file konfigurasi cluster admin.
• Alokasikan alamat IP baru untuk setiap tiga node bidang kontrol, untuk bagian network.controlPlaneIPBlock di file konfigurasi cluster admin.

Memperbarui aturan firewall

Saat memigrasikan cluster admin dari non-HA ke HA, perbarui aturan firewall di cluster admin Anda. Tindakan ini memastikan bahwa alamat IP yang baru dialokasikan untuk node panel kontrol dapat menjangkau semua API dan tujuan lain yang diperlukan, seperti yang dijelaskan dalam Aturan firewall untuk cluster admin.

Mempersiapkan migrasi load balancer

Jika cluster admin Anda menggunakan konfigurasi F5 BIG-IP terintegrasi atau load balancer Seesaw yang di-bundle, ikuti langkah-langkah di bagian ini untuk membuat perubahan yang diperlukan pada file konfigurasi cluster admin. Jika tidak, lanjutkan ke bagian berikutnya, Bersiap untuk bermigrasi dari non-HA ke HA.

F5 BIG-IP

Jika cluster admin Anda menggunakan konfigurasi F5 BIG-IP terintegrasi, lakukan perubahan berikut pada file konfigurasi cluster admin:

1. Tetapkan kolom loadBalancer.kind ke "ManualLB".
2. Tetapkan atau pertahankan nilai kolom loadBalancer.vips.controlPlaneVIP. Jika cluster admin Anda sudah HA, pertahankan nilai yang sama. Jika Anda bermigrasi dari cluster admin non-HA ke cluster admin HA, ubah nilai kolom loadBalancer.vips.controlPlaneVIP ke alamat IP yang Anda alokasikan.
3. Hapus seluruh bagian loadBalancer.f5BigIP.

Contoh file konfigurasi cluster admin berikut menunjukkan perubahan ini:

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.6
kind: "F5BigIP" "ManualLB"
f5BigIP:
    address: "203.0.113.20"
  credentials:
    fileRef:
      path: ""my-config-folder/user-creds.yaml"
      entry: "f5-creds"
  partition: "my-f5-user-partition"
  

Seesaw

Jika cluster admin Anda menggunakan load balancer Seesaw, lakukan perubahan berikut pada file konfigurasi cluster admin:

1. Tetapkan kolom loadBalancer.kind ke "MetalLB".
2. Pertahankan bagian network.hostConfig.
3. Tetapkan atau pertahankan nilai kolom loadBalancer.vips.controlPlaneVIP]5. Jika cluster admin Anda sudah HA, Anda dapat mempertahankan nilai yang sama. Jika bermigrasi dari cluster admin non-HA ke cluster admin HA, ubah nilai kolom loadBalancer.vips.controlPlaneVIP ke alamat IP yang Anda alokasikan.
4. Hapus bagian loadBalancer.seesaw.

Contoh file konfigurasi cluster admin berikut menunjukkan perubahan ini:

network:
hostConfig:
  dnsServers:
  - "203.0.113.1"
  - "203.0.113.2"
  ntpServers:
  - "203.0.113.3"
loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.6
kind: "MetalLB" "Seesaw"
seesaw:
  ipBlockFilePath: "user-cluster-1-ipblock.yaml"
  vrid: 1
  masterIP: ""
  cpus: 4
  memoryMB: 3072

Bersiap untuk bermigrasi dari non-HA ke HA

Jika cluster admin Anda adalah non-HA, bersiaplah untuk bermigrasi ke HA dengan mengikuti langkah-langkah di bagian ini.

Jika cluster admin Anda sudah HA, lanjutkan ke bagian berikutnya, Memigrasikan cluster admin.

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 mengganti kunci enkripsi menggunakan langkah-langkah dalam masalah umum ini.

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

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

Perbarui file konfigurasi cluster admin

Lakukan perubahan berikut pada file konfigurasi cluster admin:

1. Isi network.controlPlaneIPBlock dengan tiga alamat IP yang Anda alokasikan untuk node bidang kontrol.
2. Pastikan Anda telah mengisi bagian network.hostConfig. Bagian ini berisi informasi tentang server NTP, server DNS, dan domain penelusuran DNS yang digunakan oleh VM yang merupakan node cluster Anda.
3. Pastikan Anda telah mengganti nilai loadBalancer.vips.controlPlaneVIP dengan alamat IP yang Anda alokasikan.
4. Setel adminMaster.replicas ke 3.
5. 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.
6. Jika loadBalancer.kind disetel ke "ManualLB", setel loadBalancer.manualLB.controlPlaneNodePort ke 0.

Contoh file konfigurasi cluster admin berikut menunjukkan perubahan ini:

vCenter:
  address: "my-vcenter-server.my-domain.example"
  datacenter: "my-data-center"
  dataDisk: "xxxx.vmdk"
...
network:
  hostConfig:
    dnsServers:
    - 203.0.113.1
    - 203.0.113.2
    ntpServers:
    - 203.0.113.3
  ...
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "198.51.100.1"
    ips:
    - ip: "192.0.2.1"
      hostname: "admin-cp-hostname-1"
    - ip: "192.0.2.2"
      hostname: "admin-cp-hostname-2"
    - ip: "192.0.2.3"
      hostname: "admin-cp-hostname-3"
...

...
loadBalancer:
  vips:
    controlPlaneVIP: 192.0.2.6 192.0.2.50
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 30003 0

...
adminMaster:
  replicas: 3
  cpus: 4
  memoryMB: 8192
...

Sesuaikan pemetaan di load balancer Anda jika diperlukan

Jika cluster admin Anda telah menggunakan load balancing manual, selesaikan langkah-langkah di bagian ini.

Jika Anda bermigrasi dari F5 BIG-IP terintegrasi ke load balancing manual, atau jika Anda bermigrasi ke MetalLB, lanjutkan ke bagian berikutnya, Memigrasikan cluster admin.

Untuk setiap tiga alamat IP node control plane baru yang Anda tentukan di bagian network.controlPlaneIPBlock, konfigurasikan pemetaan ini di load balancer eksternal Anda (seperti F5 BIG-IP atau Citrix):

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

Hal ini memastikan bahwa VIP bidang kontrol lama terus berfungsi selama migrasi.

Memigrasikan cluster admin

Tinjau dengan cermat semua perubahan yang Anda lakukan pada file konfigurasi cluster admin. Semua setelan tidak dapat diubah kecuali saat memperbarui cluster untuk migrasi.

Update cluster:

gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG

Replace the following:

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

Selama migrasi dari non-HA ke HA, VIP control plane yang lebih lama terus berfungsi dan dapat digunakan untuk mengakses cluster admin HA baru. Setelah migrasi selesai, file kubeconfig cluster admin akan otomatis diupdate untuk menggunakan VIP bidang kontrol baru.

Setelah migrasi

Setelah update selesai, pastikan cluster admin berjalan:

kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Output yang diharapkan mirip dengan berikut ini:

Migrasi load balancer

Jika Anda memigrasikan load balancer, pastikan komponen load balancer berjalan dengan berhasil.

MetalLB

Jika Anda bermigrasi ke MetalLB, pastikan komponen MetalLB berjalan dengan berhasil menggunakan perintah berikut:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods \
    --namespace kube-system --selector app=metallb

Output menampilkan Pod untuk pengontrol dan speaker MetalLB. Contoh:

metallb-controller-744884bf7b-rznr9 1/1 Running
metallb-speaker-6n8ws 1/1 Running
metallb-speaker-nb52z 1/1 Running
metallb-speaker-rq4pp 1/1 Running

Setelah migrasi berhasil, hapus VM Seesaw yang dimatikan untuk cluster admin. Anda dapat menemukan nama VM Seesaw di bagian vmnames dari file seesaw-for-gke-admin.yaml di direktori konfigurasi Anda.

ManualLB

Setelah Anda mengupdate cluster untuk menggunakan load balancing manual, traffic ke cluster Anda tidak akan terganggu. Hal ini karena resource F5 yang ada masih ada, seperti yang dapat Anda lihat dengan menjalankan perintah berikut:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \

Output yang diharapkan mirip dengan berikut ini:

Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-xt697x   Opaque   4      13h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         13h
kube-system   serviceaccount/load-balancer-f5   0         13h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           13h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           13h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         13h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   13h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T04:37:34Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T04:37:34Z