Praktik terbaik untuk upgrade cluster Google Distributed Cloud

Dokumen ini menjelaskan praktik terbaik dan pertimbangan untuk mengupgrade Google Distributed Cloud. Anda akan mempelajari cara mempersiapkan upgrade cluster, dan praktik terbaik yang harus diikuti sebelum upgrade. Praktik terbaik ini membantu mengurangi risiko yang terkait dengan upgrade cluster.

Jika Anda memiliki beberapa lingkungan seperti test, development, dan production, sebaiknya mulai dengan lingkungan yang paling tidak penting, seperti test, dan verifikasi fungsi upgrade. Setelah Anda memverifikasi bahwa upgrade berhasil, lanjutkan ke lingkungan berikutnya. Ulangi proses ini hingga Anda mengupgrade lingkungan produksi. Dengan pendekatan ini, Anda dapat berpindah dari satu titik penting ke titik penting berikutnya, dan memverifikasi bahwa upgrade dan beban kerja Anda berjalan dengan benar.

Checklist upgrade

Untuk membuat proses upgrade selancar mungkin, tinjau dan selesaikan pemeriksaan berikut sebelum Anda mulai mengupgrade cluster:

Merencanakan upgrade

Update dapat mengganggu. Sebelum memulai upgrade, rencanakan dengan cermat untuk memastikan lingkungan dan aplikasi Anda sudah siap. Anda mungkin juga perlu menjadwalkan upgrade setelah jam kerja normal saat traffic paling lengang.

Perkirakan komitmen waktu dan rencanakan masa pemeliharaan

Secara default, semua node pool diupgrade secara paralel. Namun, dalam setiap node pool, node diupgrade secara berurutan karena setiap node harus dikosongkan dan dibuat ulang. Jadi, total waktu untuk upgrade bergantung pada jumlah node di node pool terbesar. Untuk menghitung perkiraan kasar waktu upgrade, kalikan 15 menit dengan jumlah node di node pool terbesar. Misalnya, jika Anda memiliki 10 node di pool terbesar, total waktu upgrade adalah sekitar 15 * 10 = 150 menit atau 2,5 jam.

Berikut beberapa cara untuk mengurangi waktu upgrade dan mempermudah perencanaan serta penjadwalan upgrade:

  • Di versi 1.28 dan yang lebih baru, Anda dapat mempercepat upgrade dengan menyetel nilai maxSurge untuk setiap node pool. Saat Anda mengupgrade node dengan maxSurge, beberapa node diupgrade dalam waktu yang sama dengan yang diperlukan untuk mengupgrade satu node.

  • Jika cluster Anda menggunakan versi 1.16 atau yang lebih tinggi, Anda dapat melewati versi minor saat mengupgrade node pool. Melakukan upgrade lewati versi akan mengurangi waktu yang diperlukan untuk mengupgrade node pool dua versi secara berurutan menjadi setengahnya. Selain itu, upgrade melewati versi memungkinkan Anda meningkatkan waktu antara upgrade yang diperlukan untuk tetap menggunakan versi yang didukung. Mengurangi jumlah upgrade akan mengurangi gangguan workload dan waktu verifikasi. Untuk mengetahui informasi selengkapnya, lihat Melewati versi saat mengupgrade node pool.

  • Anda dapat mengupgrade bidang kontrol cluster pengguna secara terpisah dari node pool. Dengan fleksibilitas ini, Anda dapat merencanakan beberapa masa pemeliharaan yang lebih singkat, bukan satu masa pemeliharaan yang panjang, untuk mengupgrade seluruh cluster. Untuk mengetahui detailnya, lihat Mengupgrade node pool.

Mencadangkan cluster pengguna dan admin

Sebelum memulai upgrade, cadangkan cluster pengguna dan admin Anda.

Pencadangan cluster pengguna adalah snapshot penyimpanan etcd cluster pengguna. Penyimpanan etcd berisi semua objek Kubernetes dan objek kustom yang diperlukan untuk mengelola status cluster. Snapshot berisi data yang diperlukan untuk membuat ulang komponen dan workload cluster. Untuk mengetahui informasi selengkapnya, lihat cara mencadangkan cluster pengguna.

Dengan Google Distributed Cloud versi 1.8 dan yang lebih baru, Anda dapat menyiapkan pencadangan otomatis dengan clusterBackup.datastore dalam file konfigurasi cluster admin. Untuk mengaktifkan fitur ini di cluster yang ada, edit file konfigurasi cluster admin dan tambahkan kolom clusterBackup.datastore, lalu jalankan gkectl update admin.

