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.

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

Pada versi 1.30, perubahan dan update ini telah mencapai tahap yang mengharuskan kami sebaiknya Anda memigrasikan deployment lama untuk memanfaatkan peningkatan performa. Halaman ini menjelaskan manfaat melakukan migrasi dari versi lama ke fitur terbaru yang direkomendasikan.

Anda memiliki opsi berikut untuk setiap area fitur:

Area fitur	Opsi yang direkomendasikan	Opsi asli
Antarmuka Jaringan Container (CNI)	Pesawat Data V2 (Cilium) (`enableDataplaneV2: true`)	Pesawat Data V1 (Calico) (`enableDataplaneV2: false`)
Load balancer	ManualLB (berfungsi dengan agen Big IP F5) (`loadBalancer.kind: "ManualLB"`) MetalLB (`loadBalancer.kind: "MetalLB"`)	Integrasi Big IP F5¹ (`loadBalancer.kind: "F5BigIP"`) Jungkat-jungkit (`loadBalancer.kind: "Seesaw"`)
Bidang kontrol cluster admin	Cluster admin dengan ketersediaan tinggi (HA) (`adminMaster.replicas: 3`)	cluster admin non-HA (`adminMaster.replicas: 1`)
Bidang kontrol cluster pengguna	Pesawat Kontrol V2 (`enableControlplaneV2: true`)	Cluster pengguna Kubeception (`enableControlplaneV2: false`)

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

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

Jenis cluster	Fitur sudah tidak berlaku	Tambahkan untuk cluster baru	Izinkan upgrade cluster	Migrasi ke fitur baru
Versi 1.30
Admin	non-HA	Tidak	Ya	Ya
	Seesaw	Tidak	Ya	Ya
	Integrasi Big IP F5	Tidak	Ya	Ya
Pengguna	Kubeception	Tidak	Ya	Ya
	Seesaw	Tidak	Ya	Ya
	Integrasi Big IP F5	Tidak	Ya	Ya
	Pesawat Data V1	Tidak	Ya	Ya
Versi 1.29
Admin	non-HA	Tidak	Ya	Ya (Pratinjau)
	Seesaw	Tidak	Ya	Ya
	Integrasi Big IP F5	Ya	Ya	Ya (Pratinjau)
Pengguna	Kubeception	Ya	Ya	Ya (Pratinjau)
	Seesaw	Ya	Ya	Ya
	Integrasi Big IP F5	Ya	Ya	Ya (Pratinjau)
	Pesawat Data V1	Ya	Ya	Tidak
Versi 1.28
Admin	non-HA	Tidak	Ya	Tidak
	Seesaw	Tidak	Ya	Ya
	Integrasi Big IP F5	Ya	Ya	Tidak
Pengguna	Kubeception	Ya	Ya	Tidak
	Seesaw	Ya	Ya	Ya
	Integrasi Big IP F5	Ya	Ya	Tidak
	Pesawat Data V1	Ya	Ya	Tidak

Poin penting:

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

Memigrasikan cluster pengguna ke Dataplane V2

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

Dataplane V2 menyediakan desain yang dioptimalkan dan pemanfaatan sumber daya yang efisien, yang mengarah ke peningkatan kinerja jaringan dan skalabilitas yang lebih baik, terutama untuk cluster atau lingkungan berukuran besar dengan permintaan traffic jaringan yang tinggi. Kami sangat sebaiknya Anda memigrasikan cluster ke Dataplane V2 untuk mendapatkan fitur terbaru, inovasi dan kemampuan jaringan.

Dimulai dengan versi 1.30, Dataplane V2 adalah satu-satunya pilihan CNI untuk membuat klaster.

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

Peningkatan Performa dan Skalabilitas: Dataplane V2 dioptimalkan desain dan pemanfaatan sumber daya yang efisien dapat menghasilkan peningkatan jaringan performa dan skalabilitas yang lebih baik, terutama dalam cluster besar atau lingkungan dengan kebutuhan traffic jaringan yang tinggi. Hal ini karena penggunaan EBPF, bukan IPTables, yang memungkinkan penskalaan cluster menggunakan peta BPF.
Pengelolaan dan Dukungan yang Disederhanakan: Standardisasi pada Dataplane V2 di seluruh Google Distributed Cloud dan GKE dapat menyederhanakan pengelolaan dan pemecahan masalah cluster, karena Anda dapat mengandalkan set alat dan dokumentasi.
Fitur Jaringan Lanjutan: EgressNAT dan fitur jaringan lanjutan lainnya hanya didukung di Dataplane V2. Semua permintaan jaringan pada masa mendatang akan diterapkan di Dataplane V2 feedforward.

	Sebelum migrasi	Setelah migrasi
CNI	Calico	Silium
kube-proxy	Diperlukan 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 seperti F5 BIG-IP atau Citrix. Gunakan "MetalLB" untuk paket load balancing kami solusi.

Mulai versi 1.30, inilah satu-satunya opsi untuk membuat klaster. Untuk cluster yang ada yang menggunakan integrasi F5 Big IP atau paket load balancer Seesaw, kami memberikan panduan migrasi untuk setelan konfigurasi "F5BigIP" ke "ManualLB", dan untuk memigrasikan paket load balancer dari Seesaw menjadi MetalLB.

Memigrasikan setelan konfigurasi untuk load balancer F5 BIG-IP Anda

Rencanakan untuk memigrasi cluster apa pun yang menggunakan integrasi F5 Big IP untuk "ManualLB". Integrasi F5 Big IP menggunakan F5 BIG-IP dengan load balancer agen, yang terdiri dari dua pengontrol berikut:

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

Integrasi F5 Big IP asli memiliki batasan berikut:

