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 hingga ManualLB
  
  atau
- Dari load balancer Seesaw yang dibundel ke MetalLB.

Halaman ini ditujukan untuk administrator dan Operator 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 Peran dan tugas pengguna GKE Enterprise umum.

Praktik terbaik

Sebaiknya migrasikan terlebih dahulu lingkungan yang paling tidak penting, seperti test. 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 workload Anda berjalan dengan benar, sebelum berpindah ke lingkungan berikutnya yang lebih penting.

Sebaiknya buat cluster pengguna baru dengan Controlplane V2 yang diaktifkan 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 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.

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

Perkirakan komitmen waktu dan rencanakan masa pemeliharaan

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

Jika bermigrasi dari Seesaw ke MetalLB, perkirakan waktu 15 menit untuk pembaruan guna memilih node pool untuk load balancer MetalLB. Untuk update ini, hanya kumpulan node yang dipilih yang 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 memperbarui cluster. Langkah-langkah tingkat tinggi berikut menunjukkan kapan Anda perlu menjalankan gkectl update cluster untuk memperbarui cluster:

Jika cluster pengguna menggunakan enkripsi secret selalu aktif, nonaktifkan fitur dan jalankan gkectl update cluster.
Jika cluster pengguna memiliki enableDataplaneV2 yang tidak disetel atau disetel ke false, lakukan perubahan konfigurasi, lalu jalankan gkectl update cluster untuk bermigrasi ke Dataplane V2.
Mempersiapkan migrasi load balancer dan bidang kontrol:
1. Jika cluster admin memiliki perbaikan otomatis diaktifkan, 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 kumpulan node yang dipilih.
Lakukan semua perubahan konfigurasi yang diperlukan untuk memperbarui load balancer dan bermigrasi ke Controlplane V2. Kemudian, jalankan gkectl update cluster.
Setelah migrasi, jika Anda menonaktifkan enkripsi rahasia selalu aktif, aktifkan kembali fitur ini 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, 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 perkiraan waktu migrasi, tambahkan berikut:

150 menit untuk migrasi ke Dataplane V2 karena 15 menit * 10 node di kumpulan 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 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 terpengaruh selama migrasi. Jika Anda bermigrasi ke Controlplane V2, akan ada periode nonaktif bidang kontrol untuk cluster pengguna kubeception saat loadBalancer.vips.controlPlaneVIP dimigrasikan. Waktu nonaktif biasanya kurang dari 10 menit, tetapi durasi waktu nonaktif bergantung pada infrastruktur Anda.
Waktu nonaktif workload: 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	Workload pengguna
Cluster Kubeception menggunakan Calico, yang memiliki `enableDataplaneV2` tidak disetel atau disetel ke `false`	Cluster Kubeception dengan Dataplane V2	Tidak terpengaruh	Tidak terpengaruh
Cluster Kubeception, yang memiliki `enableControlplaneV2` tidak ditetapkan atau ditetapkan ke `false` dengan `MetalLB` atau `ManualLB`	Cluster Controlplane 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 Controlplane V2 dengan MetalLB	Terpengaruh	Terpengaruh

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

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 di 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 dan tujuan lain yang diperlukan, seperti yang dijelaskan dalam Aturan firewall untuk node cluster pengguna.

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

Periksa kondisi cluster

Periksa kondisi cluster dan perbaiki masalah 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 file konfigurasi cluster admin. Jika kolom tersebut tidak disetel atau disetel ke true, lakukan langkah-langkah berikut:

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

Perbarui 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 pada enkripsi rahasia yang selalu aktif

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

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

Sebelum memulai migrasi, jalankan perintah berikut untuk melihat apakah enkripsi secret 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, berarti enkripsi rahasia selalu aktif belum pernah diaktifkan. Anda dapat memulai migrasi.

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

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

Memeriksa masalah pada webhook workload yang salah dikonfigurasi

Jika Anda memigrasikan cluster pengguna untuk menggunakan Controlplane V2, periksa 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 dibundel 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 kumpulan node 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 dibundel dengan MetalLB.

Bermigrasi ke Dataplane V2

Sebelum melakukan migrasi, 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, Mempersiapkan migrasi load balancer.

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 sementara spesifikasi NetworkPolicy 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 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 sehingga Anda dapat menerapkan kembali spesifikasi setelah memperbarui 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, maka setelah update selesai, terapkan kembali dengan perintah ini:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
```

Setelah menyelesaikan langkah-langkah tersebut, Anda telah mengaktifkan Dataplane V2. 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 melakukan 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, bersiaplah untuk migrasi ke ManualLB dengan membuat 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 migrasi ke MetalLB dengan melakukan langkah-langkah di bagian berikut.

Menentukan kumpulan alamat

Pengontrol MetalLB menetapkan alamat IP untuk Layanan. 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 kemungkinan akan aktif. Kemudian, tentukan alamat IP yang cukup di bagian loadBalancer.metalLB.addressPools file konfigurasi cluster pengguna Anda.

Alamat di pool 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"

Perbarui 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 akan dipilih dan ditetapkan oleh pengontrol MetalLB ke Layanan jenis LoadBalancer. VIP ingress, yang dalam contoh ini adalah 198.51.100.10, berada di 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 konfigurasi untuk proxy ingress.
Node pool yang diaktifkan untuk menggunakan MetalLB. Migrasi ini men-deploy MetalLB di node dalam kumpulan node 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 Migrasikan cluster pengguna.

Perbarui file konfigurasi cluster pengguna

Buat perubahan berikut pada file konfigurasi cluster pengguna yang ada:

Tetapkan enableControlplaneV2 ke benar (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 (atau alamat) untuk node bidang kontrol cluster pengguna ke bagian network.controlPlaneIPBlock.ips. Alamat IP (atau alamat) untuk node bidang kontrol harus berada di VLAN yang sama dengan node pekerja. 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 keduanya harus memiliki nilai 0.
Jika cluster pengguna menggunakan load balancing manual, konfigurasikan load balancer Anda seperti yang dijelaskan di bagian berikutnya.

Sesuaikan pemetaan di load balancer Anda jika diperlukan

Jika cluster pengguna Anda sudah menggunakan load balancing manual, Anda perlu mengonfigurasi beberapa pemetaan di load balancer Anda. 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 membuka bagian berikutnya, Memigrasikan cluster pengguna.

Untuk setiap alamat IP yang Anda tentukan di bagian network.controlPlaneIPBlock, konfigurasi 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 di cluster. Setelah permintaan dirutekan ke salah satu node cluster, jaringan Kubernetes internal akan merutekan permintaan ke Pod tujuan.

Migrasikan cluster pengguna

Pertama, tinjau dengan cermat semua perubahan yang Anda lakukan 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 kubeception. Hingga migrasi selesai, node tidak dihapus karena hal itu memungkinkan pemulihan kegagalan dengan melakukan fallback 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.
Menyesuaikan cluster pengguna yang dipulihkan agar sesuai dengan 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 node pool 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 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 Anda untuk menghapus node control plane cluster pengguna kubeception.
Jika Anda menonaktifkan enkripsi rahasia 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 berhasil.

Migrasi MetalLB

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

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

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