Setelah clusterBackup.datastore diaktifkan, cluster admin Anda akan otomatis dicadangkan di etcd pada penyimpanan data vSphere yang dikonfigurasi. Proses pencadangan ini diulang setiap kali ada perubahan pada cluster admin. Saat Anda memulai upgrade cluster, tugas pencadangan akan berjalan sebelum mengupgrade cluster.

Untuk memulihkan cluster admin dari cadangannya jika Anda mengalami masalah, lihat Mencadangkan dan memulihkan cluster admin dengan gkectl.

Meninjau penggunaan PodDisruptionBudgets

Di Kubernetes, PodDisruptionBudgets (PDB) dapat membantu mencegah gangguan atau waktu nonaktif aplikasi yang tidak diinginkan. PDB menginstruksikan penjadwal untuk selalu menjalankan sejumlah Pod, sementara Pod lainnya mungkin gagal. Perilaku ini adalah cara yang berguna untuk menyediakan ketersediaan aplikasi.

  1. Untuk memeriksa PDB yang dikonfigurasi di cluster Anda, gunakan perintah kubectl get pdb:

    kubectl get pdb -A --kubeconfig KUBECONFIG

    Ganti KUBECONFIG dengan nama file kubeconfig Anda.

    Contoh output berikut menunjukkan PDB bernama istio-ingress, istiod, dan kube-dns:

    NAMESPACE     NAME            MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
gke-system    istio-ingress   1               N/A               1                     16d
gke-system    istiod          1               N/A               1                     16d
kube-system   kube-dns        1               N/A               1                     16d

Dalam tabel sebelumnya, setiap PDB menentukan bahwa setidaknya satu Pod harus selalu tersedia. Ketersediaan ini menjadi sangat penting selama upgrade saat node dikuras.

Periksa PDB yang tidak dapat dipenuhi. Misalnya, Anda dapat menetapkan ketersediaan minimum 1, saat Deployment hanya menampilkan 1 replika. Dalam contoh ini, operasi pengurasan terganggu karena PDB tidak dapat dipenuhi oleh pengontrol resource.

Untuk memastikan bahwa PDB tidak mengganggu prosedur upgrade, periksa semua PDB pada cluster tertentu sebelum Anda memulai upgrade. Anda mungkin perlu berkoordinasi dengan tim pengembangan dan pemilik aplikasi untuk mengubah atau menonaktifkan PDB sementara selama upgrade cluster.

Google Distributed Cloud menjalankan pemeriksaan pra-penerbangan selama proses upgrade untuk memperingatkan tentang PDB. Namun, Anda juga harus memverifikasi PDB secara manual untuk memastikan pengalaman upgrade yang lancar. Untuk mempelajari PDB lebih lanjut, lihat Menentukan Anggaran Gangguan untuk Aplikasi Anda.

Meninjau alamat IP yang tersedia

Pertimbangan alamat IP berikut berlaku untuk upgrade cluster pengguna dan cluster admin non-HA (yaitu, cluster admin yang tidak memiliki ketersediaan tinggi):

  • Proses upgrade cluster membuat node baru dan mengosongkan resource sebelum menghapus node lama. Sebaiknya Anda selalu memiliki N+1 alamat IP untuk cluster, dengan N adalah jumlah node dalam cluster. Rekomendasi ini hanya berlaku untuk cluster admin non-HA (yang hanya memiliki satu node bidang kontrol) dan cluster pengguna.

  • Saat menggunakan alamat IP statis, alamat IP yang diperlukan harus tercantum dalam file blok IP.

    • Saat mengupgrade cluster admin non-HA, tambahkan alamat IP tambahan dalam file blok IP yang digunakan oleh cluster admin. Jalur ke file ini harus ditentukan di kolom network.ipMode.ipBlockFilePath pada file konfigurasi cluster admin.
    • Saat mengupgrade cluster pengguna, tambahkan alamat IP tambahan dalam file blok IP yang digunakan oleh cluster pengguna. Jalur ke file ini harus ditentukan di kolom network.ipMode.ipBlockFilePath pada file konfigurasi cluster pengguna.

  • Jika Anda menggunakan DHCP, pastikan VM baru dapat memperoleh lease IP tambahan di subnet yang berlaku selama upgrade.

    Jika Anda perlu menambahkan alamat IP, perbarui file blok IP, lalu jalankan perintah gkectl update. Untuk mengetahui informasi selengkapnya, lihat Merencanakan alamat IP Anda.

  • Jika Anda menggunakan alamat IP statis dan ingin mempercepat proses upgrade cluster pengguna, cantumkan alamat IP yang cukup dalam file blok IP Anda sehingga setiap kumpulan node dapat memiliki alamat IP tambahan yang tersedia. Pendekatan ini memungkinkan proses mempercepat prosedur penambahan dan penghapusan VM karena dilakukan berdasarkan per node pool.

    Meskipun pendekatan ini merupakan opsi yang baik untuk mempercepat upgrade cluster pengguna, pertimbangkan ketersediaan resource dan performa lingkungan vSphere Anda sebelum melanjutkan.

  • Jika hanya ada satu IP cadangan untuk seluruh cluster pengguna, batasan ini memperlambat proses upgrade menjadi hanya satu VM dalam satu waktu, meskipun beberapa kumpulan node digunakan.

