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 pengguna ke fitur yang direkomendasikan

Ringkasan

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

Bermigrasi ke Dataplane V2 sebagai antarmuka jaringan container (CNI).
Memigrasikan cluster pengguna menggunakan kubeception ke Controlplane V2.
Migrasikan konfigurasi load balancer:
- Dari konfigurasi load balancer F5 BIG-IP terintegrasi ke ManualLB
  
  atau
- Dari load balancer Seesaw yang dipaketkan ke MetalLB.

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

Praktik terbaik

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.

Sebaiknya buat cluster pengguna baru dengan mengaktifkan Controlplane V2 untuk mempelajari perbedaan arsitektur dengan cluster kubeception. Cluster baru tidak memengaruhi beban kerja Anda. Namun, dalam skenario terburuk, jika migrasi gagal, Anda memiliki cluster yang siap untuk workload Anda.

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

Persyaratan

Untuk migrasi ini:

Cluster pengguna harus menggunakan versi 1.30 atau yang lebih tinggi.
Semua kumpulan node harus memiliki versi yang sama dengan cluster pengguna.
Jika cluster menggunakan load balancer Seesaw, pastikan Anda tidak mengandalkan Seesaw untuk pelestarian IP klien seperti yang dijelaskan di bagian berikut.

Pemeliharaan IP klien seesaw

Untuk memeriksa externalTrafficPolicy, jalankan perintah berikut:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get svc -A -o yaml | grep "externalTrafficPolicy: Local"

Jika Anda mengalami masalah ini, hubungi Dukungan Google.

Memperkirakan komitmen waktu dan merencanakan periode pemeliharaan

Saat Anda mengupdate cluster, secara default, semua node pool akan diupdate secara paralel. Namun, dalam setiap node pool, node diupdate secara berurutan. Oleh karena itu, total waktu pembaruan bergantung pada jumlah node dalam kumpulan node terbesar. Untuk menghitung perkiraan kasar setiap update:

Jika bermigrasi dari Seesaw ke MetalLB, perkirakan waktu 15 menit untuk update agar dapat memilih node pool untuk load balancer MetalLB. Untuk update ini, hanya kumpulan node yang dipilih yang akan diupdate.
Untuk update lainnya dalam proses migrasi, kalikan 15 menit dengan jumlah node dalam kumpulan node.

Untuk memperkirakan komitmen waktu, hitung frekuensi Anda perlu mengupdate cluster. Langkah-langkah tingkat tinggi berikut menunjukkan kapan Anda perlu menjalankan gkectl update cluster untuk mengupdate cluster:

Jika cluster pengguna menggunakan enkripsi secret yang selalu aktif, nonaktifkan fitur tersebut dan jalankan gkectl update cluster.
Jika cluster pengguna memiliki enableDataplaneV2 yang tidak ditetapkan atau ditetapkan ke false, buat perubahan konfigurasi, lalu jalankan gkectl update cluster untuk bermigrasi ke Dataplane V2.
Bersiaplah untuk migrasi load balancer dan bidang kontrol:
1. Jika cluster admin telah mengaktifkan perbaikan otomatis, nonaktifkan. Kemudian, jalankan gkectl update admin. Pembaruan ini selesai dengan cepat karena tidak membuat ulang node cluster admin.
2. Jika cluster pengguna menggunakan Seesaw, pilih node pool untuk load balancer MetalLB yang akan digunakan, lalu jalankan gkectl update cluster. Update ini hanya memperbarui node di kumpulan node yang dipilih.
Lakukan semua perubahan konfigurasi yang diperlukan untuk mengupdate load balancer dan melakukan migrasi ke Controlplane V2. Kemudian, jalankan gkectl update cluster.
Setelah migrasi, jika Anda menonaktifkan enkripsi secret yang selalu aktif,aktifkan kembali fitur tersebut dan jalankan gkectl update cluster.

