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 terkait upgrade cluster.

Jika Anda memiliki beberapa lingkungan seperti test, pengembangan, dan produksi, sebaiknya mulai dengan lingkungan yang paling tidak penting, seperti test, dan verifikasi fungsi upgrade. Setelah memastikan bahwa upgrade berhasil, lanjutkan ke lingkungan berikutnya. Ulangi proses ini sampai Anda mengupgrade lingkungan produksi. Pendekatan ini memungkinkan Anda berpindah dari satu titik penting ke titik penting berikutnya, dan memastikan bahwa upgrade dan workload Anda berjalan dengan benar.

Upgrade checklist

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 cadangan untuk cluster pengguna dan cluster admin.

Periksa PodDisruptionBudgets di cluster pengguna.

Tinjau alamat IP yang tersedia dan kebutuhannya.

Periksa pemanfaatan cluster pengguna dan resource yang tersedia.

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

Periksa kondisi dan konfigurasi cluster untuk menyelesaikan masalah sebelum upgrade.

Gunakan Deployment untuk meminimalkan gangguan pada aplikasi.

Gunakan pasangan load balancer 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 siap dan siap.

Memperkirakan komitmen waktu dan merencanakan masa pemeliharaan

Secara default, semua kumpulan node diupgrade secara paralel, tetapi dalam setiap kumpulan node, node diupgrade secara berurutan. Jadi, total waktu untuk upgrade bergantung pada jumlah node di kumpulan node terbesar. Untuk menghitung perkiraan kasar waktu upgrade, gunakan 15 menit * jumlah node dalam kumpulan node terbesar. Misalnya, jika Anda memiliki 10 node di kumpulan terbesar, total waktu upgrade adalah sekitar 150 menit.

Pada versi 1.28 dan yang lebih baru, Anda dapat mempercepat upgrade dengan menetapkan nilai maxSurge untuk setiap kumpulan node.

Mencadangkan pengguna dan cluster admin

Sebelum memulai upgrade, cadangkan cluster pengguna dan admin Anda.

Cadangan cluster pengguna adalah snapshot dari 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 di 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 datastore vSphere yang dikonfigurasi. Proses pencadangan ini berulang setiap kali terjadi 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.

Tinjau penggunaan `PodDisruptionBudgets`

Di Kubernetes, PodDisruptionBudgets (PDB) dapat membantu mencegah periode nonaktif atau pemadaman 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.

Untuk memeriksa PDB apa 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

Pada tabel sebelumnya, setiap PDB menentukan bahwa setidaknya satu Pod harus selalu tersedia. Ketersediaan ini menjadi penting selama upgrade jika node terkuras.

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 pada cluster tertentu sebelum memulai upgrade. Anda mungkin perlu berkoordinasi dengan tim pengembangan dan pemilik aplikasi untuk mengubah atau menonaktifkan PDB untuk sementara selama upgrade cluster.

Google Distributed Cloud menjalankan pemeriksaan preflight 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 akan membuat node baru dan menghabiskan resource sebelum menghapus node lama. Sebaiknya Anda selalu memiliki alamat IP N+1 untuk admin atau cluster pengguna, dengan N adalah jumlah node dalam cluster.
Saat menggunakan alamat IP statis, alamat IP yang diperlukan harus tercantum dalam file blok IP.
Jika Anda menggunakan DHCP, pastikan VM baru bisa mendapatkan lease 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, cantumkan alamat IP yang cukup dalam file blok IP Anda sehingga setiap kumpulan node dapat memiliki alamat IP tambahan. Pendekatan ini memungkinkan proses mempercepat prosedur penambahan dan penghapusan VM karena dilakukan dengan dasar 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 akan memperlambat proses upgrade ke hanya satu VM pada satu waktu, meskipun beberapa kumpulan node digunakan.

Memeriksa penggunaan cluster

Pastikan Pod dapat dievakuasi saat node dikosongkan, dan ada cukup resource di cluster yang diupgrade untuk mengelola upgrade. Untuk memeriksa penggunaan resource cluster saat ini, Anda dapat menggunakan dasbor kustom di Kemampuan Observasi Google Cloud, 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 terkait resource yang digunakan dari waktu ke waktu. Data penggunaan resource ini dapat membantu menunjukkan kapan upgrade akan menyebabkan gangguan yang paling sedikit, misalnya selama akhir pekan atau malam hari, bergantung pada beban kerja dan kasus penggunaan yang berjalan.

Waktu upgrade cluster admin mungkin tidak begitu penting dibandingkan untuk cluster pengguna, karena upgrade cluster admin biasanya tidak menyebabkan periode nonaktif aplikasi. Namun, penting untuk 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 tidak terlalu penting.

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

Memeriksa penggunaan vSphere

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

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

Pada dasarnya, cluster vSphere Anda harus dapat mendukung resource tambahan berikut:

+1 VM per upgrade cluster admin
+1 VM per kumpulan node per upgrade cluster pengguna

Sebagai contoh, 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 + 256 GB vSwap

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

Meskipun vSphere dirancang untuk penggunaan resource simultan dan memiliki mekanisme untuk menyediakan resource, meskipun jika di-commit, sebaiknya Anda tidak melakukan commit berlebihan pada memori VM. Kelebihan memori dapat menyebabkan dampak performa serius yang memengaruhi seluruh cluster karena vSphere menyebabkan "RAM yang hilang" sehingga tidak dapat 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 hit 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 bermasalah. Jika perintah gkectl diagnose menampilkan peringatan Cluster unhealthy, perbaiki masalah sebelum Anda mencoba melakukan upgrade. Untuk mengetahui informasi selengkapnya, lihat Mendiagnosis masalah cluster.
Alat pra-upgrade: selain memeriksa kondisi 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 preflight, tetapi tidak memulai proses upgrade. Meskipun versi Google Distributed Cloud sebelumnya menjalankan pemeriksaan preflight, versi 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 preflight pada cluster pengguna sebelum upgrade.

Menggunakan Deployment untuk meminimalkan gangguan aplikasi

Karena node harus dikosongkan selama update, upgrade cluster dapat menyebabkan gangguan aplikasi. Pengosongan node berarti semua Pod yang berjalan harus dinonaktifkan dan dimulai ulang pada node yang tersisa dalam cluster.

Jika memungkinkan, aplikasi Anda sebaiknya menggunakan Deployment. Dengan pendekatan ini, aplikasi didesain 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 untuk 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 alasan tertentu, seperti upgrade atau pemeliharaan pada node cluster, dan penting untuk diperiksa sebelum upgrade.

Gunakan pasangan load balancer 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, Anda dapat menggunakan pasangan ketersediaan tinggi (pasangan HA). Dalam konfigurasi ini, sistem akan membuat dan mengonfigurasi dua VM load balancer sehingga failover ke peer lainnya dapat terjadi.

Untuk meningkatkan ketersediaan layanan (yaitu, untuk server Kubernetes API), sebaiknya selalu gunakan pasangan HA di depan cluster admin. Untuk mempelajari Seesaw dan konfigurasi HA-nya lebih lanjut, lihat Load balancing paket 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 sampai 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 dengan ketersediaan tinggi (HA) menggunakan pasangan load balancer HA.

Jika Anda menggunakan MetalLB sebagai load balancer yang dipaketkan, tidak diperlukan penyiapan pra-upgrade. Load balancer tersebut akan 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, mengupgrade bidang kontrol dan semua kumpulan node dalam cluster), atau mengupgrade bidang kontrol cluster pengguna dan membiarkan kumpulan node tetap ke versi saat ini. Untuk mengetahui informasi tentang alasan Anda sebaiknya 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 kumpulan node secara terpisah, catat versi bidang kontrol dan setiap kumpulan node 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, kumpulan node di cluster pengguna, dan cluster admin.

Pastikan Anda menggunakan 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 perangkat Anda.

Saat Anda menetapkan --location=-, ini berarti mencantumkan semua cluster di semua region. Jika Anda perlu memperkecil 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 menampilkan versi Kubernetes. Untuk mendapatkan versi Google Distributed Cloud yang sesuai untuk versi Kubernetes, baca bagian 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 akan dirotasi, tetapi sertifikat CA tidak. Anda harus merotasi sertifikat CA secara manual setidaknya sekali setiap lima tahun. Untuk informasi selengkapnya, lihat Merotasi certificate authority cluster pengguna dan Merotasi sertifikat CA cluster admin.

Perbedaan berbagai jenis cluster

Ada dua jenis cluster yang berbeda:

Cluster pengguna
Cluster Admin

Bergantung pada cara Anda membuat cluster pengguna, cluster mungkin berisi node pekerja dan node bidang kontrol (Controlplane V2) atau hanya node pekerja (kubeception). Dengan kubeception, bidang kontrol untuk cluster pengguna berjalan pada satu atau beberapa node dalam cluster admin. Pada kedua kasus tersebut, pada versi 1.14 dan yang lebih baru, Anda dapat mengupgrade bidang kontrol cluster pengguna secara terpisah dari kumpulan node yang menjalankan beban kerja.

Efek yang berbeda dari upgrade cluster pengguna versus upgrade 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 dihabiskan dan menambahkannya ke cluster. Node pekerja yang terkuras kemudian dihapus dari inventaris VMware. Selama proses ini, beban kerja apa pun yang berjalan pada node ini akan dihentikan dan dimulai ulang pada node lain yang tersedia di cluster.

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

Gangguan cluster pengguna

Tabel berikut menjelaskan dampak upgrade cluster pengguna yang diterapkan:

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
Auto 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 dapat 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 dikosongkan, lalu diperbarui sebagaimana mestinya.

Di lingkungan dengan bidang kontrol ketersediaan tinggi (HA), mengupgrade bidang kontrol cluster pengguna tidak mengganggu workload pengguna. Dalam lingkungan HA, mengupgrade cluster admin tidak mengganggu workload 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 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 bidang kontrol (mode ketersediaan tinggi).

Gangguan cluster admin

Tabel berikut menjelaskan dampak upgrade cluster admin yang diterapkan:

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
Autoscaler Pod	Terpengaruh	Terpengaruh	Tidak terpengaruh
Perbaikan Otomatis	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 dapat terjadi dalam waktu yang sangat singkat, tetapi hampir tidak terlihat.

Langkah selanjutnya

Mengupgrade cluster Anthos di VMware