Cluster admin HA tidak memerlukan alamat IP N+1 untuk upgrade. Tiga node bidang kontrol di cluster admin HA dibuat ulang satu per satu, sehingga tidak memerlukan alamat IP tambahan.

Memeriksa pemanfaatan cluster

Pastikan Pod dapat dievakuasi saat node dikuras dan ada cukup resource di cluster yang diupgrade untuk mengelola upgrade. Untuk memeriksa penggunaan resource cluster saat ini, Anda dapat menggunakan dasbor kustom di Google Cloud Observability, atau langsung di cluster menggunakan perintah seperti kubectl top nodes.

Perintah yang Anda jalankan terhadap cluster akan menampilkan snapshot penggunaan resource cluster saat ini. Dasbor dapat memberikan tampilan yang lebih mendetail tentang resource yang digunakan dari waktu ke waktu. Data penggunaan resource ini dapat membantu menunjukkan kapan upgrade akan menyebabkan gangguan paling kecil, seperti selama akhir pekan atau malam hari, bergantung pada beban kerja yang berjalan dan kasus penggunaan.

Waktu untuk upgrade cluster admin mungkin tidak terlalu penting dibandingkan dengan cluster pengguna, karena upgrade cluster admin biasanya tidak menyebabkan periode istirahat aplikasi. Namun, Anda tetap harus memeriksa ketersediaan resource gratis di vSphere sebelum memulai upgrade cluster admin. Selain itu, mengupgrade cluster admin dapat menimbulkan risiko tertentu, sehingga upgrade sebaiknya dilakukan selama periode penggunaan yang kurang aktif saat akses pengelolaan ke cluster tidak terlalu penting.

Untuk mengetahui informasi selengkapnya, lihat layanan apa yang terpengaruh selama upgrade cluster.

Memeriksa pemanfaatan vSphere

Pastikan ada cukup resource pada infrastruktur vSphere yang mendasarinya. Untuk memeriksa penggunaan resource ini, pilih cluster di vCenter dan tinjau tab Summary.

Tab ringkasan menampilkan konsumsi memori, CPU, dan penyimpanan secara keseluruhan dari seluruh cluster. Karena upgrade Google Distributed Cloud memerlukan resource tambahan, Anda juga harus memeriksa apakah cluster dapat menangani permintaan resource tambahan ini.

Sebagai aturan umum, cluster vSphere Anda harus dapat mendukung resource tambahan berikut:

  • +1 VM per upgrade cluster admin
  • +1 VM per node pool per upgrade cluster pengguna

Misalnya, asumsikan bahwa cluster pengguna memiliki 3 kumpulan node yang setiap kumpulan nodenya memiliki node yang menggunakan 8 vCPU dan RAM 32 GB atau lebih. Karena upgrade terjadi secara paralel untuk 3 node pool secara default, prosedur upgrade menggunakan resource tambahan berikut untuk 3 node lonjakan tambahan:

  • 24 vCPU
  • RAM 96 GB
  • Ruang disk VM + vSwap 96 GB

Proses upgrade membuat VM menggunakan operasi clone vSphere. Meng-clone beberapa VM dari template dapat menimbulkan tekanan pada sistem penyimpanan yang mendasarinya dalam bentuk peningkatan operasi I/O. Upgrade dapat sangat melambat jika subsistem penyimpanan yang mendasarinya tidak mampu memberikan performa yang memadai selama upgrade.