Total waktu untuk migrasi bergantung pada frekuensi Anda harus menjalankan gkectl cluster update, yang bergantung pada konfigurasi Anda. Misalnya, Anda bermigrasi ke Dataplane V2, ControlPlane V2, dan MetalLB. Asumsikan juga bahwa ada 10 node di node pool terbesar dan 3 node di node pool yang akan digunakan MetalLB. Untuk menghitung estimasi waktu migrasi, tambahkan hal berikut:

150 menit untuk migrasi ke Dataplane V2 karena 15 menit * 10 node dalam kumpulan terbesar = 150 menit.
45 menit untuk node pool yang digunakan oleh MetalLB karena 15 menit * 3 node dalam node pool tersebut = 45 menit.
150 menit untuk update Controlplane V2 dan MetalLB karena 15 menit * 10 node di kumpulan terbesar = 150 menit.

Total waktu untuk migrasi adalah sekitar 345 menit, yang sama dengan 5 jam 45 menit.

Jika perlu, Anda dapat melakukan migrasi secara bertahap. Dengan menggunakan contoh sebelumnya, Anda dapat melakukan migrasi ke Dataplane V2 dalam satu periode pemeliharaan, dan melakukan migrasi lainnya dalam satu atau dua periode pemeliharaan.

Merencanakan periode nonaktif selama migrasi

Saat merencanakan migrasi, rencanakan jenis periode nonaktif berikut:

Periode nonaktif bidang kontrol: Akses ke server Kubernetes API akan terpengaruh selama migrasi. Jika Anda bermigrasi ke Controlplane V2, akan ada periode nonaktif control plane untuk cluster pengguna kubeception saat loadBalancer.vips.controlPlaneVIP dimigrasikan. Waktu nonaktif biasanya kurang dari 10 menit, tetapi durasi waktu nonaktif bergantung pada infrastruktur Anda.
Downtime beban kerja: IP virtual (VIP) yang digunakan oleh Layanan jenis: LoadBalancer tidak tersedia. Hal ini hanya terjadi selama migrasi dari Seesaw ke MetalLB. Proses migrasi MetalLB akan menghentikan koneksi jaringan ke semua VIP di cluster pengguna untuk Layanan Kubernetes jenis LoadBalancer selama sekitar dua hingga sepuluh menit. Setelah migrasi selesai, koneksi akan berfungsi kembali.

Tabel berikut menjelaskan dampak migrasi:

Dari	Ke	Akses Kubernetes API	Beban kerja pengguna
Cluster Kubeception menggunakan Calico, yang telah `enableDataplaneV2` tidak ditetapkan atau ditetapkan ke `false`	Cluster Kubeception dengan Dataplane V2	Tidak terpengaruh	Tidak terpengaruh
Cluster Kubeception, yang memiliki `enableControlplaneV2` yang tidak ditetapkan atau ditetapkan ke `false` dengan `MetalLB` atau `ManualLB`	Cluster Control Plane V2 dengan jenis load balancer yang sama	Terpengaruh	Tidak terpengaruh
Cluster Kubeception dengan `loadBalancer.kind: "F5BigIP"`	Cluster Controlplane V2 dengan konfigurasi load balancer manual	Terpengaruh	Tidak terpengaruh
Cluster Kubeception dengan `loadBalancer.kind: "Seesaw"`	Cluster Control Plane V2 dengan MetalLB	Terpengaruh	Terpengaruh

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

Mempersiapkan migrasi

Untuk memastikan keberhasilan migrasi, lakukan langkah-langkah di bagian berikut.

Mengalokasikan alamat IP baru

Jika Anda bermigrasi ke Controlplane V2, alokasikan alamat IP statis baru di VLAN yang sama dengan node pekerja (node dalam node pool).

Anda memerlukan satu alamat IP untuk loadBalancer.vips.controlPlaneVIP.
Alokasikan satu alamat IP untuk setiap node bidang kontrol. Jumlah alamat IP yang perlu Anda alokasikan bergantung pada apakah cluster pengguna akan memiliki ketersediaan tinggi (HA) atau non-HA.
- Non-HA: satu alamat IP
- HA: tiga alamat IP

Memperbarui aturan firewall

