Cluster Anthos di VMware kini menjadi Google Distributed Cloud (khusus software) untuk VMware. Untuk mengetahui informasi selengkapnya, lihat ringkasan produk.

Halaman ini diterjemahkan oleh Cloud Translation API.

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 kemampuan skalabilitas, performa, keamanan, dan integrasi yang lebih baik. Oleh karena itu, Google Distributed Cloud terus beradaptasi dan meningkatkan kualitasnya.

Pada versi 1.30, perubahan dan update telah mencapai titik di mana kami sangat menyarankan agar Anda memigrasikan deployment lama untuk memanfaatkan peningkatan yang signifikan. Halaman ini menjelaskan manfaat migrasi dari fitur yang sudah tidak berlaku 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.30
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-poin penting:

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:
  - Control plane non-HA: 1.28 dan yang lebih baru
  - Load balancing seesaw: 1.28 dan yang lebih baru
  - 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 tinggi
  - 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 Antarmuka Jaringan Container (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 penggunaan resource yang efisien, sehingga meningkatkan performa jaringan dan skalabilitas yang lebih baik, terutama untuk cluster atau lingkungan besar dengan permintaan traffic jaringan yang tinggi. Sebaiknya migrasikan 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 ada periode nonaktif untuk workload yang ada. Dengan bermigrasi secara proaktif ke Dataplane V2, Anda dapat memperoleh manfaat dari:

Performa dan Skalabilitas yang Ditingkatkan: Desain yang dioptimalkan dan penggunaan resource yang efisien pada Dataplane V2 dapat meningkatkan performa jaringan dan skalabilitas yang lebih baik, terutama di cluster atau lingkungan besar dengan permintaan traffic jaringan yang tinggi. Hal ini disebabkan oleh penggunaan EBPF, bukan IPTables, yang memungkinkan cluster diskalakan menggunakan peta BPF.
Pengelolaan dan Dukungan yang Disederhanakan: Menstandarkan Dataplane V2 di seluruh Google Distributed Cloud dan GKE dapat menyederhanakan pengelolaan dan pemecahan masalah cluster, karena Anda dapat mengandalkan serangkaian alat dan dokumentasi yang konsisten.
Fitur Jaringan Lanjutan: EgressNAT dan fitur jaringan lanjutan lainnya hanya didukung di Dataplane V2. Semua permintaan jaringan mendatang akan diterapkan 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

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 yang dipaketkan menggunakan load balancer MetalLB.

Mulai versi 1.30, ini adalah satu-satunya opsi untuk membuat cluster baru. Untuk cluster yang 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

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:

Pengontrol F5 (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 asli memiliki batasan berikut:

Ekspresi Terbatas: F5 Big IP terintegrasi membatasi potensi penuh F5 BIG-IP dengan membatasi ekspresi 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, yang 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) Pengontrol CIS OSS (tidak ada perubahan)
Upgrade versi komponen F5	Anda harus mengupgrade cluster untuk mengupgrade komponen F5. Versi komponen yang tersedia terbatas 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 resource yang dikurangi: Tidak seperti Seesaw, MetalLB berjalan langsung di node cluster, sehingga memungkinkan penggunaan dinamis resource cluster untuk load balancing.
Penetapan IP otomatis: Pengontrol MetalLB melakukan pengelolaan alamat IP untuk Layanan, sehingga Anda tidak perlu memilih alamat IP secara manual untuk setiap Layanan.
Distribusi beban di antara node LB: Instance MetalLB yang aktif untuk Layanan yang berbeda dapat berjalan di node yang berbeda.
Fitur yang ditingkatkan dan siap menghadapi masa depan: Pengembangan aktif MetalLB dan integrasinya dengan ekosistem Kubernetes yang lebih luas menjadikannya solusi yang lebih siap menghadapi masa depan dibandingkan dengan Seesaw. Menggunakan MetalLB memastikan bahwa 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 pelanggan
Pelestarian 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 secara 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 di 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 menjadi 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 ditransisikan ke GA pada 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 downtime untuk cluster pengguna.
Pemisahan deployment: Anda dapat menempatkan cluster admin dan pengguna di domain topologi yang berbeda atau beberapa lokasi. Misalnya, dalam model deployment komputasi edge, cluster pengguna mungkin berada di lokasi yang berbeda dengan cluster admin.

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

Membuat bidang kontrol baru di cluster pengguna.
Menyalin data etcd dari bidang kontrol lama.
Mentransisikan node node pool yang ada (juga disebut node pekerja) 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 Panel 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 Komputer Bidang Kontrol	IPAM atau DHCP	IPAM
Jaringan Bidang Kontrol	VLAN cluster admin	VLAN cluster pengguna

Bermigrasi ke cluster admin HA

Secara historis, cluster admin hanya dapat menjalankan satu node bidang kontrol, sehingga menimbulkan risiko bawaan berupa titik tunggal kegagalan. Selain satu node bidang kontrol, cluster admin non-HA juga memiliki dua node add-on. Cluster admin HA memiliki tiga node bidang kontrol tanpa node add-on, sehingga jumlah VM yang diperlukan cluster admin baru tidak berubah, tetapi ketersediaannya ditingkatkan 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.

Bermigrasi ke cluster admin HA memberikan manfaat berikut:

Peningkatan keandalan dan waktu aktif: 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 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 HA menyimpan status cluster terbaru di dalam cluster admin itu sendiri, sehingga memberikan sumber tepercaya yang lebih andal untuk status cluster.

Anda dapat memilih untuk memigrasikan cluster admin non-HA ke cluster admin HA, yang tidak memerlukan periode nonaktif untuk beban kerja pengguna. Proses ini menyebabkan periode nonaktif dan gangguan minimal pada cluster pengguna yang ada, terutama yang terkait dengan pengalihan platform 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 HA 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 secara 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

Migrasi load balancer grup dan bidang kontrol

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

Jika 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 panel kontrol. Mengelompokkan migrasi memberikan manfaat berikut:

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

Prosesnya bervariasi bergantung pada konfigurasi cluster. Secara keseluruhan, lakukan migrasi untuk setiap cluster dalam urutan berikut:

Migrasikan setiap cluster pengguna untuk menggunakan CNI yang direkomendasikan, Dataplane V2.
1. Lakukan perubahan konfigurasi dan perbarui cluster pengguna untuk memicu migrasi cluster pengguna dari Calico ke Dataplane V2.
  
  Catatan: Langkah ini tidak diperlukan untuk cluster admin. Saat Anda mengupgrade cluster admin ke versi 1.30, cluster akan otomatis dimigrasikan ke Dataplane V2.
Migrasikan setiap cluster pengguna untuk menggunakan load balancer dan Controlplane V2 yang direkomendasikan.
1. Buat 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 panel kontrol.
Migrasikan cluster admin untuk menggunakan load balancer yang direkomendasikan dan membuat bidang kontrol sangat tersedia.
1. Buat 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 panel kontrol.
Lakukan langkah-langkah pembersihan opsional, seperti membersihkan VM platform kontrol non-HA.

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