Meskipun vSphere didesain untuk penggunaan resource secara bersamaan dan memiliki mekanisme untuk menyediakan resource, bahkan saat over-committed, sebaiknya jangan over-commit memori VM. Penggunaan memori yang berlebihan dapat menyebabkan dampak performa yang serius dan memengaruhi seluruh cluster karena vSphere menyediakan "RAM yang hilang" dari penukaran halaman ke datastore. Perilaku ini dapat menyebabkan masalah selama upgrade cluster, dan menyebabkan dampak performa pada VM lain yang berjalan di cluster vSphere.

Jika resource yang tersedia sudah langka, matikan VM yang tidak diperlukan untuk membantu memenuhi persyaratan tambahan ini dan mencegah potensi penurunan performa.

Memeriksa kondisi dan konfigurasi cluster

Jalankan alat berikut di semua cluster sebelum upgrade:

  • Perintah gkectl diagnose: gkectl diagnose memastikan semua cluster responsif. Perintah ini menjalankan pemeriksaan lanjutan, seperti mengidentifikasi node yang tidak dikonfigurasi dengan benar, atau yang memiliki Pod dalam status macet. Jika perintah gkectl diagnose menampilkan peringatan Cluster unhealthy, perbaiki masalahnya sebelum Anda mencoba melakukan upgrade. Untuk mengetahui informasi selengkapnya, lihat Mendiagnosis masalah cluster.

  • Alat pra-upgrade: selain memeriksa konfigurasi dan kondisi cluster, alat pra-upgrade juga memeriksa potensi masalah umum yang dapat terjadi selama upgrade cluster.

Selain itu, saat mengupgrade cluster pengguna ke 1.29 dan yang lebih tinggi, sebaiknya Anda menjalankan perintah gkectl upgrade cluster dengan flag --dry-run. Flag --dry-run menjalankan pemeriksaan awal tetapi tidak memulai proses upgrade. Meskipun versi Google Distributed Cloud sebelumnya menjalankan pemeriksaan awal, pemeriksaan tersebut tidak dapat dijalankan secara terpisah dari upgrade. Dengan menambahkan tanda --dry-run, Anda dapat menemukan dan memperbaiki masalah apa pun yang ditemukan oleh pemeriksaan pra-penerbangan pada cluster pengguna sebelum upgrade.

Menggunakan Deployment untuk meminimalkan gangguan aplikasi

Karena node perlu dikosongkan selama update, upgrade cluster dapat menyebabkan gangguan aplikasi. Mengosongkan node berarti semua Pod yang berjalan harus dimatikan dan dimulai ulang di node yang tersisa dalam cluster.

Jika memungkinkan, aplikasi Anda harus menggunakan Deployment. Dengan pendekatan ini, aplikasi dirancang untuk menangani gangguan. Dampak apa pun harus minimal pada Deployment yang memiliki beberapa replika. Anda masih dapat mengupgrade cluster jika aplikasi tidak menggunakan Deployment.

Ada juga aturan untuk Deployment guna memastikan sejumlah replika selalu berjalan. Aturan ini dikenal sebagai PodDisruptionBudgets (PDB). PDB memungkinkan Anda membatasi gangguan pada workload saat Pod-nya harus dijadwalkan ulang karena beberapa alasan, seperti upgrade atau pemeliharaan pada node cluster, dan penting untuk diperiksa sebelum upgrade.

Menggunakan pasangan load balancer dengan ketersediaan tinggi

Jika Anda menggunakan Seesaw sebagai load balancer di cluster, load balancer akan diupgrade secara otomatis saat Anda mengupgrade cluster. Upgrade ini dapat menyebabkan gangguan layanan. Untuk mengurangi dampak upgrade dan kegagalan load balancer pada akhirnya, Anda dapat menggunakan pasangan ketersediaan tinggi (pasangan HA). Dalam konfigurasi ini, sistem membuat dan mengonfigurasi dua VM load balancer sehingga failover ke peer lain dapat terjadi.

Untuk meningkatkan ketersediaan layanan (yaitu, ke server Kubernetes API), sebaiknya Anda selalu menggunakan pasangan HA di depan cluster admin. Untuk mempelajari Seesaw dan konfigurasi HA-nya lebih lanjut, lihat dokumentasi versi 1.16 Load balancing gabungan dengan Seesaw.

Untuk mencegah gangguan layanan selama upgrade dengan pasangan HA, cluster memulai failover sebelum membuat VM load balancer baru. Jika cluster pengguna hanya menggunakan satu instance load balancer, gangguan layanan akan terjadi hingga upgrade untuk load balancer selesai.