Jika Anda bermigrasi ke Controlplane V2, perbarui aturan firewall di cluster pengguna Anda. Pastikan alamat IP yang baru dialokasikan untuk node bidang kontrol di cluster pengguna dapat menjangkau semua API yang diperlukan dan tujuan lainnya, seperti yang dijelaskan dalam Aturan firewall node cluster pengguna.

Memeriksa versi cluster dan node pool

Pastikan semua node pool menggunakan versi yang sama dengan cluster pengguna, yang harus menggunakan versi 1.30 atau yang lebih baru. Jika tidak, upgrade node pool ke gkeOnPremVersion dalam file konfigurasi cluster pengguna sebelum melanjutkan migrasi. Untuk memeriksa versi, jalankan perintah berikut:

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

Ganti ADMIN_CLUSTER_KUBECONFIG dengan jalur ke file kubeconfig cluster admin Anda.

Memeriksa kondisi cluster

Periksa kondisi cluster dan perbaiki masalah apa pun yang dilaporkan perintah gkectl diagnose cluster:

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name USER_CLUSTER_NAME

Ganti kode berikut:

ADMIN_CLUSTER_KUBECONFIG: jalur file kubeconfig cluster admin.
USER_CLUSTER_NAME: nama cluster pengguna.

Menonaktifkan perbaikan otomatis di cluster admin

Jika Anda memigrasikan cluster pengguna untuk menggunakan Controlplane V2 dan perbaikan otomatis diaktifkan di cluster admin, nonaktifkan perbaikan otomatis. Periksa kolom autoRepair.enabled file konfigurasi cluster admin. Jika kolom tersebut tidak ditetapkan atau ditetapkan ke true, lakukan langkah-langkah berikut:

Dalam file konfigurasi cluster admin, tetapkan autoRepair.enabled ke false . Contoh:
```
autoRepair:
  enabled: false
```

Update cluster admin:

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

Ganti kode berikut:

ADMIN_CLUSTER_KUBECONFIG: jalur ke file kubeconfig cluster admin.
ADMIN_CLUSTER_CONFIG: jalur ke file konfigurasi cluster admin.

Setelah migrasi selesai, pastikan untuk mengaktifkan kembali perbaikan otomatis di cluster admin.

Memeriksa masalah terkait enkripsi rahasia yang selalu aktif

Jika Anda memigrasikan cluster pengguna untuk menggunakan Controlplane V2, periksa masalah enkripsi secret yang selalu aktif.

Jika enkripsi secret yang selalu aktif pernah diaktifkan di cluster pengguna, Anda harus melakukan langkah-langkah di Menonaktifkan enkripsi secret yang selalu aktif dan mendekripsi secret sebelum memulai migrasi. Jika tidak, cluster Controlplane V2 baru tidak dapat mendekripsi secret.

Sebelum memulai migrasi, jalankan perintah berikut untuk melihat apakah enkripsi secret yang selalu aktif pernah diaktifkan pada suatu waktu:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  get onpremusercluster USER_CLUSTER_NAME \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  -o jsonpath={.spec.secretsEncryption}

Jika output perintah sebelumnya kosong, enkripsi secret yang selalu aktif belum pernah diaktifkan. Anda dapat memulai migrasi.

Jika output perintah sebelumnya tidak kosong, berarti enkripsi secret yang selalu aktif sebelumnya telah diaktifkan. Sebelum melakukan migrasi, Anda harus melakukan langkah-langkah di bagian berikutnya untuk memastikan bahwa cluster Controlplane V2 baru dapat mendekripsi secret.

Contoh berikut menunjukkan output yang tidak kosong:

{"generatedKeyVersions":{"keyVersions":[1]}}

Menonaktifkan enkripsi secret yang selalu aktif dan mendekripsi secret jika diperlukan

Untuk menonaktifkan enkripsi secret yang selalu aktif dan mendekripsi secret, lakukan langkah-langkah berikut:

