Cluster Anthos di VMware kini menjadi Google Distributed Cloud (khusus software) untuk VMware. Untuk mengetahui informasi selengkapnya, lihat ringkasan produk.

Halaman ini diterjemahkan oleh Cloud Translation API.

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 berikut:

Konfigurasi load balancer:
- Konfigurasi load balancer F5 BIG-IP terintegrasi ke ManualLB.
  
  atau
- Load balancer Seesaw yang dipaketkan ke MetalLB.
Bermigrasi ke cluster admin ketersediaan tinggi (HA) dari cluster admin non-HA. Ketersediaan akan 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 semua node panel kontrol tanpa node add-on.

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

Untuk 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 lingkungan yang paling tidak penting terlebih dahulu, seperti pengujian. Setelah Anda memverifikasi bahwa migrasi berhasil, ulangi proses ini untuk setiap lingkungan, dengan memigrasikan lingkungan produksi Anda sebagai yang terakhir. Hal ini memungkinkan Anda memvalidasi keberhasilan setiap migrasi dan memastikan bahwa workload Anda berjalan dengan benar, sebelum beralih ke lingkungan berikutnya yang lebih penting.

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 artikel 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 status stabil.

Dari	Ke	Akses Kubernetes API	Beban kerja 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

Terdampak: Ada gangguan layanan yang signifikan selama migrasi.
Tidak terpengaruh: Tidak ada gangguan layanan atau hampir tidak terlihat.

Mempersiapkan migrasi

Jika cluster admin Anda bukan 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, Menyiapkan 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 dari tiga node bidang kontrol, untuk bagian network.controlPlaneIPBlock dalam 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 yang diperlukan dan tujuan lainnya, seperti yang dijelaskan dalam Aturan firewall untuk cluster admin.

Menyiapkan migrasi load balancer

Jika cluster admin Anda menggunakan konfigurasi F5 BIG-IP terintegrasi atau load balancer Seesaw yang dipaketkan, 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, buat perubahan berikut pada file konfigurasi cluster admin:

Tetapkan kolom loadBalancer.kind ke "ManualLB".
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 menjadi alamat IP yang Anda alokasikan.
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:

Tetapkan kolom loadBalancer.kind ke "MetalLB".
Pertahankan bagian network.hostConfig.
Tetapkan atau pertahankan nilai kolom loadBalancer.vips.controlPlaneVIP]5. Jika cluster admin 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 menjadi alamat IP yang Anda alokasikan.
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 bukan 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 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 merotasi kunci enkripsi menggunakan langkah-langkah dalam masalah umum ini.

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

Memperbarui file konfigurasi cluster admin

Lakukan perubahan berikut pada file konfigurasi cluster admin:

Isi network.controlPlaneIPBlock dengan tiga alamat IP yang Anda alokasikan untuk node bidang kontrol.
Pastikan Anda telah mengisi bagian network.hostConfig. Bagian ini menyimpan informasi tentang server NTP, server DNS, dan domain penelusuran DNS yang digunakan oleh VM yang merupakan node cluster Anda.
Pastikan Anda telah mengganti nilai loadBalancer.vips.controlPlaneVIP dengan alamat IP yang Anda alokasikan.
Tetapkan adminMaster.replicas ke 3.
Hapus kolom vCenter.dataDisk. Untuk cluster admin HA, jalur untuk tiga disk data yang digunakan oleh node platform kontrol otomatis dibuat di direktori root anthos di datastore.
Jika loadBalancer.kind ditetapkan ke "ManualLB", tetapkan 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 jika diperlukan

Jika cluster admin Anda telah menggunakan load balancing manual, selesaikan 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, Migrasi cluster admin.

Untuk setiap dari tiga alamat IP node bidang kontrol baru yang Anda tentukan di bagian network.controlPlaneIPBlock, konfigurasikan pemetaan ini di load balancer eksternal (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 buat pada file konfigurasi cluster admin. Semua setelan tidak dapat diubah kecuali saat mengupdate 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 platform kontrol lama terus berfungsi dan dapat digunakan untuk mengakses cluster admin HA baru. Setelah migrasi selesai, file kubeconfig cluster admin akan otomatis diperbarui 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 berhasil berjalan.

MetalLB

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

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

Output menunjukkan 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 dinonaktifkan untuk cluster admin. Anda dapat menemukan nama VM Seesaw di bagian vmnames dari file seesaw-for-gke-admin.yaml di direktori konfigurasi.

`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