Merencanakan migrasi cluster ke fitur yang direkomendasikan

Ringkasan

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

Pada versi 1.30, perubahan dan update telah mencapai titik di mana kami sangat menganjurkan agar Anda memigrasikan deployment lama untuk memanfaatkan peningkatan signifikan. Halaman ini menjelaskan manfaat bermigrasi 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 terintegrasi1
    (loadBalancer.kind: "F5BigIP")
  • Seesaw
    (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
  • 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 yang sudah tidak berlaku Menambahkan untuk cluster baru Mengizinkan upgrade cluster Migrasi ke fitur baru
Versi 1.30 dan yang lebih tinggi
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 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 pemanfaatan resource yang efisien, sehingga meningkatkan performa jaringan dan skalabilitas yang lebih baik, terutama untuk cluster besar atau lingkungan dengan permintaan traffic jaringan yang tinggi. Sebaiknya lakukan migrasi cluster ke Dataplane V2 untuk mendapatkan fitur, inovasi, dan kemampuan jaringan 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 menyebabkan 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 dalam cluster besar atau lingkungan dengan permintaan traffic jaringan yang tinggi. Hal ini disebabkan oleh penggunaan EBPF, bukan IPTables, yang memungkinkan cluster melakukan penskalaan menggunakan peta BPF.

  • Pengelolaan dan Dukungan yang Disederhanakan: Standardisasi Dataplane V2 di 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 gabungan kami menggunakan load balancer MetalLB.

Mulai versi 1.30, opsi 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

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).
  • Pengontrol CIS F5 BIG-IP v1.14 (pod prefix: k8s-bigip-ctlr-deployment): menerjemahkan ConfigMap menjadi konfigurasi load balancer F5.

F5 Big IP terintegrasi asli memiliki batasan berikut:

  • Ekspresivitas Terbatas: F5 Big IP terintegrasi membatasi potensi penuh F5 BIG-IP dengan membatasi ekspresivitas Service API. Hal ini dapat mencegah Anda mengonfigurasi pengontrol BIG-IP sesuai kebutuhan spesifik Anda 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
  • Pengontrol F5 (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 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 Layanan, sehingga Anda tidak perlu memilih alamat IP secara manual untuk setiap Layanan.
  • Distribusi beban di antara node LB: Instance aktif MetalLB untuk Layanan yang berbeda dapat berjalan di node yang berbeda.
  • Fitur yang ditingkatkan dan siap untuk masa depan: Pengembangan aktif MetalLB dan integrasinya dengan ekosistem Kubernetes yang lebih luas menjadikannya solusi yang lebih siap untuk masa depan 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 pelanggan
Mempertahankan 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 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 dengan 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 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 bertransisi 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 waktu 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 beban kerja cluster pengguna yang ada. Bergantung pada lingkungan vSphere yang mendasarinya, bidang 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.
  • Mengalihkan 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 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 Mesin Bidang Kontrol IPAM atau DHCP IPAM
Jaringan Bidang Kontrol VLAN cluster admin VLAN cluster pengguna

Bermigrasi ke cluster admin HA

Sebelumnya, 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 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.

Bermigrasi ke cluster admin HA memberikan manfaat berikut:

  • Peningkatan keandalan dan waktu aktif: Konfigurasi HA menghilangkan titik tunggal kegagalan, sehingga memungkinkan cluster admin 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 titik pemeriksaan" di luar band untuk menyimpan status cluster admin. Sebaliknya, cluster admin 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 menyebabkan periode nonaktif untuk beban kerja pengguna. Proses ini menyebabkan periode nonaktif dan gangguan minimal pada cluster pengguna yang ada, terutama terkait dengan pengalihan control plane. Proses migrasi melakukan hal berikut:

  • Membuat bidang kontrol HA baru.
  • Memulihkan data etcd dari cluster non-HA yang ada.
  • Mengalihkan 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 bawah 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 memperbarui cluster, sebaiknya perbarui 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 memperbarui cluster hanya sekali untuk melakukan kedua perubahan.

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 harus 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 secara berurutan.

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

  1. 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 CNI lama, Calico, ke Dataplane V2.

  2. 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. Perbarui cluster pengguna untuk memigrasikan load balancer dan bidang kontrol.

  3. Migrasikan cluster admin untuk menggunakan load balancer yang direkomendasikan dan untuk membuat bidang kontrol sangat tersedia.

    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. Perbarui cluster admin untuk memigrasikan load balancer dan bidang kontrol.

  4. Lakukan langkah-langkah pembersihan opsional, seperti membersihkan VM control plane 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: