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 cara 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 kritis seperti test, dan memverifikasi fungsi upgrade. Setelah Anda memverifikasi bahwa upgrade berhasil, lanjutkan ke lingkungan berikutnya. Ulangi proses ini hingga Anda mengupgrade lingkungan produksi. Pendekatan ini memungkinkan Anda beralih dari satu titik penting ke langkah berikutnya, dan memverifikasi bahwa upgrade dan beban kerja Anda semuanya berjalan dengan benar.

Upgrade checklist

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

Merencanakan upgrade

Update dapat mengganggu. Sebelum Anda memulai peningkatan, rencanakan dengan saksama untuk memastikan bahwa 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 node node akan diupgrade secara berurutan. Jadi total waktu untuk peningkatan bergantung pada jumlah node dalam kumpulan node terbesar. Untuk menghitung perkiraan perkiraan waktu upgrade, gunakan 15 menit * jumlah node dalam kumpulan node terbesar. Misalnya, jika Anda memiliki 10 node di kumpulan terbesar, total waktu upgrade akan menjadi sekitar 150 menit.

Di versi 1.28 dan yang lebih baru, Anda dapat mempercepat upgrade dengan menetapkan nilai maxSurge untuk tiap 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. dll. 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 tersebut. Untuk informasi selengkapnya, lihat cara mencadangkan cluster pengguna.

Dengan Google Distributed Cloud versi 1.8 dan yang lebih baru, Anda dapat menyiapkan cadangkan dengan clusterBackup.datastore di file konfigurasi cluster admin. Untuk mengaktifkan fitur ini di cluster, 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 di datastore vSphere yang dikonfigurasi. Proses pencadangan ini berulang setiap kali ada perubahan pada kelompok admin. Saat Anda memulai sebelum mengupgrade cluster, tugas pencadangan akan dijalankan 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 hal-hal yang tidak diinginkan periode nonaktif atau pemadaman aplikasi. PDB menginstruksikan penjadwal untuk selalu menyimpan jumlah Pod yang berjalan sementara Pod lainnya mungkin gagal. Perilaku ini merupakan berguna untuk menyediakan ketersediaan aplikasi.

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

   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 yang tersedia. Ketersediaan ini penting selama upgrade jika node terkuras.

Periksa PDB yang tidak dapat dipenuhi. Misalnya, Anda dapat menetapkan ketersediaan 1, jika Deployment hanya menampilkan 1 replika. Di sini contoh, operasi pengosongan 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 sementara mengubah atau menonaktifkan PDB 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. Untuk mempelajari PDB lebih lanjut, lihat Menentukan Anggaran Gangguan untuk Aplikasi.

Meninjau alamat IP yang tersedia

Pertimbangan alamat IP berikut berlaku selama upgrade cluster:

• Proses upgrade cluster akan membuat node baru dan menguras resource sebelum {i>node<i} yang lama akan dihapus. Sebaiknya Anda selalu memiliki alamat IP N+1 untuk cluster admin atau pengguna, dengan N adalah jumlah node dalam cluster.
• Bila menggunakan alamat IP statis, alamat IP yang diperlukan harus tercantum di file blok IP.
• Jika Anda menggunakan DHCP, pastikan VM baru bisa 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 informasi selengkapnya, lihat Rencanakan alamat IP Anda.
• Jika Anda menggunakan alamat IP statis dan ingin mempercepat upgrade cluster pengguna , buat daftar alamat IP yang cukup di file blok IP Anda sehingga setiap kumpulan node dapat memiliki alamat IP tambahan. Pendekatan ini memungkinkan kecepatan proses prosedur penambahan dan penghapusan VM seperti yang dilakukan pada kumpulan per node layanan.
  • Meskipun pendekatan ini adalah pilihan yang baik untuk mempercepat upgrade cluster pengguna, pertimbangkan ketersediaan resource dan performa vSphere Anda lingkungan sebelum melanjutkan.
• Jika hanya ada satu IP cadangan untuk seluruh cluster pengguna, pembatasan ini memperlambat proses upgrade ke hanya satu VM pada satu waktu, bahkan ketika beberapa kumpulan data yang digunakan.