Di file konfigurasi cluster pengguna, untuk menonaktifkan enkripsi secret yang selalu aktif, tambahkan kolom disabled: true ke bagian secretsEncryption:
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: true
```
Update cluster:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
Ganti kode berikut:
- ADMIN_CLUSTER_KUBECONFIG: jalur file kubeconfig cluster admin
- USER_CLUSTER_CONFIG: jalur file konfigurasi cluster pengguna

Lakukan update berkelanjutan pada DaemonSet tertentu, sebagai berikut:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  rollout restart statefulsets kube-apiserver \
  -n USER_CLUSTER_NAME

Dapatkan manifes semua secret di cluster pengguna, dalam format YAML:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  get secrets -A -o yaml > SECRETS_MANIFEST.yaml

Agar semua secret disimpan di etcd sebagai teks biasa, terapkan kembali semua secret di cluster pengguna:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
Sekarang Anda dapat memulai migrasi ke Controlplane V2. Setelah migrasi selesai, Anda dapat mengaktifkan kembali enkripsi secret yang selalu aktif di cluster.

Mengaktifkan node pool untuk digunakan oleh MetalLB

Jika Anda bermigrasi dari load balancer Seesaw yang dipaketkan ke MetalLB, lakukan langkah-langkah di bagian ini. Cluster menggunakan Seesaw jika loadBalancer.kind: Seesaw ada dalam file konfigurasi cluster pengguna. Jika Anda memigrasikan konfigurasi F5 BIG-IP terintegrasi, lanjutkan ke bagian berikutnya, Melakukan migrasi ke Dataplane V2.

Pilih kumpulan node dan aktifkan untuk digunakan dengan MetalLB. Migrasi ini akan men-deploy MetalLB pada node dalam node pool tersebut.

Di bagian nodePools dalam file konfigurasi cluster pengguna, pilih kumpulan node atau tambahkan kumpulan node baru, dan tetapkan enableLoadBalancer ke true. Contoh:
```
nodePools:
  - name: pool-1
    replicas: 3
    enableLoadBalancer: true
```

Update cluster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Untuk informasi selengkapnya tentang MetalLB, lihat Load balancing yang dipaketkan dengan MetalLB.

Bermigrasi ke Dataplane V2

Sebelum bermigrasi, periksa apakah DataPlane V2 diaktifkan di cluster dengan menjalankan perintah berikut:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremusercluster USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -o yaml | grep enableDataplaneV2

Jika Dataplane V2 sudah diaktifkan, lanjutkan ke bagian berikutnya, Bersiap untuk migrasi load balancer.

Untuk bermigrasi ke Dataplane V2, lakukan langkah-langkah berikut. Jika Anda memiliki kekhawatiran tentang penghapusan spesifikasi NetworkPolicy untuk sementara, hubungi Dukungan Google.

Jika cluster Anda menggunakan NetworkPolicy, hapus sementara spesifikasinya dari cluster, sebagai berikut:

Periksa apakah ada NetworkPolicy non-sistem yang diterapkan ke cluster Anda:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy -A -o wide | grep -v kube-system

Jika output langkah sebelumnya tidak kosong, simpan setiap spesifikasi NetworkPolicy ke file:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml
```
Ganti kode berikut:
- NETWORK_POLICY_NAME: nama NetworkPolicy yang Anda simpan.
- NETWORK_POLICY_NAMESPACE: namespace NetworkPolicy.

Hapus NetworkPolicy, menggunakan perintah berikut:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE

Bermigrasi ke Dataplane V2 menggunakan langkah-langkah berikut:

Tetapkan enableDataplaneV2 ke true dalam file konfigurasi cluster pengguna Anda.

Untuk mengaktifkan DataPlane V2, update cluster Anda:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG

