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.
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
, dankube-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 perlu menambahkan alamat IP, perbarui file blok IP, lalu jalankan
Perintah
- 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 perintahgkectl diagnose
menampilkan peringatanCluster 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
Gkectl
Untuk memeriksa versi cluster pengguna:
gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Ganti
ADMIN_CLUSTER_KUBECONFIG
dengan jalur {i>kubeconfig<i} 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 pada 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 Anda project host perangkat.Saat Anda menetapkan
--location=-
, itu berarti membuat daftar semua cluster dalam semua region. Jika Anda perlu memperkecil daftar, tetapkan--location
ke region yang ditentukan 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 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:
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 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:
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 |
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 proses upgrade selesai.
- Tidak terpengaruh: gangguan layanan dapat terjadi dalam waktu yang sangat singkat waktu, tetapi hampir tidak terlihat.