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.

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 pengujian, pengembangan, dan produksi, sebaiknya mulai dengan lingkungan yang paling tidak penting, seperti pengujian, dan verifikasi fungsi upgrade. Setelah Anda memverifikasi bahwa upgrade berhasil, lanjutkan ke lingkungan berikutnya. Ulangi proses ini hingga Anda mengupgrade lingkungan produksi. Pendekatan ini memungkinkan Anda berpindah dari satu titik kritis ke titik kritis berikutnya, dan memverifikasi bahwa upgrade dan semua beban kerja Anda berjalan dengan benar.

Checklist upgrade

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

Perkirakan komitmen waktu dan rencanakan masa pemeliharaan untuk upgrade.

Siapkan pencadangan untuk cluster pengguna dan cluster admin.

Periksa PodDisruptionBudgets di cluster pengguna.

Tinjau alamat IP yang tersedia dan kebutuhan.

Periksa penggunaan cluster pengguna dan resource yang tersedia.

Periksa kapasitas cluster vSphere untuk resource yang tersedia seperti CPU, memori, dan waktu siap.

Periksa kesehatan dan konfigurasi cluster untuk menyelesaikan masalah sebelum upgrade.

Gunakan Deployment untuk meminimalkan gangguan aplikasi.

Gunakan pasangan load balancer dengan ketersediaan tinggi.

Tentukan cara mengupgrade setiap cluster pengguna.

Periksa apakah sertifikat CA perlu dirotasi.

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 buka normal saat traffic sedang sepi.

Memperkirakan komitmen waktu dan merencanakan periode pemeliharaan

Secara default, semua kumpulan node 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 dalam 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 kumpulan terbesar, total waktu upgrade akan berkisar 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 menetapkan nilai maxSurge untuk setiap node pool. Saat Anda mengupgrade catatan dengan maxSurge, beberapa node akan 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 versi lewati akan mengurangi waktu upgrade node pool dua versi secara berurutan menjadi setengah. Selain itu, upgrade versi lewati 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 informasi selengkapnya, lihat Lewati versi saat mengupgrade node pool.
Anda dapat mengupgrade panel kontrol cluster pengguna secara terpisah dari node pool. Dengan fleksibilitas ini, Anda dapat merencanakan beberapa periode pemeliharaan yang lebih singkat, bukan satu periode pemeliharaan yang lama 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.

Cadangan 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 beban kerja cluster. Untuk informasi selengkapnya, lihat cara membuat cadangan 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 dibatasi di etcd pada datastore 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 periode nonaktif atau gangguan aplikasi yang tidak diinginkan. PDB menginstruksikan penjadwal untuk selalu mempertahankan sejumlah Pod yang berjalan saat Pod lain mungkin gagal. Perilaku ini adalah cara yang berguna untuk menyediakan ketersediaan aplikasi.

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 habis.

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

Untuk memastikan PDB tidak mengganggu prosedur upgrade, periksa semua PDB di cluster tertentu sebelum Anda memulai upgrade. Anda mungkin perlu berkoordinasi dengan tim pengembangan dan pemilik aplikasi untuk sementara mengubah atau menonaktifkan PDB 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 selama upgrade cluster:

Proses upgrade cluster membuat node baru dan menghabiskan resource sebelum menghapus node lama. Sebaiknya Anda selalu memiliki alamat IP N+1 untuk cluster admin atau pengguna, dengan N adalah jumlah node dalam cluster.
Saat menggunakan alamat IP statis, alamat IP yang diperlukan harus dicantumkan dalam file blok IP.
Jika Anda menggunakan DHCP, pastikan VM baru dapat mendapatkan sewa IP tambahan di subnet yang diinginkan 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.
Jika Anda menggunakan alamat IP statis dan ingin mempercepat proses upgrade cluster pengguna, daftarkan 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 node pool per.
- Meskipun pendekatan ini adalah 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 akan memperlambat proses upgrade hanya ke satu VM dalam satu waktu, meskipun beberapa kumpulan node digunakan.

Memeriksa penggunaan cluster

Pastikan Pod dapat dievakuasi saat node habis dan ada resource yang cukup 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 ringkasan 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 sedikit, seperti selama akhir pekan atau malam hari, bergantung pada beban kerja yang berjalan dan kasus penggunaan.

Waktu untuk upgrade cluster admin mungkin kurang penting daripada untuk cluster pengguna, karena upgrade cluster admin biasanya tidak menyebabkan periode nonaktif aplikasi. Namun, Anda tetap harus memeriksa resource gratis di vSphere sebelum memulai upgrade cluster admin. Selain itu, mengupgrade cluster admin mungkin menyiratkan beberapa risiko, sehingga mungkin direkomendasikan selama periode penggunaan yang kurang aktif saat akses pengelolaan ke cluster kurang penting.

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

Memeriksa penggunaan vSphere

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

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 dengan setiap kumpulan node 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 256 GB
Kapasitas disk VM + vSwap 256 GB

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

