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) |
|
|
Load balancer |
|
|
Bidang kontrol cluster admin |
|
|
Bidang kontrol cluster pengguna |
|
|
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 tetap 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 melibatkan 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 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 |
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 |
|
|
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 dari 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.
Lakukan perubahan konfigurasi dan perbarui cluster pengguna untuk memicu migrasi cluster pengguna dari Calico ke Dataplane V2.
Migrasikan setiap cluster pengguna untuk menggunakan load balancer dan Controlplane V2 yang direkomendasikan.
- Buat perubahan konfigurasi untuk menggunakan load
balancer yang direkomendasikan (
MetalLB
atauManualLB
). - Lakukan perubahan konfigurasi untuk mengaktifkan Controlplane V2.
- Update cluster pengguna untuk memigrasikan load balancer dan panel kontrol.
- Buat perubahan konfigurasi untuk menggunakan load
balancer yang direkomendasikan (
Migrasikan cluster admin untuk menggunakan load balancer yang direkomendasikan dan membuat bidang kontrol sangat tersedia.
- Buat perubahan konfigurasi untuk menggunakan load
balancer yang direkomendasikan (
MetalLB
atauManualLB
). - Lakukan perubahan konfigurasi untuk memigrasikan bidang kontrol cluster admin dari non-HA ke HA.
- Update cluster admin untuk memigrasikan load balancer dan panel kontrol.
- Buat perubahan konfigurasi untuk menggunakan load
balancer yang direkomendasikan (
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:
- Memigrasikan cluster pengguna ke fitur yang direkomendasikan
- Memigrasikan cluster admin ke fitur yang direkomendasikan