Sebaiknya Anda memiliki pasangan load balancer HA jika cluster pengguna itu sendiri juga dikonfigurasi agar memiliki ketersediaan tinggi. Seri praktik terbaik ini mengasumsikan bahwa cluster pengguna HA menggunakan pasangan load balancer HA.

Jika Anda menggunakan MetalLB sebagai load balancer yang dipaketkan, tidak diperlukan penyiapan pra-upgrade. Load balancer diupgrade selama proses upgrade cluster.

Menentukan cara mengupgrade setiap cluster pengguna

Pada versi 1.14 dan yang lebih baru, Anda dapat memilih untuk mengupgrade cluster pengguna secara keseluruhan (artinya, Anda dapat mengupgrade bidang kontrol dan semua node pool dalam cluster), atau Anda dapat mengupgrade bidang kontrol cluster pengguna dan membiarkan node pool pada versi saat ini. Untuk mengetahui informasi tentang alasan Anda mungkin ingin mengupgrade bidang kontrol secara terpisah, lihat Upgrade cluster pengguna.

Dalam lingkungan multi-cluster, pantau cluster pengguna mana yang telah diupgrade dan catat nomor versinya. Jika Anda memutuskan untuk mengupgrade bidang kontrol dan node pool secara terpisah, catat versi bidang kontrol dan setiap node pool di setiap cluster.

Memeriksa versi cluster pengguna dan admin

gkectl

  • Untuk memeriksa versi cluster pengguna:

    gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Ganti ADMIN_CLUSTER_KUBECONFIG dengan jalur file kubeconfig untuk cluster admin Anda.

  • Untuk memeriksa versi cluster admin:

    gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

gcloud CLI

Untuk cluster yang terdaftar di GKE On-Prem API, Anda dapat menggunakan gcloud CLI untuk mendapatkan versi cluster pengguna, node pool di cluster pengguna, dan cluster admin.

  1. Pastikan Anda memiliki gcloud CLI versi terbaru. Update komponen gcloud CLI, jika diperlukan:

    gcloud components update

  2. Jalankan perintah berikut untuk memeriksa versi:

  • Untuk memeriksa versi cluster pengguna:

    gcloud container vmware clusters list \
    --project=PROJECT_ID \
    --location=-

    Ganti PROJECT_ID dengan project ID project host fleet Anda.

    Jika Anda menetapkan --location=-, artinya mencantumkan semua cluster di semua wilayah. Jika Anda perlu mempersempit cakupan daftar, tetapkan --location ke region yang Anda tentukan saat mendaftarkan cluster.

    Output perintah mencakup versi cluster.

  • Untuk memeriksa versi cluster admin:

    gcloud container vmware admin-clusters list \
    --project=PROJECT_ID \
    --location=-

Periksa versi node cluster:

Anda dapat menggunakan kubectl untuk mendapatkan versi node cluster, tetapi kubectl akan menampilkan versi Kubernetes. Untuk mendapatkan versi Google Distributed Cloud yang sesuai dengan versi Kubernetes, lihat Pembuatan Versi.

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Ganti USER_CLUSTER_KUBECONFIG dengan jalur file kubeconfig untuk cluster pengguna Anda.

Memeriksa apakah sertifikat CA perlu diubah

Selama upgrade, sertifikat leaf dirotasi, tetapi sertifikat CA tidak. Anda harus merotasi sertifikat CA secara manual setidaknya sekali setiap lima tahun. Untuk mengetahui informasi selengkapnya, lihat Merotasi otoritas sertifikat cluster pengguna dan Merotasi sertifikat CA cluster admin.

Perbedaan antara jenis cluster

Ada dua jenis cluster yang berbeda:

  • Cluster pengguna
  • Cluster admin

Bergantung pada cara Anda membuat cluster pengguna, cluster tersebut dapat berisi worker node dan node bidang kontrol (Controlplane V2) atau hanya worker node (kubeception). Dengan kubeception, bidang kontrol untuk cluster pengguna berjalan di satu atau beberapa node dalam cluster admin. Dalam kedua kasus tersebut, di versi 1.14 dan yang lebih baru, Anda dapat mengupgrade bidang kontrol cluster pengguna secara terpisah dari node pool yang menjalankan workload Anda.

Efek berbeda dari upgrade cluster pengguna versus upgrade cluster admin