Memeriksa penggunaan cluster

Pastikan Pod dapat dievakuasi saat node terkuras dan di sana memiliki cukup resource dalam cluster yang sedang diupgrade untuk mengelola upgrade. Kepada 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 cluster saat ini penggunaan resource. Dasbor dapat menyediakan tampilan yang lebih rinci dari sumber daya yang yang dikonsumsi dari waktu ke waktu. Data penggunaan resource ini dapat membantu menunjukkan kapan upgrade akan menyebabkan gangguan yang paling sedikit, misalkan selama akhir pekan atau malam hari, tergantung untuk workload dan kasus penggunaan yang berjalan.

Waktu untuk upgrade cluster admin mungkin kurang penting dibandingkan untuk karena upgrade cluster admin biasanya tidak memperkenalkan periode nonaktif aplikasi. Namun, penting untuk memeriksa sumber daya gratis yang di vSphere sebelum Anda memulai upgrade cluster admin. Selain itu, mengupgrade admin mungkin menyiratkan risiko tertentu, dan oleh karena itu mungkin direkomendasikan dalam periode penggunaan aktif saat akses pengelolaan ke cluster tidak terlalu penting.

Untuk informasi selengkapnya, lihat layanan apa yang terdampak 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 Summary menunjukkan keseluruhan konsumsi memori, CPU, dan penyimpanan seluruh cluster. Karena upgrade Google Distributed Cloud memerlukan tambahan resource tambahan ini, Anda juga harus memeriksa apakah cluster dapat menangani resource tambahan ini permintaan resource.

Pada dasarnya, cluster vSphere harus dapat mendukung referensi tambahan:

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

Misalnya, asumsikan bahwa cluster pengguna memiliki 3 kumpulan node tempat setiap node memiliki node yang menggunakan 8 vCPU dan RAM 32 GB atau lebih. Karena upgrade terjadi secara paralel untuk 3 kumpulan node 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. Menggandakan beberapa VM dari template dapat menimbulkan tekanan pada penyimpanan yang mendasarinya dalam bentuk peningkatan operasi I/O. Upgrade dapat sangat diperlambat jika subsistem penyimpanan yang mendasarinya tidak mampu menyediakan performa selama upgrade.

Sementara vSphere dirancang untuk penggunaan sumber daya simultan dan memiliki mekanisme untuk menyediakan resource, bahkan jika terjadi permintaan berlebih, sebaiknya jangan melakukan overcommiting pada memori VM. Terlalu banyak komitmen dalam memori dapat menyebabkan dampak performa yang memengaruhi seluruh cluster karena vSphere menyediakan "RAM tidak ada" untuk menukar halaman ke datastore. Perilaku ini dapat menyebabkan terhadap 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 sehat. Perintah tersebut menjalankan pemeriksaan lanjutan, seperti untuk mengidentifikasi node yang tidak dikonfigurasi dengan benar, atau yang memiliki Pod dengan status macet. Jika perintah gkectl diagnose menampilkan peringatan Cluster unhealthy, perbaiki sebelum mencoba melakukan upgrade. Untuk informasi selengkapnya, lihat Mendiagnosis masalah cluster.

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

Selain itu, saat Anda mengupgrade cluster pengguna ke versi 1.29 dan yang lebih tinggi, kami sebaiknya jalankan perintah gkectl upgrade cluster dengan tanda --dry-run. Flag --dry-run berjalan pemeriksaan preflight tetapi tidak memulai proses {i>upgrade<i}. Meskipun versi sebelumnya dari Google Distributed Cloud menjalankan pemeriksaan preflight, tidak dapat dijalankan secara terpisah dari melakukan upgrade. Dengan menambahkan tanda --dry-run, Anda dapat menemukan dan memperbaiki masalah apa pun yang ditemukan pemeriksaan preflight dengan cluster pengguna sebelum upgrade.

Menggunakan Deployment untuk meminimalkan gangguan aplikasi

