Halaman ini menjelaskan opsi ketersediaan tinggi di Google Distributed Cloud.
Fungsi inti
GKE di VMware mencakup cluster admin dan satu atau beberapa cluster pengguna.
Cluster admin mengelola siklus proses cluster pengguna, termasuk pembuatan, update, upgrade, dan penghapusan cluster pengguna. Di cluster admin, master admin mengelola node pekerja admin, yang mencakup master pengguna (node yang menjalankan bidang kontrol cluster pengguna terkelola) dan node add-on (node yang menjalankan komponen add-on yang mendukung fungsi cluster admin).
Untuk setiap cluster pengguna, cluster admin memiliki satu node non-HA atau tiga node HA yang menjalankan bidang kontrol. Bidang kontrol mencakup server Kubernetes API, penjadwal Kubernetes, pengelola pengontrol Kubernetes, dan beberapa pengontrol penting untuk cluster pengguna.
Ketersediaan bidang kontrol cluster pengguna sangat penting untuk operasi workload seperti pembuatan workload, peningkatan dan penurunan skala, serta penghentian. Dengan kata lain, pemadaman bidang kontrol tidak akan mengganggu workload yang sedang berjalan, tetapi workload yang ada tidak memiliki kemampuan pengelolaan dari server Kubernetes API jika bidang kontrolnya tidak ada.
Workload dan layanan dalam container di-deploy di node pekerja cluster pengguna. Setiap node pekerja tunggal seharusnya tidak penting untuk ketersediaan aplikasi selama aplikasi di-deploy dengan pod redundan yang dijadwalkan di beberapa node pekerja.
Mengaktifkan ketersediaan tinggi
vSphere dan Google Distributed Cloud menyediakan sejumlah fitur yang berkontribusi terhadap ketersediaan tinggi (HA).
vSphere HA dan vMotion
Sebaiknya aktifkan dua fitur berikut di cluster vCenter yang menghosting cluster Google Distributed Cloud Anda:
Fitur ini meningkatkan ketersediaan dan pemulihan jika host ESXi gagal.
vCenter HA menggunakan beberapa host ESXi yang dikonfigurasi sebagai cluster untuk memberikan pemulihan
cepat dari pemadaman layanan dan HA hemat biaya untuk aplikasi
yang berjalan di virtual machine. Sebaiknya sediakan cluster vCenter dengan host tambahan dan aktifkan Pemantauan Host HA vSphere dengan Host Failure Response yang ditetapkan ke Restart VMs. VM Anda kemudian dapat otomatis dimulai ulang pada host lain yang tersedia jika terjadi kegagalan host ESXi.
vMotion memungkinkan migrasi langsung VM tanpa periode nonaktif dari satu host ESXi ke host ESXi lainnya. Untuk pemeliharaan host terencana, Anda dapat menggunakan migrasi langsung vMotion untuk menghindari periode nonaktif aplikasi sepenuhnya dan memastikan kelangsungan bisnis.
Cluster Admin
Google Distributed Cloud mendukung pembuatan cluster admin dengan ketersediaan tinggi (HA). Cluster admin HA memiliki tiga node yang menjalankan komponen bidang kontrol. Untuk mengetahui informasi tentang persyaratan dan batasan, lihat Cluster admin dengan ketersediaan tinggi.
Perlu diperhatikan bahwa ketidaktersediaan bidang kontrol cluster admin tidak memengaruhi fungsi cluster pengguna yang ada atau workload apa pun yang berjalan di cluster pengguna.
Ada dua node add-on di cluster admin. Jika salah satunya tidak aktif, instance satunya lagi
masih dapat menyalurkan operasi cluster admin. Untuk redundansi, Google Distributed Cloud menyebarkan Layanan add-on penting, seperti kube-dns, di kedua node add-on.
Jika Anda menetapkan antiAffinityGroups.enabled ke true di file konfigurasi cluster admin, Google Distributed Cloud akan otomatis membuat aturan anti-afinitas vSphere DRS untuk node add-on, yang menyebabkannya tersebar di dua host fisik untuk HA.
Cluster pengguna
Anda dapat mengaktifkan HA untuk cluster pengguna dengan menetapkan masterNode.replicas ke 3 di file konfigurasi cluster pengguna. Jika cluster pengguna mengaktifkan Controlplane V2 (direkomendasikan), 3 node bidang kontrol akan berjalan di cluster pengguna.
Cluster pengguna kubeception HA lama menjalankan tiga node bidang kontrol di cluster admin. Setiap node bidang kontrol
juga menjalankan replika etcd. Cluster pengguna akan terus berfungsi
selama ada satu bidang kontrol yang berjalan dan kuorum dll. Kuorum etcd mengharuskan dua dari tiga replika etcd berfungsi.
Jika Anda menetapkan antiAffinityGroups.enabled ke true di file konfigurasi cluster admin, Google Distributed Cloud akan otomatis membuat aturan anti-afinitas DRS vSphere untuk tiga node yang menjalankan bidang kontrol cluster pengguna.
Hal ini menyebabkan VM tersebut tersebar di tiga host fisik.
Google Distributed Cloud juga membuat aturan anti-afinitas DRS vSphere untuk node pekerja di cluster pengguna Anda, yang menyebabkan node tersebut tersebar di setidaknya tiga host fisik. Beberapa aturan anti-afinitas DRS digunakan per kumpulan node cluster pengguna berdasarkan jumlah node. Dengan begitu, node pekerja dapat menemukan host untuk dijalankan, meskipun jumlah host lebih sedikit dari jumlah VM di kumpulan node cluster pengguna. Sebaiknya sertakan host fisik tambahan di cluster vCenter. Selain itu, konfigurasikan DRS agar sepenuhnya otomatis sehingga jika host tidak tersedia, DRS dapat otomatis memulai ulang VM di host lain yang tersedia tanpa melanggar aturan anti-afinitas VM.
Google Distributed Cloud mempertahankan label node khusus, onprem.gke.io/failure-domain-name, yang nilainya ditetapkan ke nama host ESXi yang mendasarinya. Aplikasi pengguna yang menginginkan ketersediaan tinggi dapat menyiapkan aturan podAntiAffinity dengan label ini sebagai topologyKey untuk memastikan bahwa Pod aplikasi mereka tersebar di berbagai VM serta host fisik.
Anda juga dapat mengonfigurasi beberapa kumpulan node untuk cluster pengguna dengan datastore yang berbeda dan label node khusus. Demikian pula, Anda dapat menyiapkan aturan podAntiAffinity dengan label node khusus tersebut sebagai topologyKey untuk mencapai ketersediaan yang lebih tinggi setelah kegagalan datastore.
Agar memiliki HA untuk workload pengguna, pastikan cluster pengguna memiliki jumlah replika yang memadai di bawah nodePools.replicas, yang memastikan jumlah worker cluster pengguna yang diinginkan dalam kondisi berjalan.
Anda dapat menggunakan datastore terpisah untuk cluster admin dan cluster pengguna untuk mengisolasi kegagalannya.
Load balancer
Ada dua jenis load balancer yang dapat Anda gunakan untuk ketersediaan tinggi.
Load balancer MetalLB yang dipaket
Untuk load balancer MetalLB yang dipaketkan, Anda mencapai HA dengan memiliki lebih dari satu node dengan enableLoadBalancer: true.
MetalLB mendistribusikan layanan ke node load balancer, tetapi untuk satu layanan, hanya ada satu node pemimpin yang menangani semua traffic untuk layanan tersebut.
Selama upgrade cluster, terjadi periode nonaktif saat node load balancer diupgrade. Durasi gangguan failover MetalLB bertambah seiring dengan meningkatnya jumlah node load balancer. Dengan kurang dari 5 node, gangguan memerlukan waktu 10 detik.
Load balancer Seesaw paket
Untuk load balancer Seesaw paket, Anda dapat mengaktifkan HA dengan menetapkan loadBalancer.seesaw.enableHA ke true dalam file konfigurasi cluster.
Anda juga harus mengaktifkan kombinasi pembelajaran MAC, transmisi palsu, dan mode promiscuous pada grup port load balancer.
Dengan HA, dua load balancer disiapkan dalam mode pasif aktif. Jika load balancer aktif mengalami masalah, traffic akan beralih ke load balancer pasif.
Selama upgrade load balancer, terjadi periode nonaktif. Jika HA diaktifkan untuk load balancer, periode nonaktif maksimumnya adalah dua detik.
Load balancer F5 BIG-IP terintegrasi
Platform F5 BIG-IP menyediakan berbagai Layanan untuk membantu Anda meningkatkan keamanan, ketersediaan, dan performa aplikasi Anda. Untuk Google Distributed Cloud, BIG-IP menyediakan akses eksternal dan Layanan load balancing L3/4.
Menggunakan beberapa cluster untuk pemulihan dari bencana
Men-deploy aplikasi di beberapa cluster di beberapa vCenter atau platform GKE Enterprise dapat memberikan ketersediaan global yang lebih tinggi dan membatasi radius ledakan selama gangguan.
Penyiapan ini menggunakan cluster GKE Enterprise yang sudah ada di pusat data sekunder untuk pemulihan dari bencana, bukan menyiapkan cluster baru. Berikut adalah ringkasan umum untuk mencapai hal ini:
Buat cluster admin dan cluster pengguna lain di pusat data sekunder. Dalam arsitektur multi-cluster ini, kita mengharuskan pengguna untuk memiliki dua cluster admin di setiap pusat data, dan setiap cluster admin menjalankan satu cluster pengguna.
Cluster pengguna sekunder memiliki jumlah worker node minimal (tiga) dan merupakan mode hot standby (selalu berjalan).
Deployment aplikasi dapat direplikasi di kedua vCenter menggunakan Config Sync, atau pendekatan yang lebih disukai adalah menggunakan rantai DevOps (CI/CD, Spinnaker) aplikasi yang sudah ada.
Jika terjadi bencana, ukuran cluster pengguna dapat diubah sesuai jumlah node.
Selain itu, switchover DNS diperlukan untuk mengarahkan traffic antara cluster ke pusat data sekunder.