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 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 pembaruan bergantung pada jumlah node dalam kumpulan node terbesar. Untuk menghitung perkiraan kasar setiap pembaruan:
- 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 kefalse
, buat perubahan konfigurasi, lalu jalankangkectl update cluster
untuk bermigrasi ke Dataplane V2. Bersiaplah untuk migrasi load balancer dan bidang kontrol:
- 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. - Jika cluster pengguna menggunakan Seesaw, pilih node pool untuk load balancer MetalLB yang akan digunakan, lalu jalankan
gkectl update cluster
. Update ini hanya akan memperbarui node di kumpulan node yang dipilih.
- Jika cluster admin telah mengaktifkan perbaikan otomatis, nonaktifkan. Kemudian, jalankan
Lakukan semua perubahan konfigurasi yang diperlukan untuk mengupdate load balancer Anda dan untuk bermigrasi 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 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
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
kefalse
. 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 bagiansecretsEncryption
: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 adminUSER_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 di node dalam node pool tersebut.
Di bagian nodePools dalam file konfigurasi cluster pengguna, pilih kumpulan node atau tambahkan kumpulan node baru, dan tetapkan
enableLoadBalancer
ketrue
. 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
: namaNetworkPolicy
yang Anda simpan.NETWORK_POLICY_NAMESPACE
: namespaceNetworkPolicy
.
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
ketrue
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: 3072metalLB: 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
dangateway
di bagiannetwork.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
danloadBalancer.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 dengankubectl 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 jalankangkectl 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.
- Di file konfigurasi cluster pengguna, hapus kolom
disabled: true
. Update cluster pengguna:
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG
- Di file konfigurasi cluster pengguna, hapus kolom
Jika Anda menonaktifkan perbaikan otomatis di cluster admin, aktifkan kembali fitur tersebut.
Dalam file konfigurasi cluster admin, tetapkan
autoRepair.enabled
ketrue
.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