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

Merencanakan migrasi cluster ke fitur yang direkomendasikan

Ringkasan

Google Distributed Cloud didasarkan pada Kubernetes dan banyak teknologi terkait lainnya, yang terus diperbarui dan ditingkatkan untuk memberikan skalabilitas, performa, keamanan, dan kemampuan integrasi yang lebih baik. Oleh karena itu, Google Distributed Cloud terus beradaptasi dan berkembang.

Pada versi 1.30, perubahan dan update telah mencapai titik di mana kami sangat menyarankan Anda untuk memigrasikan deployment lama guna memanfaatkan peningkatan yang signifikan. Halaman ini menjelaskan manfaat bermigrasi dari fitur lama ke fitur terbaru yang direkomendasikan.

Anda memiliki opsi berikut untuk setiap area fitur:

Area fitur	Opsi yang direkomendasikan	Opsi asli
Container Network Interface (CNI)	Dataplane V2 (`enableDataplaneV2: true`)	Dataplane V1 (Calico) (`enableDataplaneV2: false`)
Load balancer	`ManualLB` (berfungsi dengan agen F5 Big IP) (`loadBalancer.kind: "ManualLB"`) MetalLB (`loadBalancer.kind: "MetalLB"`)	F5 Big IP terintegrasi¹ (`loadBalancer.kind: "F5BigIP"`) Seesaw (`loadBalancer.kind: "Seesaw"`)
Bidang kontrol cluster admin	Cluster admin ketersediaan tinggi (HA) (`adminMaster.replicas: 3`)	Cluster admin non-HA (`adminMaster.replicas: 1`)
Bidang kontrol cluster pengguna	Controlplane V2 (`enableControlplaneV2: true`)	Cluster pengguna Kubeception (`enableControlplaneV2: false`)

^{1 F5 BIG-IP Terintegrasi mengacu pada
loadBalancer.kind: "F5BigIP" dan setelan terkait di bagian
loadBalancer.f5BigIP dalam file konfigurasi cluster
Anda.}

Tabel berikut menunjukkan matriks dukungan untuk fitur ini di cluster admin dan pengguna:

Jenis cluster	Fitur usang	Menambahkan untuk cluster baru	Mengizinkan upgrade cluster	Migrasi ke fitur baru
Versi 1.32 dan yang lebih baru
Admin	Non-HA	Tidak	Tidak	T/A
	Seesaw	Tidak	Tidak	T/A
	F5 Big IP Terintegrasi	Tidak	Tidak	T/A
Pengguna	Kubeception	Tidak	Tidak	T/A
	Seesaw	Tidak	Tidak	T/A
	F5 Big IP Terintegrasi	Tidak	Tidak	T/A
	Dataplane V1	Tidak	Tidak	T/A
Versi 1.30 dan 1.31
Admin	Non-HA	Tidak	Ya	Ya
	Seesaw	Tidak	Ya	Ya
	F5 Big IP Terintegrasi	Tidak	Ya	Ya
Pengguna	Kubeception	Tidak	Ya	Ya
	Seesaw	Tidak	Ya	Ya
	F5 Big IP Terintegrasi	Tidak	Ya	Ya
	Dataplane V1	Tidak	Ya	Ya
Versi 1.29
Admin	Non-HA	Tidak	Ya	Ya (Pratinjau)
	Seesaw	Tidak	Ya	Ya
	F5 Big IP Terintegrasi	Ya	Ya	Ya (Pratinjau)
Pengguna	Kubeception	Ya	Ya	Ya (Pratinjau)
	Seesaw	Ya	Ya	Ya
	F5 Big IP Terintegrasi	Ya	Ya	Ya (Pratinjau)
	Dataplane V1	Ya	Ya	Tidak
Versi 1.28
Admin	Non-HA	Tidak	Ya	Tidak
	Seesaw	Tidak	Ya	Ya
	F5 Big IP Terintegrasi	Ya	Ya	Tidak