Meskipun vSphere dirancang untuk penggunaan resource serentak dan memiliki mekanisme untuk menyediakan resource, meskipun jika overcommit, sebaiknya jangan overcommit memori VM. Overcommit memori dapat menyebabkan dampak performa yang serius yang memengaruhi seluruh cluster karena vSphere menyediakan "RAM yang hilang" dari menukar 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 untuk mengidentifikasi node yang tidak dikonfigurasi dengan benar, atau yang memiliki Pod yang dalam status macet. Jika perintah gkectl diagnose menampilkan peringatan Cluster unhealthy, perbaiki masalah sebelum Anda mencoba upgrade. Untuk mengetahui informasi selengkapnya, lihat Mendiagnosis masalah cluster.
Alat pra-upgrade: selain memeriksa kesehatan dan konfigurasi 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 jalankan perintah gkectl upgrade cluster dengan flag --dry-run. Flag --dry-run menjalankan pemeriksaan pra-penerbangan, tetapi tidak memulai proses upgrade. Meskipun versi sebelumnya dari Google Distributed Cloud menjalankan pemeriksaan pra-penerbangan, versi tersebut tidak dapat dijalankan secara terpisah dari upgrade. Dengan menambahkan tanda --dry-run, Anda dapat menemukan dan memperbaiki masalah apa pun yang ditemukan pemeriksaan pra-penerbangan dengan cluster pengguna sebelum upgrade.

Menggunakan Deployment untuk meminimalkan gangguan aplikasi

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

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

Ada juga aturan untuk Deployment untuk memastikan jumlah replika yang ditetapkan selalu terus berjalan. Aturan ini dikenal sebagai PodDisruptionBudgets (PDB). PDB memungkinkan Anda membatasi gangguan pada beban kerja saat Pod-nya harus dijadwalkan ulang karena alasan tertentu, 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 otomatis diupgrade 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 pengalihan 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 yang dipaketkan dengan Seesaw.

Untuk mencegah gangguan layanan selama upgrade dengan pasangan HA, cluster akan 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. Rangkaian praktik terbaik ini mengasumsikan bahwa cluster pengguna HA menggunakan pasangan load balancer HA.

Jika Anda menggunakan MetalLB sebagai load balancer yang dipaketkan, Anda tidak perlu melakukan 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, lacak 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.

Pastikan Anda memiliki gcloud CLI versi terbaru. Update komponen gcloud CLI, jika diperlukan:
```
gcloud components update
```
Jalankan perintah berikut untuk memeriksa versi:

Untuk memeriksa versi cluster pengguna:
```
gcloud container vmware clusters list \
    --project=PROJECT_ID \
    --location=-
```
Ganti PROJECT_ID Project ID untuk project host fleet Anda.

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

Output perintah ini 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 untuk 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 dirotasi

Selama upgrade, sertifikat leaf dirotasi, tetapi sertifikat CA tidak. Anda harus merotasi sertifikat CA secara manual setidaknya setiap lima tahun sekali. Untuk informasi selengkapnya, lihat Memutar otoritas sertifikat cluster pengguna dan Memutar 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 mungkin berisi node pekerja dan node bidang kontrol (Controlplane V2) atau hanya node pekerja (kubeception). Dengan kubeception, bidang kontrol untuk cluster pengguna berjalan di satu atau beberapa node dalam cluster admin. Dalam kedua kasus tersebut, pada versi 1.14 dan yang lebih baru, Anda dapat mengupgrade panel kontrol cluster pengguna secara terpisah dari node pool yang menjalankan workload Anda.

Perbedaan efek upgrade cluster pengguna dan cluster admin

Prosedur upgrade Google Distributed Cloud melibatkan proses pengosongan node yang menghapus semua Pod dari node. Proses ini membuat VM baru untuk setiap node pekerja yang habis dan menambahkannya ke cluster. Node pekerja yang habis kemudian dihapus dari inventaris VMware. Selama proses ini, semua beban kerja 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 pada satu waktu.

Gangguan cluster pengguna

Tabel berikut menjelaskan dampak upgrade cluster pengguna in-place:

Fungsi	Cluster admin	Cluster pengguna non-HA	Cluster pengguna HA
Akses Kubernetes API	Tidak terpengaruh	Tidak terpengaruh	Tidak terpengaruh
Beban kerja 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 terlihat hingga upgrade selesai.
Tidak terpengaruh: gangguan layanan mungkin terjadi dalam waktu yang sangat singkat, tetapi hampir tidak terlihat.

Node bidang kontrol cluster pengguna, baik yang berjalan di cluster admin (kubeception) maupun cluster pengguna itu sendiri (Controlplane V2), tidak menjalankan beban kerja pengguna apa pun. Selama upgrade, node bidang kontrol ini akan dikosongkan, lalu diupdate sebagaimana mestinya.

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

Selama upgrade di lingkungan bidang kontrol non-HA, bidang kontrol tidak dapat mengontrol tindakan deployment, pemulihan, atau penskalaan Pod. Selama gangguan singkat pada 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 cluster pengguna produksi selama upgrade, sebaiknya gunakan tiga node panel 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
Beban kerja pengguna	Tidak terpengaruh	Tidak terpengaruh	Tidak terpengaruh
Node bidang kontrol	Terpengaruh	Terpengaruh	Tidak terpengaruh
Penskalaan 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 terlihat hingga upgrade selesai.
Tidak terpengaruh: gangguan layanan mungkin terjadi dalam waktu yang sangat singkat, tetapi hampir tidak terlihat.

Langkah selanjutnya

Mengupgrade cluster atau node pool