Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

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 container network interface (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 admin IT dan Operator yang mengelola siklus proses infrastruktur teknologi yang mendasarinya. Untuk mengetahui informasi tentang peran umum dan contoh tugas yang kami referensikan dalam kontenGoogle Cloud , lihat Peran dan tugas pengguna GKE umum.

Praktik terbaik

Sebaiknya Anda memigrasikan lingkungan yang paling tidak penting terlebih dahulu, seperti pengujian. Setelah memverifikasi bahwa migrasi berhasil, ulangi proses ini untuk setiap lingkungan, dengan memigrasikan lingkungan produksi Anda di akhir. Dengan begitu, Anda dapat memvalidasi keberhasilan setiap migrasi dan memastikan workload berjalan dengan baik, sebelum beralih ke lingkungan berikutnya yang lebih penting.

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

Untuk mengetahui 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 node pool harus memiliki versi yang sama dengan cluster pengguna.
Jika cluster menggunakan load balancer Seesaw, pastikan Anda tidak mengandalkan Seesaw untuk mempertahankan IP klien seperti yang dijelaskan di bagian berikutnya.

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 masa 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 update bergantung pada jumlah node di node pool terbesar. Untuk menghitung perkiraan kasar untuk setiap update:

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

Untuk memperkirakan komitmen waktu, hitung berapa kali 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 disetel atau disetel ke false, buat perubahan konfigurasi, lalu jalankan gkectl update cluster untuk bermigrasi ke Dataplane V2.
Bersiap untuk migrasi load balancer dan bidang kontrol:
1. Jika cluster admin telah mengaktifkan perbaikan otomatis, nonaktifkan. Kemudian, jalankan gkectl update admin. Update ini selesai dengan cepat karena tidak membuat ulang node cluster admin.
2. Jika cluster pengguna menggunakan Seesaw, pilih node pool yang akan digunakan load balancer MetalLB, lalu jalankan gkectl update cluster. Update ini hanya mengupdate node di node pool yang dipilih.
Lakukan semua perubahan konfigurasi yang diperlukan untuk mengupdate load balancer Anda dan bermigrasi ke Controlplane V2. Kemudian, jalankan gkectl update cluster.
Setelah migrasi, jika Anda menonaktifkan enkripsi secret always-on, aktifkan kembali fitur tersebut dan jalankan gkectl update cluster.

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

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

Total waktu untuk migrasi adalah sekitar 345 menit, yang setara 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 masa pemeliharaan, dan melakukan sisa migrasi dalam satu atau dua masa 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 bidang kontrol untuk cluster pengguna kubeception saat loadBalancer.vips.controlPlaneVIP dimigrasikan. Periode nonaktif biasanya kurang dari 10 menit, tetapi durasi periode nonaktif bergantung pada infrastruktur Anda.
Periode nonaktif workload: IP virtual (VIP) yang digunakan oleh Service 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 Service 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	Workload pengguna
Cluster kubeception yang menggunakan Calico, yang memiliki `enableDataplaneV2` yang tidak ditetapkan atau ditetapkan ke `false`	Cluster Kubeception dengan Dataplane V2	Tidak terdampak	Tidak terdampak
Cluster Kubeception, yang memiliki `enableControlplaneV2` tidak ditetapkan atau ditetapkan ke `false` dengan `MetalLB` atau `ManualLB`	Cluster Controlplane V2 dengan jenis load balancer yang sama	Yang terpengaruh	Tidak terdampak
Cluster kubeception dengan `loadBalancer.kind: "F5BigIP"`	Cluster Controlplane V2 dengan konfigurasi load balancer manual	Yang terpengaruh	Tidak terdampak
Cluster Kubeception dengan `loadBalancer.kind: "Seesaw"`	Cluster Controlplane V2 dengan MetalLB	Yang terpengaruh	Yang terpengaruh

Terpengaruh: Terjadi gangguan layanan yang terlihat 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 worker node (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 Node cluster pengguna aturan firewall.

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 tinggi. Jika belum, upgrade node pool ke gkeOnPremVersion di 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 oleh 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 pada 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 secret yang selalu aktif

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

Jika enkripsi secret selalu aktif pernah diaktifkan di cluster pengguna, Anda harus melakukan langkah-langkah dalam Menonaktifkan enkripsi secret selalu aktif dan mendekripsi secret sebelum memulai migrasi. Jika tidak, cluster Controlplane V2 yang baru tidak akan 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 bermigrasi, Anda harus melakukan langkah-langkah di bagian berikutnya untuk memastikan bahwa cluster Controlplane V2 yang 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:

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

Memeriksa masalah terkait webhook workload yang salah dikonfigurasi

Jika Anda memigrasikan cluster pengguna untuk menggunakan Controlplane V2, periksa apakah ada masalah dengan webhook workload yang salah dikonfigurasi.

Jika Anda memiliki webhook yang menyertakan pod sistem di namespace kube-system, tambahkan namespaceSelector untuk memfilter namespace kube-system.

Misalnya,

  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system

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, Bermigrasi ke Dataplane V2.

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

Di bagian nodePools dalam file konfigurasi cluster pengguna, pilih node pool atau tambahkan node pool 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 mengetahui 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:

Jika cluster awalnya dibuat dengan Dataplane V2 diaktifkan, lanjutkan ke Bersiap untuk migrasi load balancer.
Jika cluster sebelumnya telah dimigrasikan dari Calico ke Dataplane V2 (misalnya, selama upgrade ke versi 1.31), lanjutkan ke Menghapus DaemonSet Calico yang tidak aktif.

Untuk bermigrasi ke Dataplane V2, Anda memiliki opsi berikut:

Upgrade cluster ke 1.31. Untuk mengetahui langkah-langkah mendetail, lihat Mengaktifkan Dataplane V2.
Update cluster 1.30.

Dalam kedua kasus tersebut, Anda harus menghapus spesifikasi NetworkPolicy untuk sementara seperti yang dijelaskan dalam langkah-langkah berikut.

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

Jika cluster Anda menggunakan NetworkPolicy, hapus spesifikasinya untuk sementara 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 agar Anda dapat menerapkan ulang spesifikasi setelah mengupdate cluster.
```
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

Migrasikan 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
```

Anda telah mengaktifkan Dataplane V2.

Menghapus DaemonSet Calico yang tidak aktif

Setelah Anda memigrasikan cluster admin atau cluster pengguna dari Calico ke Dataplane V2, DaemonSet calico-node dan calico-route-daemon tetap tidak aktif di namespace kube-system untuk mempertahankan kemampuan rollback. Sebelum menskalakan atau mengupgrade cluster, hapus anotasi features.onprem.cluster.gke.io/dpv2-migration sekali per cluster yang dimigrasikan agar pengontrol cluster menghapus DaemonSet Calico yang tidak aktif secara permanen dan mencegahnya melakukan inisialisasi pada node baru (lihat masalah umum Waktu tunggu koneksi terputus-putus setelah mengupgrade atau menskalakan cluster yang dimigrasikan dari Calico ke Dataplane V2). Anda tidak perlu melakukan langkah-langkah ini pada cluster yang dibuat dengan Dataplane V2 diaktifkan.

Pastikan migrasi Dataplane V2 telah selesai dan semua node dalam cluster memiliki label networking.gke.io/cni-type: cilium:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG get nodes -L networking.gke.io/cni-type
```
Ganti CLUSTER_KUBECONFIG dengan jalur ke file kubeconfig cluster pengguna atau cluster admin.
Setelah Anda mengonfirmasi bahwa Dataplane V2 berjalan di semua node dan Anda tidak perlu lagi melakukan roll back ke Calico, hapus anotasi features.onprem.cluster.gke.io/dpv2-migration dari resource kustom OnPremUserCluster (dan dari OnPremAdminCluster jika cluster admin Anda dimigrasikan dari Calico selama upgrade dari versi 1.29 ke 1.30):
```
# For a user cluster:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG annotate onpremusercluster USER_CLUSTER_NAME \
    -n USER_CLUSTER_NAME-gke-onprem-mgmt \
    features.onprem.cluster.gke.io/dpv2-migration-

# For an admin cluster:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG annotate onpremadmincluster ADMIN_CLUSTER_NAME \
    -n kube-system \
    features.onprem.cluster.gke.io/dpv2-migration-
```
Ganti kode berikut:
- ADMIN_CLUSTER_KUBECONFIG: jalur ke file kubeconfig cluster admin.
- USER_CLUSTER_NAME: nama cluster pengguna.
- ADMIN_CLUSTER_NAME: nama cluster admin (Anda dapat menemukannya dengan menjalankan kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremadmincluster -n kube-system).
Catatan: Jangan gunakan kubectl delete daemonset untuk menghapus DaemonSet secara manual, karena pengontrol cluster merekonsiliasi paket add-on selama update dan upgrade, serta membuatnya kembali kecuali jika Anda menghapus anotasi features.onprem.cluster.gke.io/dpv2-migration.

Pastikan pengontrol telah menghapus DaemonSet calico-node dan calico-route-daemon (keduanya menampilkan NotFound):

kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-system get daemonset calico-node calico-route-daemon

Selanjutnya, bersiaplah untuk memigrasikan cluster Anda ke load balancer dan Controlplane V2 yang direkomendasikan.

Mempersiapkan 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, Bersiap untuk migrasi ke Controlplane V2.

F5 BIG-IP

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

Ubah loadBalancer.kind menjadi "ManualLB".
Pertahankan 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, bersiaplah untuk bermigrasi ke MetalLB dengan melakukan langkah-langkah di bagian berikut.

Menentukan kumpulan alamat

Pengontrol MetalLB menetapkan alamat IP untuk Service. Saat developer aplikasi membuat Service jenis LoadBalancer di cluster pengguna, pengontrol MetalLB akan otomatis menetapkan alamat IP untuk Service tersebut. Pengontrol MetalLB memilih alamat IP dari kumpulan alamat yang Anda tentukan.

Untuk memastikan cluster pengguna Anda memiliki alamat IP yang cukup, pertimbangkan jumlah maksimum Layanan LoadBalancer yang mungkin aktif. Kemudian, tentukan alamat IP yang cukup di bagian loadBalancer.metalLB.addressPools pada file konfigurasi cluster pengguna Anda.

Alamat dalam kumpulan harus dalam format CIDR atau format rentang. Untuk menentukan alamat individual, gunakan CIDR /32. Contoh:

addresses:
  -   "192.0.2.0/26"
  -   "192.0.2.64-192.0.2.72"
  -   "192.0.2.75/32"

Mengecualikan alamat IP yang digunakan untuk tujuan lain

Jangan sertakan alamat IP berikut dalam kumpulan alamat mana pun:

VIP bidang kontrol:
- cluster admin
- cluster pengguna
Alamat IP node bidang kontrol:
- cluster admin
- cluster pengguna
Alamat IP gateway:
- cluster admin
- cluster pengguna
Alamat IP untuk Service:
- cluster admin
- cluster pengguna
Alamat IP untuk Pod:
- cluster admin
- cluster pengguna
Alamat IP worker node cluster pengguna
Alamat IP server vCenter, server DNS, server NTP, dan workstation admin

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

Kumpulan alamat yang dapat dipilih oleh pengontrol MetalLB dan ditetapkan ke Service jenis LoadBalancer. VIP ingress, yang dalam contoh ini adalah 198.51.100.10, berada di pool ini dalam notasi format rentang, 198.51.100.10/32.
VIP yang ditetapkan untuk server Kubernetes API cluster pengguna.
VIP ingress yang telah Anda konfigurasi untuk proxy ingress.
Node pool yang diaktifkan untuk menggunakan MetalLB. Migrasi men-deploy MetalLB pada node di 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"

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

Mengupdate file konfigurasi cluster pengguna

Buat perubahan berikut pada file konfigurasi cluster pengguna yang ada:

Tetapkan enableControlplaneV2 ke true.
Secara opsional, buat bidang kontrol untuk cluster pengguna Controlplane V2 memiliki ketersediaan tinggi (HA). Untuk mengubah dari cluster non-HA menjadi cluster HA, ubah masterNode.replicas dari 1 menjadi 3.
Tambahkan alamat IP statis untuk node bidang kontrol cluster pengguna ke bagian network.controlPlaneIPBlock.ips. Alamat IP untuk node bidang kontrol harus berada di VLAN yang sama dengan worker node. Nama host wajib diisi.
Isi netmask dan gateway di bagian network.controlPlaneIPBlock.
Jika bagian network.hostConfig kosong, isi bagian tersebut.
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. Keduanya tidak diperlukan saat Controlplane V2 diaktifkan, tetapi harus memiliki nilai 0.
Jika cluster pengguna menggunakan load balancing manual, konfigurasikan load balancer Anda seperti yang dijelaskan di bagian berikutnya.

Menyesuaikan pemetaan di load balancer jika diperlukan

Jika cluster pengguna Anda sudah menggunakan load balancing manual, Anda perlu mengonfigurasi beberapa pemetaan di load balancer. Jika Anda bermigrasi dari konfigurasi F5 BIG-IP terintegrasi ke load balancing manual, Anda tidak perlu melakukan perubahan konfigurasi apa pun pada load balancer dan dapat langsung melanjutkan 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 worker node. Karena NodePort dikonfigurasi di cluster, Kubernetes membuka NodePort di semua node cluster sehingga node mana pun di cluster dapat menangani traffic bidang data.

Setelah Anda mengonfigurasi pemetaan, load balancer akan memproses traffic di alamat IP yang Anda konfigurasi 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.
Mematikan node bidang kontrol cluster pengguna pada 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 bidang kontrol 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 workload cluster pengguna selama migrasi.
Ada beberapa periode nonaktif untuk bidang kontrol cluster pengguna selama migrasi. Secara khusus, bidang kontrol tidak tersedia antara penghentian bidang kontrol Kubernetes cluster kubeception dan penyelesaian koneksi node nodepool cluster kubeception ke bidang kontrol baru. (Dalam pengujian, periode nonaktif ini kurang dari 7 menit, tetapi durasi sebenarnya bergantung pada infrastruktur Anda).
Di akhir migrasi, node bidang kontrol cluster pengguna dari cluster kubeception akan dihapus. Jika cluster admin memiliki network.ipMode.type yang ditetapkan 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 sedang digunakan. Untuk mendaur ulang alamat IP tersebut, hapus alamat IP dari file konfigurasi cluster admin dan jalankan gkectl update admin.
Di akhir migrasi, worker node akan melalui update bertahap. Tunggu hingga semua node siap sebelum melanjutkan ke langkah-langkah pascamigrasi di bagian berikut.
Setelah migrasi, alamat VIP bidang kontrol lama masih berfungsi, tetapi tidak stabil. Jangan mengandalkannya. Perbarui semua dependensi pada alamat VIP lama untuk menggunakan alamat VIP baru sesegera mungkin.

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 bidang kontrol cluster pengguna kubeception.
Jika Anda menonaktifkan enkripsi secret yang selalu aktif, aktifkan kembali fitur tersebut.
1. Di file konfigurasi cluster pengguna, hapus kolom disabled: true.
2. Perbarui 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 berjalan dengan baik.

Migrasi MetalLB

Jika Anda bermigrasi ke MetalLB, pastikan komponen MetalLB berjalan dengan baik:

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

Output akan 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 dinonaktifkan untuk cluster pengguna. Anda dapat menemukan nama VM Seesaw di bagian vmnames pada 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