Pengguna	Kubeception	Ya	Ya	Tidak
	Seesaw	Ya	Ya	Ya
	F5 Big IP Terintegrasi	Ya	Ya	Tidak
	Dataplane V1	Ya	Ya	Tidak

Poin utama:

Mulai versi 1.30, semua solusi migrasi tersedia untuk memigrasikan cluster ke alternatif yang direkomendasikan.
Saat membuat cluster baru, berikut adalah versi yang tidak mengizinkan fitur asli:
- Cluster admin:
  - Bidang kontrol non-HA: 1.28 dan yang lebih tinggi
  - Load balancing Seesaw: 1.28 dan yang lebih tinggi
  - F5 Big IP terintegrasi: 1.30 dan yang lebih tinggi
- Cluster pengguna:
  - Kubeception: 1.30 dan yang lebih tinggi
  - Seesaw: 1.30 dan yang lebih baru
  - F5 Big IP terintegrasi: 1.30 dan yang lebih tinggi
  - Dataplane V1: 1.30 dan yang lebih tinggi
Anda masih dapat mengupgrade cluster yang ada dengan fitur asli.

Memigrasikan cluster pengguna ke Dataplane V2

Anda dapat memilih Container Network Interface (CNI) yang menawarkan fitur jaringan container, baik Calico maupun Dataplane V2. Dataplane V2, implementasi CNI Google, didasarkan pada Cilium dan digunakan di Google Kubernetes Engine (GKE) dan Google Distributed Cloud.

Dataplane V2 memberikan desain yang dioptimalkan dan pemanfaatan resource yang efisien, sehingga menghasilkan peningkatan performa jaringan dan skalabilitas yang lebih baik, terutama untuk cluster besar atau lingkungan dengan permintaan traffic jaringan yang tinggi. Kami sangat menyarankan Anda untuk memigrasikan cluster ke Dataplane V2 untuk mendapatkan fitur, inovasi jaringan, dan kemampuan terbaru.

Mulai versi 1.30, Dataplane V2 adalah satu-satunya opsi CNI untuk membuat cluster baru.

Transisi dari Calico ke Dataplane V2 memerlukan perencanaan dan koordinasi, tetapi dirancang agar tidak menimbulkan periode nonaktif untuk workload yang ada. Dengan bermigrasi secara proaktif ke Dataplane V2, Anda dapat memperoleh manfaat dari:

Peningkatan Performa dan Skalabilitas: Desain Dataplane V2 yang dioptimalkan dan pemanfaatan resource yang efisien dapat meningkatkan performa jaringan dan skalabilitas yang lebih baik, terutama di cluster besar atau lingkungan dengan permintaan traffic jaringan yang tinggi. Hal ini karena penggunaan EBPF, bukan IPTables, yang memungkinkan cluster diskalakan menggunakan peta BPF.
Pengelolaan dan Dukungan yang Lebih Sederhana: Standardisasi pada Dataplane V2 di Google Distributed Cloud dan GKE dapat menyederhanakan pengelolaan cluster dan pemecahan masalah, karena Anda dapat mengandalkan serangkaian alat dan dokumentasi yang konsisten.
Fitur Jaringan Lanjutan: EgressNAT dan fitur jaringan lanjutan lainnya hanya didukung di Dataplane V2. Setiap permintaan jaringan di masa mendatang akan diimplementasikan di lapisan Dataplane V2.

	Sebelum migrasi	Setelah migrasi
kube-proxy	Wajib dan di-deploy secara otomatis	Tidak diperlukan dan tidak di-deploy
Pemilihan rute	kube-proxy + iptables	eBPF