Prosedur upgrade Google Distributed Cloud melibatkan proses pengurasan node yang menghapus semua Pod dari node. Proses ini membuat VM baru untuk setiap node pekerja yang dikuras dan menambahkannya ke cluster. Node pekerja yang dikuras kemudian dihapus dari inventaris VMware. Selama proses ini, workload apa pun yang berjalan di node ini akan dihentikan dan dimulai ulang di node lain yang tersedia di cluster.

Bergantung pada arsitektur beban kerja yang dipilih, prosedur ini mungkin berdampak pada ketersediaan aplikasi. Untuk menghindari terlalu banyak tekanan pada kemampuan resource cluster, Google Distributed Cloud mengupgrade satu node dalam satu waktu.

Gangguan cluster pengguna

Tabel berikut menjelaskan dampak upgrade cluster pengguna di tempat:

Fungsi Cluster admin Cluster pengguna non-HA Cluster pengguna HA
Akses Kubernetes API Tidak terpengaruh Tidak terpengaruh Tidak terpengaruh
Workload pengguna Tidak terpengaruh Tidak terpengaruh Tidak terpengaruh
PodDisruptionBudgets* Tidak terpengaruh Tidak terpengaruh Tidak terpengaruh
Node bidang kontrol Tidak terpengaruh Terpengaruh Tidak terpengaruh
Autoscaler pod (VMware) Tidak terpengaruh Tidak terpengaruh Tidak terpengaruh
Perbaikan otomatis Tidak terpengaruh Tidak terpengaruh Tidak terpengaruh
Penskalaan otomatis node (VMware) Tidak terpengaruh Tidak terpengaruh Tidak terpengaruh
Penskalaan otomatis Pod horizontal Terpengaruh Terpengaruh Tidak terpengaruh
  • * : PDB dapat menyebabkan upgrade gagal atau berhenti.
  • Terpengaruh: gangguan layanan selama upgrade akan terasa hingga upgrade selesai.
  • Tidak terpengaruh: gangguan layanan mungkin terjadi dalam waktu yang sangat singkat, tetapi hampir tidak terasa.

Node bidang kontrol cluster pengguna, baik yang berjalan di cluster admin (kubeception) atau cluster pengguna itu sendiri (Controlplane V2), tidak menjalankan beban kerja pengguna. Selama upgrade, node bidang kontrol ini akan dihabiskan dan kemudian diupdate sebagaimana mestinya.

Di lingkungan dengan bidang kontrol ketersediaan tinggi (HA), mengupgrade bidang kontrol cluster pengguna tidak akan mengganggu workload pengguna. Di lingkungan HA, mengupgrade cluster admin tidak mengganggu beban kerja pengguna. Untuk cluster pengguna yang menggunakan Controlplane V2, mengupgrade hanya bidang kontrol tidak akan mengganggu workload pengguna.

Selama upgrade di lingkungan bidang kontrol non-HA, bidang kontrol tidak dapat mengontrol tindakan penskalaan, pemulihan, atau deployment Pod. Selama gangguan singkat bidang kontrol selama upgrade, workload pengguna dapat terpengaruh jika berada dalam status penskalaan, deployment, atau pemulihan. Artinya, peluncuran akan gagal selama upgrade di lingkungan non-HA.

Untuk meningkatkan ketersediaan dan mengurangi gangguan pada cluster pengguna produksi selama upgrade, sebaiknya gunakan tiga node bidang kontrol (mode ketersediaan tinggi).

Gangguan cluster admin

Tabel berikut menjelaskan dampak upgrade cluster admin di tempat:

Fungsi Cluster admin Cluster pengguna non-HA Cluster pengguna HA
Akses Kubernetes API Terpengaruh Terpengaruh Tidak terpengaruh
Workload pengguna Tidak terpengaruh Tidak terpengaruh Tidak terpengaruh
Node bidang kontrol Terpengaruh Terpengaruh Tidak terpengaruh
Penskala Otomatis Pod Terpengaruh Terpengaruh Tidak terpengaruh
Bengkel Mobil Terpengaruh Terpengaruh Tidak terpengaruh
Penskalaan otomatis node Terpengaruh Terpengaruh Tidak terpengaruh
Penskalaan otomatis Pod horizontal Terpengaruh Terpengaruh Tidak terpengaruh
  • Terpengaruh: gangguan layanan selama upgrade akan terasa hingga upgrade selesai.
  • Tidak terpengaruh: gangguan layanan mungkin terjadi dalam waktu yang sangat singkat, tetapi hampir tidak terlihat.

Langkah berikutnya