Keterbatasan Ekspresi: Integrasi Big IP F5 membatasi potensi penuh F5 BIG-IP dengan membatasi kemampuan API Layanan Google. Hal ini dapat mencegah Anda mengkonfigurasi {i>controller<i} BIG-IP untuk kebutuhan spesifik Anda atau memanfaatkan fitur F5 lanjutan yang mungkin sangat penting untuk aplikasi Anda.
Komponen Lama: Implementasi saat ini bergantung pada versi lama seperti CCCL ConfigMap API dan 1.x CIS. Warisan ini mungkin tidak kompatibel dengan kemajuan terbaru dalam F5's penawaran harga, yang berpotensi menyebabkan hilangnya peluang performa peningkatan kualitas dan peningkatan keamanan.

Perubahan setelah migrasi dari integrasi F5 BIG-IP ke ManualLB mencakup:

	Sebelum migrasi	Setelah migrasi
Komponen agen F5	Pengontrol F5 Pengontrol CIS OSS	Pengontrol F5 (tidak ada perubahan) Pengontrol CIS OSS (tidak ada perubahan)
Upgrade versi komponen F5	Anda harus mengupgrade cluster untuk mengupgrade komponen F5. Tersedia versi komponen terbatas seperti yang telah 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 sumber daya: Tidak seperti Seesaw, MetalLB berjalan langsung pada node cluster, sehingga memungkinkan penggunaan dinamis resource cluster untuk load balancing.
Penetapan IP otomatis: Pengontrol MetalLB melakukan alamat IP untuk Layanan, sehingga Anda tidak perlu memilih alamat IP secara manual untuk setiap Layanan.
Distribusi pemuatan di antara node LB: Instance MetalLB aktif untuk Layanan yang berbeda dapat berjalan pada {i>node<i} yang berbeda.
Fitur yang ditingkatkan dan siap menghadapi masa depan: Pengembangan aktif MetalLB dan integrasi dengan ekosistem Kubernetes yang lebih luas membuatnya yang 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	Extra Seesaw VM (di luar cluster)	Node LB dalam cluster dengan pilihan pelanggan
Preservasi IP Klien	Dapat dilakukan melalui `externalTrafficPolicy: Local`	Dapat dicapai via mode DSR DataplaneV2
Pembuatan layanan	IP Layanan yang ditentukan secara manual	IP Layanan yang ditetapkan secara otomatis dari kumpulan alamat

Migrasikan cluster pengguna ke Controlplane V2 dan cluster admin ke ketersediaan tinggi (HA)

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

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

Memigrasikan cluster pengguna ke Controlplane V2

Secara historis, klaster pengguna telah menggunakan {i>kubeception<i}. Versi 1.13 diperkenalkan Controlplane V2 sebagai fitur pratinjau, yang dialihkan ke GA pada versi 1.14. Sejak versi 1.15, Controlplane V2 telah menjadi opsi {i>default<i} untuk membuat pengguna cluster, dan Controlplane V2 adalah satu-satunya pilihan di versi 1.30.

Dibandingkan dengan kubeception, manfaat Controlplane V2 antara lain:

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

Selama migrasi, tidak ada periode nonaktif untuk cluster pengguna yang ada sebagian besar workload standar dan berbasis cloud. Bergantung pada lingkungan vSphere yang mendasarinya, bidang kontrol akan mengalami periode nonaktif minimal selama peralihan ke Controlplane V2. Tujuan proses migrasi akan melakukan hal berikut:

Membuat bidang kontrol baru di cluster pengguna.
Menyalin data {i>etcd<i} dari bidang kontrol lama.
Mentransisikan node kumpulan node 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	Statefulsets/Deployment cluster admin (namespace cluster pengguna)	Cluster pengguna statis pod (namespace sistem kube)
Pod Bidang Kontrol Lainnya	Statefulsets/Deployment cluster admin (namespace cluster pengguna)	Statefulsets/Deployment cluster pengguna (namespace sistem kube)
VIP Pesawat Kontrol	Layanan Load Balancer cluster Admin	keepalive + haproxy (cluster pengguna statis pod)
Data Etcd	Volume Persisten cluster Admin	Disk data
Pengelolaan IP Mesin Pesawat Kontrol	IPAM atau DHCP	IPAM
Jaringan Pesawat Kontrol	VLAN cluster admin	VLAN cluster pengguna

Bermigrasi ke cluster admin ketersediaan tinggi

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

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

Keandalan dan waktu beroperasi yang lebih baik: Konfigurasi HA menghilangkan titik tunggal kegagalan, yang memungkinkan cluster admin operasional meskipun jika salah satu node bidang kontrol mengalami masalah.
Pengalaman upgrade dan update yang ditingkatkan: Semua langkah yang diperlukan untuk upgrade dan update cluster admin kini dijalankan di dalam cluster, bukan dalam VM admin terpisah. Hal ini memastikan bahwa upgrade dan update dapat terus berlanjut meskipun sesi awal ke VM admin mungkin terganggu.
Sumber tepercaya yang andal untuk status cluster: Cluster admin non-HA mengandalkan "file checkpoint" yang tidak umum untuk menyimpan status cluster admin. Sebaliknya, cluster admin HA menyimpan status cluster terbaru di dalam cluster admin itu sendiri, untuk menyediakan 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 waktu henti yang minimal dan gangguan terhadap klaster pengguna yang ada, terutama yang terkait dengan kontrol peralihan pesawat. Proses migrasi akan melakukan hal-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 di file konfigurasi cluster admin	Dibuat otomatis pada direktori: `/anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk`
VIP Pesawat Kontrol	Ditetapkan oleh loadBalancer.kind di file konfigurasi cluster admin	keepalive + haproxy
Alokasi alamat IP untuk node bidang kontrol cluster admin	DHCP atau statis, bergantung pada network.ipMode.type	3 alamat IP statis