Hapus anotasi features.onprem.cluster.gke.io/dpv2-migration dari resource kustom OnPremUserCluster dan resource kustom OnPremAdminCluster (jika cluster admin Anda dimigrasikan dari Calico selama upgrade dari versi 1.29 ke 1.30) setelah Anda memverifikasi bahwa migrasi dari Calico ke Dataplane V2 telah selesai dan Anda tidak perlu melakukan roll back ke Calico. Menghapus anotasi ini sebelum Anda menskalakan atau mengupgrade cluster akan memungkinkan pengontrol cluster menghapus DaemonSet calico-node dan calico-route-daemon yang tidak aktif secara permanen. Anda tidak perlu melakukan langkah ini untuk cluster yang dibuat dengan Dataplane V2 diaktifkan. Untuk mengetahui informasi selengkapnya, lihat Menghapus DaemonSet Calico yang tidak aktif.

Memigrasikan jenis load balancer

Jenis load balancer yang direkomendasikan (loadBalancer.kind) adalah "ManualLB" dan "MetalLB". Gunakan "ManualLB" jika Anda memiliki load balancer pihak ketiga seperti F5 BIG-IP atau Citrix. Gunakan "MetalLB" untuk solusi load balancing paket kami menggunakan load balancer MetalLB.

Mulai versi 1.30, ini adalah satu-satunya opsi untuk membuat cluster baru. Untuk cluster yang sudah ada yang menggunakan F5 Big IP terintegrasi atau load balancer Seesaw yang dipaketkan, kami menyediakan panduan migrasi untuk memigrasikan setelan konfigurasi "F5BigIP" ke "ManualLB", dan untuk memigrasikan load balancer yang dipaketkan dari Seesaw ke MetalLB.

Memigrasikan setelan konfigurasi untuk load balancer F5 BIG-IP Anda

Rencanakan untuk memigrasikan cluster apa pun yang menggunakan F5 Big IP terintegrasi ke ManualLB. F5 Big IP terintegrasi menggunakan F5 BIG-IP dengan agen load balancer, yang terdiri dari dua pengontrol berikut:

F5 Controller (pod prefix: load-balancer-f5): merekonsiliasi Layanan Kubernetes jenis LoadBalancer ke dalam format ConfigMap F5 Common Controller Core Library (CCCL).
F5 BIG-IP CIS Controller v1.14 (pod prefix: k8s-bigip-ctlr-deployment): menerjemahkan ConfigMap menjadi konfigurasi load balancer F5.

F5 Big IP terintegrasi yang asli memiliki batasan berikut:

Ekspresivitas Terbatas: F5 Big IP yang terintegrasi membatasi potensi penuh F5 BIG-IP dengan membatasi ekspresivitas Service API. Hal ini dapat mencegah Anda mengonfigurasi pengontrol BIG-IP sesuai kebutuhan spesifik atau memanfaatkan fitur F5 lanjutan yang mungkin penting untuk aplikasi Anda.
Komponen Lama: Implementasi saat ini mengandalkan teknologi lama seperti CCCL ConfigMap API dan CIS 1.x. Komponen lama ini mungkin tidak kompatibel dengan kemajuan terbaru dalam penawaran F5, sehingga berpotensi menyebabkan hilangnya peluang untuk peningkatan performa dan peningkatan keamanan.

Perubahan setelah bermigrasi dari F5 BIG-IP terintegrasi ke ManualLB meliputi:

	Sebelum migrasi	Setelah migrasi
Komponen agen F5	Pengontrol F5 Pengontrol CIS OSS	F5 Controller (tidak ada perubahan) OSS CIS Controller (tidak ada perubahan)
Upgrade versi komponen F5	Anda harus mengupgrade cluster untuk mengupgrade komponen F5. Versi komponen yang tersedia dibatasi seperti yang dijelaskan sebelumnya.	Anda dapat mengupgrade versi komponen F5 sesuai kebutuhan.
Pembuatan layanan	Ditangani oleh agen F5	Ditangani oleh agen F5 (tidak ada perubahan)

Bermigrasi dari Seesaw ke MetalLB

MetalLB memberikan keuntungan berikut dibandingkan dengan Seesaw:

Pengelolaan yang disederhanakan dan pengurangan resource: Tidak seperti Seesaw, MetalLB berjalan langsung di node cluster, sehingga memungkinkan penggunaan resource cluster secara dinamis untuk load balancing.
Penetapan IP otomatis: Pengontrol MetalLB melakukan pengelolaan alamat IP untuk Service, sehingga Anda tidak perlu memilih alamat IP secara manual untuk setiap Service.
Distribusi beban di antara node LB: Instance aktif MetalLB untuk berbagai Service dapat berjalan di node yang berbeda.
Fitur yang ditingkatkan dan kesiapan untuk masa mendatang: Pengembangan aktif MetalLB dan integrasinya dengan ekosistem Kubernetes yang lebih luas menjadikannya solusi yang lebih siap untuk masa mendatang dibandingkan dengan Seesaw. Dengan menggunakan MetalLB, Anda dapat memanfaatkan kemajuan terbaru dalam teknologi load balancing.

	Sebelum migrasi	Setelah migrasi
Node LB	VM Seesaw tambahan (di luar cluster)	Node LB dalam cluster dengan pilihan kustom
Preservasi IP Klien	Dapat dicapai melalui `externalTrafficPolicy: Local`	Dapat dicapai melalui mode DSR DataplaneV2
Pembuatan layanan	IP Layanan yang ditentukan secara manual	IP Layanan yang ditetapkan otomatis dari kumpulan alamat

Memigrasikan cluster pengguna ke Controlplane V2 dan cluster admin ke HA

Bidang kontrol yang direkomendasikan untuk cluster pengguna adalah Controlplane V2. Dengan Controlplane V2, bidang kontrol berjalan di satu atau beberapa node dalam cluster pengguna itu sendiri. Dengan bidang kontrol lama, yang disebut sebagai kubeception, bidang kontrol untuk cluster pengguna berjalan di cluster admin. Untuk membuat cluster admin ketersediaan tinggi (HA), cluster pengguna Anda harus mengaktifkan Controlplane V2.

Mulai versi 1.30, cluster pengguna baru harus mengaktifkan Controlplane V2, dan cluster admin baru akan memiliki ketersediaan tinggi (HA). Upgrade cluster pengguna dengan bidang kontrol lama masih didukung, begitu juga upgrade cluster admin non-HA.

Memigrasikan cluster pengguna ke Controlplane V2

Secara historis, cluster pengguna telah menggunakan kubeception. Versi 1.13 memperkenalkan Controlplane V2 sebagai fitur pratinjau, yang beralih ke GA di versi 1.14. Sejak versi 1.15, Controlplane V2 telah menjadi opsi default untuk membuat cluster pengguna, dan Controlplane V2 adalah satu-satunya opsi di versi 1.30.

Dibandingkan dengan kubeception, manfaat Controlplane V2 meliputi:

Konsistensi arsitektur: Cluster admin dan cluster pengguna menggunakan arsitektur yang sama.
Isolasi kegagalan: Kegagalan cluster admin tidak memengaruhi cluster pengguna.
Pemisahan operasional: Upgrade cluster admin tidak menyebabkan periode nonaktif untuk cluster pengguna.
Pemisahan deployment: Anda dapat menempatkan cluster admin dan pengguna di domain topologi yang berbeda atau beberapa lokasi. Misalnya, dalam model deployment edge computing, cluster pengguna mungkin berada di lokasi yang berbeda dengan cluster admin.

Selama migrasi, tidak ada periode nonaktif untuk workload cluster pengguna yang ada. Bergantung pada lingkungan vSphere yang mendasarinya, bidang kontrol akan mengalami periode nonaktif minimal selama peralihan ke Controlplane V2. Proses migrasi melakukan hal berikut:

Membuat bidang kontrol baru di cluster pengguna.
Menyalin data etcd dari bidang kontrol lama.
Mentransisikan node pool yang ada (juga disebut worker node) ke bidang kontrol baru.

	Sebelum migrasi	Setelah migrasi