Karena node harus dikuras selama update, upgrade cluster dapat menyebabkan dan gangguan pada aplikasi. Pengosongan node berarti bahwa 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 yang dirancang untuk menangani gangguan. Dampak apa pun harus minimal ke Deployment yang memiliki beberapa replika. Anda masih dapat mengupgrade cluster jika aplikasi tidak menggunakan Deployment.

Ada juga aturan untuk Deployment untuk memastikan bahwa 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, misalnya 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 diupgrade secara otomatis saat Anda mengupgrade . Upgrade ini dapat menyebabkan gangguan layanan. Untuk mengurangi dampak dan kegagalan load balancer akhir, Anda dapat menggunakan model (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, untuk server Kubernetes API), kami sebaiknya selalu gunakan pasangan ketersediaan tinggi (HA) di depan cluster admin. Untuk mempelajari lebih lanjut tentang Seesaw dan konfigurasi HA-nya, lihat Paket load balancing dengan Seesaw.

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

Sebaiknya Anda memiliki pasangan load balancer HA jika cluster pengguna 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, tidak diperlukan penyiapan pra-upgrade. Load balancer tersebut merupakan di-upgrade 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 kumpulan node dalam cluster), atau Anda dapat mengupgrade bidang kontrol cluster pengguna dan membiarkan kumpulan node tetap versi saat ini. Untuk informasi tentang mengapa Anda mungkin ingin meng-upgrade bidang kontrol secara terpisah. Untuk Upgrade cluster pengguna.

Dalam lingkungan multi-cluster, lacak cluster pengguna mana yang telah diupgrade dan mencatat 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

Periksa versi node cluster:

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

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Ganti USER_CLUSTER_KUBECONFIG dengan jalur 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 Merotasikan 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 kedua node pekerja dan bidang kontrol (Controlplane V2) atau hanya node pekerja (kubeception). Dengan kubeception, bidang kontrol untuk cluster pengguna berjalan pada satu atau beberapa node di cluster admin. Pada kedua kasus tersebut, pada versi 1.14 dan yang lebih baru, Anda bisa mengupgrade bidang kontrol cluster pengguna secara terpisah dari kumpulan node yang menjalankan sebagian besar workload standar dan berbasis cloud.

Efek yang berbeda dari upgrade cluster pengguna versus upgrade cluster admin

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

Tergantung pada arsitektur beban kerja yang dipilih, prosedur ini mungkin dampak pada ketersediaan aplikasi. Untuk menghindari terlalu banyak tekanan pada kemampuan resource cluster, Google Distributed Cloud mengupgrade satu node baik.

Gangguan cluster pengguna

Tabel berikut menjelaskan dampak cluster pengguna yang diterapkan peningkatan versi:

• * : PDB dapat menyebabkan upgrade gagal atau berhenti.
• Terpengaruh: gangguan layanan selama upgrade akan terlihat hingga proses upgrade selesai.
• Tidak terpengaruh: gangguan layanan dapat terjadi dalam waktu yang sangat singkat waktu, tetapi hampir tidak terlihat.

Node bidang kontrol cluster pengguna, baik yang berjalan di cluster admin (kubeception) atau cluster pengguna itu sendiri (Controlplane V2), jangan jalankan pengguna apa pun sebagian besar workload standar dan berbasis cloud. Selama upgrade, node bidang kontrol ini dikosongkan lalu diperbarui sebagaimana mestinya.

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

Selama upgrade di lingkungan bidang kontrol non-HA, bidang kontrol tidak bisa mengontrol tindakan penskalaan, pemulihan, atau deployment Pod. Selama video Shorts gangguan bidang kontrol selama upgrade, workload pengguna dapat terpengaruh jika instance berada dalam status penskalaan, deployment, atau pemulihan. Artinya bahwa 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 (ketersediaan tinggi ).

Gangguan cluster admin

Tabel berikut menjelaskan dampak cluster admin yang diterapkan peningkatan versi:

• Terpengaruh: gangguan layanan selama upgrade akan terlihat hingga proses upgrade selesai.
• Tidak terpengaruh: gangguan layanan dapat terjadi dalam waktu yang sangat singkat waktu, tetapi hampir tidak terlihat.

Langkah selanjutnya

• Mengupgrade cluster Anthos di VMware