Jika Anda menghapus spesifikasi NetworkPolicy non-sistem pada langkah sebelumnya, setelah update selesai, terapkan kembali dengan perintah ini:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
```

Setelah menyelesaikan langkah-langkah tersebut, Dataplane V2 akan diaktifkan. Selanjutnya, bersiaplah untuk memigrasikan cluster Anda ke load balancer dan Controlplane V2 yang direkomendasikan.

Menyiapkan migrasi load balancer

Jika cluster pengguna Anda menggunakan load balancer Seesaw atau F5 BIG-IP terintegrasi, ikuti langkah-langkah di bagian ini untuk membuat perubahan file konfigurasi cluster pengguna yang diperlukan. Jika tidak, lanjutkan ke bagian berikutnya, Mempersiapkan migrasi ke Controlplane V2.

F5 BIG-IP

Jika cluster Anda menggunakan konfigurasi F5 BIG-IP terintegrasi, siapkan migrasi ke ManualLB dengan melakukan perubahan berikut pada file konfigurasi cluster pengguna:

Ubah loadBalancer.kind menjadi "ManualLB".
Tetapkan nilai yang sama untuk kolom loadBalancer.vips.ingressVIP.
Jika Anda bermigrasi ke Controlplane V2, ubah nilai kolom loadBalancer.vips.controlPlaneVIP ke alamat IP yang Anda alokasikan. Jika tidak, Anda dapat mempertahankan nilai yang sama.
Hapus seluruh bagian loadBalancer.f5BigIP.

Contoh file konfigurasi cluster pengguna berikut menunjukkan perubahan ini:

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.5
  ingressVIP: 198.51.100.20
kind: "f5BigIP" "ManualLB"
f5BigIP:
  address: "203.0.113.2"
  credentials:
  fileRef:
    path: "my-config-folder/user-creds.yaml"
    entry: "f5-creds"
  partition: "my-f5-user-partition"

Seesaw

Jika cluster pengguna Anda menggunakan load balancer Seesaw, siapkan migrasi ke MetalLB dengan melakukan langkah-langkah di bagian berikut.

Menentukan kumpulan alamat

Pengontrol MetalLB melakukan pengelolaan alamat IP untuk Layanan. Jadi, saat developer aplikasi membuat Service jenis LoadBalancer di cluster pengguna, mereka tidak perlu menentukan alamat IP untuk Service secara manual. Sebagai gantinya, pengontrol MetalLB memilih alamat IP dari kumpulan alamat yang Anda tentukan.

Pertimbangkan jumlah maksimum Layanan LoadBalancer yang mungkin aktif di cluster pengguna Anda. Kemudian, di bagian loadBalancer.metalLB.addressPools file konfigurasi cluster pengguna, tentukan alamat IP yang cukup untuk menampung Layanan tersebut.

Saat menentukan kumpulan alamat, sertakan VIP masuk untuk cluster pengguna Anda di salah satu kumpulan. Hal ini karena proxy masuk diekspos oleh Service jenis LoadBalancer.

Alamat harus dalam format CIDR atau format rentang. Jika Anda ingin menentukan alamat individual, gunakan CIDR /32 seperti 198.51.100.10/32.

Mengupdate file konfigurasi cluster

Perbarui file konfigurasi cluster untuk menghapus bagian Seesaw dan menambahkan bagian MetalLB, sebagai berikut:

Tetapkan loadBalancer.kind ke "MetalLB".
Anda dapat mempertahankan nilai yang sama untuk kolom loadBalancer.vips.ingressVIP.
Tambahkan VIP masuk ke kumpulan alamat MetalLB.
Jika Anda bermigrasi ke Controlplane V2, ubah nilai kolom loadBalancer.vips.controlPlaneVIP ke alamat IP yang Anda alokasikan. Jika tidak, Anda dapat mempertahankan nilai yang sama.
Hapus bagian loadBalancer.seesaw.
Tambahkan bagian loadBalancer.metalLB.

Bagian berikut dari file konfigurasi cluster pengguna menunjukkan perubahan ini dan konfigurasi MetalLB dari:

Pool alamat untuk pengontrol MetalLB yang dapat dipilih dan ditetapkan ke Layanan jenis LoadBalancer. VIP ingress, yang dalam contoh ini adalah 198.51.100.10, berada dalam kumpulan ini dalam notasi format rentang, 198.51.100.10/32.
VIP yang ditetapkan untuk server Kubernetes API cluster pengguna.
VIP ingress yang telah Anda konfigurasikan untuk proxy ingress.
Node pool yang diaktifkan untuk menggunakan MetalLB. Migrasi men-deploy MetalLB di node dalam node pool ini.

loadBalancer:
  vips:
    controlPlaneVIP: "198.51.100.50"
    ingressVIP: "198.51.100.10"
  kind: "MetalLB" "Seesaw"
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
  addressPools:
    - name: "address-pool-1"
      addresses:
      - "198.51.100.10/32"
      - "198.51.100.80 - 198.51.100.89"

Mempersiapkan migrasi ke Controlplane V2

Jika cluster belum mengaktifkan Controlplane V2:

Perbarui file konfigurasi cluster pengguna.
Jika cluster menggunakan load balancing manual (loadBalancer.kind: "ManualLB"), perbarui juga konfigurasi di load balancer Anda.

Langkah-langkah ini dijelaskan di bagian berikut.

Jika cluster sudah mengaktifkan Controlplane V2, lanjutkan ke bagian Memigrasikan cluster pengguna.

Memperbarui file konfigurasi cluster pengguna

Buat perubahan berikut pada file konfigurasi cluster pengguna yang ada:

Tetapkan enableControlplaneV2 ke true.
Secara opsional, buat panel kontrol untuk cluster pengguna Controlplane V2 sangat tersedia (HA). Untuk mengubah dari cluster non-HA menjadi cluster HA, ubah masterNode.replicas dari 1 menjadi 3.
Tambahkan alamat IP statis (atau alamat) untuk node kontrol-platform cluster pengguna ke bagian network.controlPlaneIPBlock.ips. Alamat IP (atau alamat) untuk node bidang kontrol harus berada di VLAN yang sama dengan node pekerja.
Isi netmask dan gateway di bagian network.controlPlaneIPBlock.
Jika bagian network.hostConfig kosong, isi.
Pastikan kolom loadBalancer.vips.controlPlaneVIP memiliki alamat IP baru untuk VIP bidang kontrol. Alamat IP harus berada di VLAN yang sama dengan IP node bidang kontrol.
Jika cluster pengguna menggunakan load balancing manual, tetapkan loadBalancer.manualLB.controlPlaneNodePort dan loadBalancer.manualLB.konnectivityServerNodePort ke 0. Nilai ini tidak diperlukan saat Controlplane V2 diaktifkan, tetapi nilainya harus 0.
Jika cluster pengguna menggunakan load balancing manual, konfigurasikan load balancer seperti yang dijelaskan di bagian berikutnya.

Sesuaikan pemetaan di load balancer jika diperlukan

Jika cluster pengguna sudah menggunakan load balancing manual, Anda perlu mengonfigurasi beberapa pemetaan di load balancer. Jika bermigrasi dari konfigurasi F5 BIG-IP terintegrasi ke load balancing manual, Anda tidak perlu membuat perubahan konfigurasi apa pun pada load balancer dan dapat langsung ke bagian berikutnya, Memigrasikan cluster pengguna.

Untuk setiap alamat IP yang Anda tentukan di bagian network.controlPlaneIPBlock, konfigurasikan pemetaan berikut di load balancer untuk node bidang kontrol:

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPSNodePort)

Pemetaan ini diperlukan untuk semua node di cluster pengguna, baik node bidang kontrol maupun node pekerja. Karena NodePort dikonfigurasi di cluster, Kubernetes membuka NodePort di semua node cluster sehingga setiap node di cluster dapat menangani traffic bidang data.

Setelah Anda mengonfigurasi pemetaan, load balancer akan memproses traffic di alamat IP yang Anda konfigurasikan untuk VIP ingress cluster pengguna di port HTTP dan HTTPS standar. Load balancer merutekan permintaan ke node mana pun dalam cluster. Setelah permintaan dirutekan ke salah satu node cluster, jaringan Kubernetes internal akan merutekan permintaan ke Pod tujuan.

Memigrasikan cluster pengguna

Pertama, tinjau dengan cermat semua perubahan yang Anda buat pada file konfigurasi cluster pengguna. Semua setelan load balancer dan Controlplane V2 tidak dapat diubah kecuali saat Anda mengupdate cluster untuk migrasi.

Untuk mengupdate cluster, jalankan perintah ini:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Migrasi Controlplane V2

Selama migrasi Controlplane V2, update akan melakukan tindakan berikut:

Membuat bidang kontrol cluster baru dengan ControlPlane V2 diaktifkan.
Menghentikan bidang kontrol Kubernetes cluster kubeception.
Mengambil snapshot etcd dari cluster kubeception.
Menonaktifkan node bidang kontrol cluster pengguna cluster kubeception. Hingga migrasi selesai, node tidak akan dihapus karena hal itu memungkinkan pemulihan kegagalan dengan kembali ke cluster kubeception tersebut.
Memulihkan data cluster di bidang kontrol baru, menggunakan snapshot etcd yang dibuat pada langkah sebelumnya.
Menghubungkan node nodepool cluster kubeception ke control plane baru, yang dapat diakses dengan controlPlaneVIP baru.
Menyelaraskan cluster pengguna yang dipulihkan untuk memenuhi status akhir cluster dengan ControlPlane V2 diaktifkan.

Perhatikan hal berikut:

Tidak ada periode nonaktif untuk beban kerja cluster pengguna selama migrasi.
Ada beberapa periode nonaktif untuk platform kontrol cluster pengguna selama migrasi. Secara khusus, panel kontrol tidak tersedia antara penghentian panel kontrol Kubernetes cluster kubeception dan penyelesaian koneksi node nodepool cluster kubeception ke panel kontrol baru. (Dalam pengujian, periode nonaktif ini kurang dari 7 menit, tetapi durasi sebenarnya bergantung pada infrastruktur Anda).
Pada akhir migrasi, node bidang kontrol cluster pengguna dari cluster kubeception akan dihapus. Jika cluster admin telah menetapkan network.ipMode.type ke "static", Anda dapat mendaur ulang beberapa alamat IP statis yang tidak digunakan. Anda dapat mencantumkan objek node cluster admin dengan kubectl get nodes -o wide untuk melihat alamat IP yang digunakan. Untuk mendaur ulang alamat IP tersebut, hapus alamat IP tersebut dari file konfigurasi cluster admin dan jalankan gkectl update admin.

Setelah migrasi

Setelah update selesai, lakukan langkah-langkah berikut:

Pastikan cluster pengguna Anda berjalan:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Outputnya mirip dengan hal berikut ini:

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Jika Anda bermigrasi ke Controlplane V2, perbarui aturan firewall di cluster admin untuk menghapus node panel kontrol cluster pengguna kubeception.
Jika Anda menonaktifkan enkripsi rahasia yang selalu aktif, aktifkan kembali fitur tersebut.
1. Di file konfigurasi cluster pengguna, hapus kolom disabled: true.
2. Update cluster pengguna:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
Jika Anda menonaktifkan perbaikan otomatis di cluster admin, aktifkan kembali fitur tersebut.
1. Dalam file konfigurasi cluster admin, tetapkan autoRepair.enabled ke true.
2. Update cluster:
```
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG
```

Migrasi load balancer

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

Migrasi MetalLB

Jika Anda bermigrasi ke MetalLB, pastikan komponen MetalLB berhasil berjalan:

kubectl --kubeconfig USER_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 pengguna. Anda dapat menemukan nama VM Seesaw di bagian vmnames dari file seesaw-for-[USERCLUSTERNAME].yaml di direktori konfigurasi.

Migrasi F5 BIG-IP

Setelah migrasi ke 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 CLUSTER_KUBECONFIG \
api-resources --verbs=list -o name | xargs -n 1 kubectl --kubeconfig
CLUSTER_KUBECONFIG get --show-kind --ignore-not-found
--selector=onprem.cluster.gke.io/legacy-f5-resource=true -A

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-sspwrd   Opaque   4      14h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         14h
kube-system   serviceaccount/load-balancer-f5   0         14h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           14h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           14h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         14h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   14h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T05:16:40Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T05:16:41Z