Objek Node Kubernetes Bidang Kontrol	Node cluster admin	Node cluster pengguna
Pod Bidang Kontrol Kubernetes	Statefulset/Deployment cluster admin (namespace cluster pengguna)	Pod statis cluster pengguna (namespace kube-system)
Pod Bidang Kontrol Lainnya	Statefulset/Deployment cluster admin (namespace cluster pengguna)	Statefulset/Deployment cluster pengguna (namespace kube-system)
VIP Bidang Kontrol	Layanan Load Balancer cluster admin	keepalived + haproxy (pod statis cluster pengguna)
Data Etcd	Volume Persisten cluster admin	Disk data
Pengelolaan IP Mesin Bidang Kontrol	IPAM atau DHCP	IPAM
Jaringan Bidang Kontrol	VLAN cluster admin	VLAN cluster pengguna

Bermigrasi ke cluster admin dengan ketersediaan tinggi (HA)

Secara historis, cluster admin hanya dapat menjalankan satu node bidang kontrol, sehingga menimbulkan risiko titik tunggal kegagalan yang melekat. Selain satu node bidang kontrol, cluster admin Non-HA juga memiliki dua node add-on. Cluster admin dengan ketersediaan tinggi (HA) memiliki tiga node bidang kontrol tanpa node add-on, sehingga jumlah VM yang diperlukan cluster admin baru tidak berubah, tetapi ketersediaannya meningkat secara signifikan. Mulai versi 1.16, Anda dapat menggunakan cluster admin ketersediaan tinggi (HA), yang menjadi satu-satunya opsi untuk pembuatan cluster baru di versi 1.28.

Migrasi ke cluster admin dengan ketersediaan tinggi (HA) memberikan manfaat berikut:

Peningkatan keandalan dan waktu beroperasi: Konfigurasi HA menghilangkan titik tunggal kegagalan, sehingga cluster admin dapat tetap beroperasi meskipun salah satu node bidang kontrol mengalami masalah.
Pengalaman upgrade dan update yang ditingkatkan: Semua langkah yang diperlukan untuk mengupgrade dan mengupdate cluster admin kini dijalankan dalam cluster, bukan di workstation admin terpisah. Hal ini memastikan upgrade dan update terus berlanjut meskipun sesi awal ke workstation admin mungkin terganggu.
Sumber tepercaya untuk status cluster: Cluster admin non-HA mengandalkan "file checkpoint" out-of-band untuk menyimpan status cluster admin. Sebaliknya, cluster admin dengan ketersediaan tinggi (HA) menyimpan status cluster terbaru di dalam cluster admin itu sendiri, sehingga memberikan sumber kebenaran yang lebih andal untuk status cluster.

Anda dapat memilih untuk memigrasikan cluster admin Non-HA ke cluster admin HA, yang tidak melibatkan periode nonaktif untuk workload pengguna. Proses ini menyebabkan periode nonaktif dan gangguan minimal pada cluster pengguna yang ada, terutama terkait dengan peralihan bidang kontrol. Proses migrasi melakukan hal berikut:

Membuat bidang kontrol HA baru.
Memulihkan data etcd dari cluster Non-HA yang ada.
Mentransisikan cluster pengguna ke cluster admin dengan ketersediaan tinggi (HA) yang baru.

	Sebelum migrasi	Setelah migrasi
Replika node bidang kontrol	1	3
Node add-on	2	0
Ukuran disk data	100GB * 1	25GB * 3
Jalur disk data	Ditetapkan oleh vCenter.dataDisk dalam file konfigurasi cluster admin	Dibuat otomatis di direktori: `/anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk`
VIP Bidang Kontrol	Ditetapkan oleh loadBalancer.kind dalam file konfigurasi cluster admin	keepalived + haproxy
Alokasi alamat IP untuk node bidang kontrol cluster admin	DHCP atau statis, bergantung pada network.ipMode.type	3 alamat IP statis

Mengelompokkan migrasi load balancer dan bidang kontrol

Biasanya, saat mengupdate cluster, sebaiknya Anda mengupdate hanya satu fitur atau setelan dalam satu waktu. Namun, di versi 1.30 dan yang lebih tinggi, Anda dapat mengelompokkan perubahan konfigurasi ke migrasi untuk load balancer dan bidang kontrol, lalu mengupdate cluster sekali saja untuk melakukan kedua perubahan tersebut.

Jika Anda memiliki cluster pengguna yang menggunakan CNI lama, Anda harus bermigrasi ke DataPlane V2 terlebih dahulu. Setelah itu, Anda dapat mengelompokkan migrasi untuk load balancer dan bidang kontrol. Pengelompokan migrasi memberikan manfaat berikut:

Proses yang lebih sederhana: Jika Anda perlu memigrasikan bidang kontrol dan load balancer, biasanya Anda hanya perlu mengupdate cluster sekali. Anda juga tidak perlu memutuskan fitur mana yang perlu dimigrasikan terlebih dahulu.
Mengurangi periode nonaktif secara keseluruhan: Migrasi tertentu melibatkan periode nonaktif bidang kontrol, sehingga mengelompokkan migrasi ini ke dalam satu operasi update akan mengurangi periode nonaktif secara keseluruhan dibandingkan dengan melakukan update individual berurutan.

Prosesnya bervariasi, bergantung pada konfigurasi cluster. Secara keseluruhan, lakukan migrasi untuk setiap cluster seperti yang dijelaskan dalam langkah-langkah berikut:

Migrasikan setiap cluster pengguna untuk menggunakan CNI yang direkomendasikan, Dataplane V2.
1. Lakukan perubahan konfigurasi dan update cluster pengguna untuk memicu migrasi cluster pengguna dari CNI lama, Calico, ke Dataplane V2.
  
  Catatan: Langkah ini tidak diperlukan untuk cluster admin. Saat Anda mengupgrade cluster admin ke versi 1.30, cluster tersebut akan otomatis dimigrasikan ke Dataplane V2.
2. Setelah Anda memverifikasi bahwa Anda telah menyelesaikan migrasi Dataplane V2 dan Anda tidak perlu 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). Menghapus anotasi ini sebelum Anda menskalakan atau mengupgrade cluster akan memungkinkan pengontrol cluster menghapus DaemonSet calico-node dan calico-route-daemon yang tidak aktif secara permanen. Untuk mengetahui petunjuknya, lihat Menghapus DaemonSet Calico yang tidak aktif.
Migrasikan setiap cluster pengguna dari load balancer (LB) lama dan bidang kontrol (CP) lama untuk menggunakan load balancer yang direkomendasikan dan Controlplane V2.
1. Lakukan perubahan konfigurasi untuk menggunakan load balancer yang direkomendasikan (MetalLB atau ManualLB).
2. Lakukan perubahan konfigurasi untuk mengaktifkan Controlplane V2.
3. Update cluster pengguna untuk memigrasikan load balancer dan bidang kontrol.
Migrasikan cluster admin untuk menggunakan load balancer yang direkomendasikan dan untuk membuat bidang kontrol dengan tingkat ketersediaan tinggi.
1. Lakukan perubahan konfigurasi untuk menggunakan load balancer yang direkomendasikan (MetalLB atau ManualLB).
2. Lakukan perubahan konfigurasi untuk memigrasikan bidang kontrol cluster admin dari Non-HA ke HA.
3. Update cluster admin untuk memigrasikan load balancer dan bidang kontrol.
Lakukan langkah-langkah pembersihan opsional, seperti membersihkan VM bidang kontrol Non-HA.

Diagram berikut menggambarkan langkah-langkah migrasi:

Langkah-langkah untuk bermigrasi ke fitur yang direkomendasikan

Jika cluster admin dan semua cluster pengguna Anda menggunakan versi 1.30 atau yang lebih tinggi, Anda dapat menggunakan proses migrasi grup. Untuk mengetahui langkah-langkah mendetail, lihat panduan berikut: