Saat Anda mengupgrade Google Distributed Cloud, proses upgrade melibatkan beberapa langkah dan komponen. Untuk membantu memantau status upgrade atau mendiagnosis dan memecahkan masalah, sebaiknya ketahui apa yang terjadi saat Anda menjalankan perintah bmctl upgrade
cluster. Dokumen ini menjelaskan detail komponen dan tahap upgrade cluster.
Ringkasan
Proses upgrade memindahkan cluster Google Distributed Cloud Anda dari versi saat ini ke versi yang lebih tinggi.
Informasi versi ini disimpan di lokasi berikut sebagai bagian dari resource kustom cluster di cluster admin:
status.anthosBareMetalVersion: menentukan versi cluster saat ini.spec.anthosBareMetalVersion: menentukan versi target, dan ditetapkan saat proses upgrade mulai berjalan.
Operasi upgrade yang berhasil akan menyelaraskan
status.anthosBareMetalVersion dengan
spec.anthosBareMetalVersion sehingga keduanya menampilkan
versi target.
Perbedaan versi cluster
Perbedaan versi cluster adalah perbedaan versi antara cluster pengelola (hybrid atau admin) dan cluster pengguna terkelolanya. Saat Anda menambahkan atau mengupgrade cluster pengguna, aturan versi berikut berlaku:
1.30 dan yang lebih baru
Aturan berikut berlaku untuk cluster pengguna yang dikelola oleh cluster admin atau cluster hybrid versi 1.30 atau yang lebih baru:
Versi cluster pengguna tidak boleh lebih tinggi dari versi cluster pengelola (admin atau hybrid).
Cluster pengguna dapat memiliki hingga dua versi minor di bawah versi cluster pengelola. Misalnya, cluster admin versi 1.30 dapat mengelola cluster pengguna 1.28. Kemampuan pengelolaan perbedaan versi n-2 ini tersedia secara umum untuk mengelola cluster di versi 1.30.
Untuk cluster pengelola tertentu di versi 1.30 atau yang lebih baru, cluster pengguna tidak perlu memiliki versi minor yang sama satu sama lain. Misalnya, cluster admin versi 1.30 dapat mengelola cluster pengguna versi 1.30, versi 1.29, dan versi 1.28.
Kemampuan pengelolaan multi-skew memberi Anda fleksibilitas yang lebih besar untuk merencanakan upgrade inventaris. Misalnya, Anda tidak diwajibkan mengupgrade semua cluster pengguna versi 1.28 ke versi 1.29 sebelum dapat mengupgrade cluster admin ke versi 1.30.
1,29
Aturan berikut berlaku untuk cluster pengguna yang dikelola oleh cluster admin atau cluster hybrid versi 1.29:
Versi cluster pengguna tidak boleh lebih tinggi dari versi cluster pengelola (admin atau hybrid).
(1.29 Pratinjau) Cluster pengguna dapat memiliki versi hingga dua versi minor di bawah versi cluster pengelola. Misalnya, cluster admin versi 1.29 dapat mengelola cluster pengguna versi 1.16. Pengelolaan penyimpangan versi n-2 ini tersedia sebagai kemampuan Pratinjau untuk mengelola cluster di versi 1.29.
(1.29 Pratinjau) Untuk cluster pengelola tertentu, cluster pengguna tidak harus memiliki versi minor yang sama satu sama lain. Misalnya, cluster admin versi 1.29 dapat mengelola cluster pengguna versi 1.29, versi 1.28, dan versi 1.16. Pengelolaan perbedaan versi campuran ini tersedia sebagai kemampuan Pratinjau untuk mengelola cluster di versi 1.29.
Kemampuan pengelolaan multi-miring Pratinjau memberi Anda fleksibilitas yang lebih besar untuk merencanakan upgrade perangkat. Misalnya, Anda tidak diwajibkan mengupgrade semua cluster pengguna versi 1.16 ke versi 1.28 sebelum dapat mengupgrade cluster admin ke versi 1.29.
1.28 dan yang lebih lama
Aturan berikut berlaku untuk cluster pengguna yang dikelola oleh cluster admin versi 1.28 atau yang lebih lama atau cluster hybrid:
Versi cluster pengguna tidak boleh lebih tinggi dari versi cluster pengelola (admin atau hybrid).
Cluster pengguna dapat memiliki versi hingga satu versi minor di bawah versi cluster pengelola. Misalnya, cluster admin versi 1.28 tidak dapat mengelola cluster pengguna di versi 1.15.
Untuk cluster pengelola tertentu, semua cluster pengguna terkelola harus berada di versi minor yang sama.
Untuk mengetahui informasi tentang aturan perbedaan versi untuk node pool, lihat Aturan pembuatan versi node pool.
Aturan versi
Saat mendownload dan menginstal bmctl versi baru, Anda dapat mengupgrade
cluster admin, hybrid, mandiri, dan pengguna yang dibuat atau diupgrade dengan bmctl versi
sebelumnya. Cluster tidak dapat didowngrade ke versi yang lebih rendah.
Anda hanya dapat mengupgrade cluster ke versi yang cocok dengan
versi bmctl yang Anda gunakan. Artinya, jika Anda menggunakan bmctl versi 1.32.100-gke.106, Anda hanya dapat mengupgrade cluster ke versi 1.32.100-gke.106.
Upgrade versi patch
Untuk versi minor tertentu, Anda dapat mengupgrade ke versi patch yang lebih tinggi. Artinya,
Anda dapat mengupgrade cluster versi 1.32.X
ke versi
1.32.Y selama
Y lebih besar daripada
X. Misalnya, Anda dapat mengupgrade dari
1.31.0 ke 1.31.100 dan Anda dapat mengupgrade dari
1.31.100 ke 1.31.300. Sebaiknya upgrade
ke versi patch terbaru jika memungkinkan untuk memastikan cluster Anda memiliki
perbaikan keamanan terbaru.
Upgrade versi minor
Anda dapat mengupgrade cluster dari satu versi minor ke versi berikutnya, terlepas dari versi patch-nya. Artinya, Anda dapat mengupgrade dari
1.N.X ke
1.N+1.Y, dengan
1.N.X adalah versi
cluster Anda dan N+1 adalah versi minor
berikutnya yang tersedia. Versi patch, X dan
Y, tidak memengaruhi logika upgrade dalam kasus ini. Misalnya, Anda dapat mengupgrade dari 1.31.600-gke.85 ke
1.32.100-gke.106.
Anda tidak dapat melewati versi minor saat mengupgrade cluster. Jika Anda mencoba mengupgrade
ke versi minor yang dua atau lebih versi minor lebih tinggi daripada versi
cluster saat ini, bmctl akan memunculkan error. Misalnya, Anda tidak dapat mengupgrade cluster
versi 1.30.0 ke versi 1.32.0 dalam satu langkah.
Seperti yang dijelaskan sebelumnya, cluster admin dapat mengelola cluster pengguna yang menggunakan versi yang sama atau lebih rendah. Perbedaan versi antara cluster pengguna dan cluster pengelolanya (terkadang disebut sebagai perbedaan versi) bervariasi menurut versi cluster. Sebelum mengupgrade cluster pengelola ke versi minor baru, pastikan versi cluster pengguna terkelola akan tetap mematuhi aturan perbedaan versi cluster untuk versi upgrade target.
Aturan pembuatan versi node pool
Saat Anda mengupgrade node pool secara selektif, aturan versi berikut berlaku:
1.30 dan yang lebih baru
Versi cluster harus lebih besar dari atau sama dengan versi node pool pekerja.
Perbedaan versi maksimum antara kumpulan node pekerja dan cluster adalah dua versi minor.
Kumpulan node pekerja dapat berada di versi patch apa pun dari versi minor yang kompatibel.
1,29
Versi cluster harus lebih besar dari atau sama dengan versi node pool pekerja.
(1.29 GA) Perbedaan versi maksimum antara kumpulan node pekerja dan cluster adalah dua versi minor.
Node pool pekerja tidak boleh menggunakan versi yang dirilis secara kronologis lebih baru daripada versi cluster. Rilis sebelumnya tidak memiliki detail komprehensif untuk rilis berikutnya, yang merupakan persyaratan untuk kompatibilitas.
Misalnya, versi 1.16.6 dirilis setelah versi 1.28.100-gke.146 dirilis, sehingga Anda tidak dapat mengupgrade cluster dari versi 1.16.6 ke versi 1.28.100-gke.146 dan membiarkan kumpulan node pekerja di versi 1.16.6. Demikian pula, jika Anda mengupgrade cluster ke versi 1.28.100-gke.146, tetapi memilih untuk membiarkan node pool pekerja di versi 1.16.5, Anda tidak dapat mengupgrade node pool pekerja ke versi 1.16.6 saat cluster berada di versi 1.28.100-gke.146.
1,28
Versi cluster harus lebih besar dari atau sama dengan versi node pool pekerja.
(1.28 Pratinjau) Perbedaan versi maksimum antara node pool pekerja dan cluster adalah dua versi minor jika fitur n-2 Pratinjau diaktifkan. Jika Anda tidak mengaktifkan kemampuan ini, perbedaan versi maksimum antara kumpulan node pekerja dan cluster adalah satu versi minor.
Node pool pekerja tidak boleh menggunakan versi yang dirilis secara kronologis lebih baru daripada versi cluster. Rilis sebelumnya tidak memiliki detail komprehensif untuk rilis berikutnya, yang merupakan persyaratan untuk kompatibilitas.
Misalnya, versi 1.16.6 dirilis setelah versi 1.28.100-gke.146 dirilis, sehingga Anda tidak dapat mengupgrade cluster dari versi 1.16.6 ke versi 1.28.100-gke.146 dan membiarkan kumpulan node pekerja di versi 1.16.6. Demikian pula, jika Anda mengupgrade cluster ke versi 1.28.100-gke.146, tetapi memilih untuk membiarkan node pool pekerja di versi 1.16.5, Anda tidak dapat mengupgrade node pool pekerja ke versi 1.16.6 saat cluster berada di versi 1.28.100-gke.146.
1.16
Versi cluster harus lebih besar dari atau sama dengan versi node pool pekerja.
Perbedaan versi maksimum antara kumpulan node pekerja dan cluster adalah satu versi minor.
Node pool pekerja tidak boleh menggunakan versi yang dirilis secara kronologis lebih baru daripada versi cluster. Rilis sebelumnya tidak memiliki detail komprehensif untuk rilis berikutnya, yang merupakan persyaratan untuk kompatibilitas.
Misalnya, versi 1.16.6 dirilis setelah versi 1.28.100-gke.146 dirilis, sehingga Anda tidak dapat mengupgrade cluster dari versi 1.16.6 ke versi 1.28.100-gke.146 dan membiarkan kumpulan node pekerja di versi 1.16.6. Demikian pula, jika Anda mengupgrade cluster ke versi 1.28.100-gke.146, tetapi memilih untuk membiarkan node pool pekerja di versi 1.16.5, Anda tidak dapat mengupgrade node pool pekerja ke versi 1.16.6 saat cluster berada di versi 1.28.100-gke.146.
Tabel berikut mencantumkan versi kumpulan node yang didukung yang diizinkan untuk versi cluster tertentu:
1.30 dan yang lebih baru
Untuk versi cluster 1.30 dan yang lebih baru, versi node pool dapat lebih rendah hingga dua versi minor. Semua versi patch kumpulan node dalam versi minor yang kompatibel kompatibel.
1,29
| Versi cluster (bidang kontrol) | Versi kumpulan node pekerja yang didukung (versi yang ditambahkan dalam huruf tebal) | |||
|---|---|---|---|---|
| 1.29.1200-gke.98 |
|
|
|
|
| 1.29.1100-gke.84 |
|
|
|
|
| 1.29.1000-gke.93 |
|
|
|
|
| 1.29.900-gke.180 |
|
|
|
|
| 1.29.800-gke.111 |
|
|
|
|
| 1.29.700-gke.113 |
|
|
|
|
| 1.29.600-gke.105 |
|
|
|
|
| 1.29.500-gke.162 |
|
|
|
|
| 1.29.400-gke.86 |
|
|
|
|
| 1.29.300-gke.185 |
|
|
|
|
| 1.29.200-gke.243 |
|
|
|
|
| 1.29.100-gke.251 |
|
|
|
|
| 1.29.0-gke.1449 |
|
|
|
|
1,28
| Versi cluster (bidang kontrol) | Versi kumpulan node pekerja yang didukung (versi yang ditambahkan dalam huruf tebal) | |||
|---|---|---|---|---|
| 1.28.1400-gke.79 |
|
|
|
|
| 1.28.1300-gke.59 |
|
|
|
|
| 1.28.1200-gke.83 |
|
|
|
|
| 1.28.1100-gke.94 |
|
|
|
|
| 1.28.1000-gke.60 |
|
|
|
|
| 1.28.900-gke.112 |
|
|
|
|
| 1.28.800-gke.111 |
|
|
|
|
| 1.28.700-gke.150 |
|
|
|
|
| 1.28.600-gke.163 |
|
|
|
|
| 1.28.500-gke.120 |
|
|
|
|
| 1.28.400-gke.77 |
|
|
|
|
| 1.28.300-gke.131 |
|
|
|
|
| 1.28.200-gke.118 |
|
|
|
|
| 1.28.100-gke.146 |
|
|
|
|
| 1.28.0-gke.425 |
|
|
|
|
1.16
| Versi cluster (bidang kontrol) | Versi kumpulan node pekerja yang didukung (versi yang ditambahkan dalam huruf tebal) | |||
|---|---|---|---|---|
| 1.16.12 |
|
|
|
|
| 1.16.11 |
|
|
|
|
| 1.16.10 |
|
|
|
|
| 1.16.9 |
|
|
|
|
| 1.16.8 |
|
|
|
|
| 1.16.7 |
|
|
|
|
| 1.16.6 |
|
|
|
|
| 1.16.5 |
|
|
|
|
| 1.16.4 |
|
|
|
|
| 1.16.3 |
|
|
|
|
| 1.16.2 |
|
|
|
|
| 1.16.1 |
|
|
||
| 1.16.0 |
|
|
||
Mengupgrade komponen
Komponen diupgrade di tingkat node dan cluster. Di tingkat cluster, komponen berikut diupgrade:
- Komponen cluster untuk jaringan, kemampuan observasi, dan penyimpanan.
- Untuk cluster admin, hybrid, dan mandiri, pengontrol siklus proses.
gke-connect-agent.
Node dalam cluster berjalan sebagai salah satu peran berikut, dengan komponen berbeda yang diupgrade, bergantung pada peran node:
| Peran node | Fungsi | Komponen yang akan diupgrade |
|---|---|---|
| Pekerja | Menjalankan workload pengguna | Kubelet, runtime container (Docker atau containerd) |
| Bidang kontrol | Menjalankan bidang kontrol Kubernetes, pengontrol siklus proses cluster, dan add-on platform edisi Google Kubernetes Engine (GKE) Enterprise | Pod statis bidang kontrol Kubernetes (kubeapi-server,
kube-scheduler, kube-controller-manager, etcd)
Pengontrol siklus proses seperti lifecycle-controllers-manager dan
anthos-cluster-operatorAdd-on platform edisi Google Kubernetes Engine (GKE) Enterprise seperti stackdriver-log-aggregator dan
gke-connect-agent |
| Load balancer bidang kontrol | Menjalankan HAProxy dan Keepalived yang melayani traffic ke
kube-apiserver, dan menjalankan speaker MetalLB untuk mengklaim alamat
IP virtual |
Pod statis load balancer bidang kontrol (HAProxy, Keepalived)
Speaker MetalLB |
Perkiraan waktu istirahat
Tabel berikut menjelaskan detail perkiraan periode nonaktif dan potensi dampak saat Anda mengupgrade cluster. Tabel ini mengasumsikan Anda memiliki beberapa node cluster dan bidang kontrol HA. Jika Anda menjalankan cluster mandiri atau tidak memiliki bidang kontrol HA, akan ada periode nonaktif tambahan. Kecuali dinyatakan lain, periode nonaktif ini berlaku untuk upgrade cluster admin dan pengguna:
| Komponen | Ekspektasi periode nonaktif | Saat periode nonaktif terjadi |
|---|---|---|
Server API bidang kontrol Kubernetes (kube-apiserver),
etcd, dan scheduler |
Tanpa periode nonaktif | T/A |
Pengontrol siklus proses dan tugas ansible-runner (khusus cluster
admin) |
Tanpa periode nonaktif | T/A |
Bidang kontrol Kubernetes loadbalancer-haproxy dan
keepalived |
Periode nonaktif sementara (kurang dari 1 hingga 2 menit) saat load balancer mengarahkan ulang traffic. | Awal proses upgrade. |
Kemampuan observasi pipeline-stackdriver dan
metrics-server |
Operator dikuras dan diupgrade. Waktu nonaktif harus kurang dari 5 menit.
DaemonSet terus berfungsi tanpa periode nonaktif. |
Setelah node bidang kontrol selesai diupgrade. |
| Antarmuka jaringan container (CNI) | Tidak ada periode nonaktif untuk rute jaringan yang ada. DaemonSet di-deploy dua per dua tanpa periode nonaktif. Operator dikuras dan diupgrade. Waktu nonaktif kurang dari 5 menit. |
Setelah node bidang kontrol selesai diupgrade. |
| MetalLB (khusus cluster pengguna) | Operator dikuras dan diupgrade. Waktu nonaktif kurang dari 5 menit.
Tidak ada periode nonaktif untuk layanan yang ada |
Setelah node bidang kontrol selesai diupgrade. |
| CoreDNS dan autoscaler DNS (khusus cluster pengguna) | CoreDNS memiliki beberapa replika dengan autoscaler. Biasanya tidak ada periode nonaktif. | Setelah node bidang kontrol selesai diupgrade. |
| Penyedia volume lokal | Tidak ada periode nonaktif untuk volume persisten (PV) yang disediakan.
Operator mungkin mengalami periode nonaktif selama 5 menit. |
Setelah node bidang kontrol selesai diupgrade. |
| Istio / ingress | Operator Istio dikuras dan diupgrade. Waktu nonaktif sekitar 5 menit. Ingress yang sudah dikonfigurasi akan terus berfungsi. |
Setelah node bidang kontrol selesai diupgrade. |
| Operator sistem lainnya | Waktu nonaktif 5 menit saat daya habis dan diupgrade. | Setelah node bidang kontrol selesai diupgrade. |
| Workload pengguna | Bergantung pada penyiapan, seperti apakah memiliki ketersediaan tinggi. Tinjau deployment workload Anda sendiri untuk memahami potensi dampaknya. |
Saat worker node diupgrade. |
Detail upgrade cluster pengguna
Bagian ini menjelaskan urutan upgrade komponen dan informasi status untuk upgrade cluster pengguna. Bagian berikut menjelaskan penyimpangan dari alur ini untuk upgrade cluster admin, hybrid, atau mandiri.
Diagram berikut menunjukkan proses pemeriksaan pra-penerbangan untuk upgrade cluster pengguna:
Diagram sebelumnya menjelaskan langkah-langkah yang terjadi selama upgrade:
- Perintah
bmctl upgrade clustermembuat resource kustomPreflightCheck. - Pemeriksaan pra-penerbangan ini menjalankan pemeriksaan tambahan seperti pemeriksaan upgrade cluster, pemeriksaan kondisi jaringan, dan pemeriksaan kondisi node.
- Hasil pemeriksaan tambahan ini digabungkan untuk melaporkan kemampuan cluster agar berhasil diupgrade ke versi target.
Jika pemeriksaan pra-peluncuran berhasil dan tidak ada masalah yang memblokir, komponen di cluster akan diupgrade dalam urutan tertentu, seperti yang ditunjukkan dalam diagram berikut:
Dalam diagram sebelumnya, komponen diupgrade secara berurutan sebagai berikut:
- Upgrade dimulai dengan memperbarui kolom
spec.anthosBareMetalVersion. - Load balancer bidang kontrol diupgrade.
- Node pool bidang kontrol diupgrade.
- Secara paralel, GKE Connect diupgrade, add-on cluster diupgrade, dan node pool load balancer diupgrade.
- Setelah node pool load balancer berhasil diupgrade, node pool pekerja akan diupgrade.
Setelah semua komponen diupgrade, health check cluster akan berjalan.
Pemeriksaan kondisi terus berjalan hingga semua pemeriksaan berhasil.
Setelah semua health check lulus, upgrade selesai.
Setiap komponen memiliki kolom statusnya sendiri di dalam resource kustom Cluster. Anda dapat memeriksa status di kolom ini untuk memahami progres upgrade:
| Urutan | Nama kolom | Arti |
|---|---|---|
| 1 | status.controlPlaneNodepoolStatus |
Status disalin dari status node pool bidang kontrol. Kolom mencakup versi node dari kumpulan node bidang kontrol |
| 2 | status.anthosBareMetalLifecycleControllersManifestsVersion
|
Versi lifecycles-controllers-manager yang diterapkan ke
cluster. Kolom ini hanya tersedia untuk cluster admin, mandiri, atau hybrid. |
| 2 | status.anthosBareMetalManifestsVersion |
Versi cluster dari manifes yang terakhir diterapkan. |
| 2 | status.controlPlaneLoadBalancerNodepoolStatus |
Status disalin dari status node pool load balancer bidang kontrol. Kolom ini kosong jika load balancer bidang kontrol terpisah tidak
ditentukan dalam Cluster.Spec. |
| 3 | status.anthosBareMetalVersions |
Peta versi gabungan dari versi ke nomor node. |
| 4 | status.anthosBareMetalVersion |
Status akhir versi yang diupgrade. |
Detail upgrade cluster admin, hybrid, dan mandiri
Mulai dari versi bmctl 1.15.0, perilaku upgrade default untuk cluster yang dikelola sendiri (admin, hybrid, atau mandiri) adalah upgrade di tempat.
Artinya, saat Anda mengupgrade cluster ke versi 1.15.0 atau yang lebih tinggi, upgrade
menggunakan pengontrol siklus proses, bukan cluster bootstrap, untuk mengelola seluruh
proses upgrade. Perubahan ini menyederhanakan proses dan mengurangi persyaratan resource, sehingga upgrade cluster menjadi lebih andal dan dapat diskalakan.
Meskipun tidak direkomendasikan, opsi untuk menggunakan cluster bootstrap untuk mengupgrade masih tersedia. Untuk menggunakan cluster bootstrap saat mengupgrade, jalankan perintah
bmctl upgrade dengan flag --use-bootstrap=true.
Tahapan upgrade berbeda-beda, bergantung pada metode yang Anda gunakan.
Upgrade di tempat
Proses upgrade di tempat default untuk cluster yang dikelola sendiri mirip dengan
proses upgrade cluster pengguna. Namun, saat Anda menggunakan proses upgrade di tempat, versi baru preflightcheck-operator akan di-deploy sebelum pemeriksaan pra-penerbangan cluster dan health check dijalankan:
Seperti upgrade cluster pengguna, proses upgrade dimulai dengan memperbarui kolom
Cluster.spec.anthosBareMetalVersion ke versi target. Dua
langkah tambahan dijalankan sebelum komponen diupdate, seperti yang ditunjukkan dalam
diagram berikut: lifecycle-controller-manager mengupgrade dirinya sendiri ke versi
target, lalu men-deploy versi target anthos-cluster-operator. Bagian ini
anthos-cluster-operator melakukan langkah-langkah yang tersisa dalam proses upgrade:
Jika berhasil, anthos-cluster-operator akan merekonsiliasi versi target dari
spec.anthosBareMetalVersion ke status.anthosBareMetalVersion.
Mengupgrade dengan cluster bootstrap
Proses mengupgrade cluster admin, hybrid, atau mandiri mirip dengan cluster pengguna yang dibahas di bagian sebelumnya.
Perbedaan utamanya adalah perintah bmctl upgrade cluster memulai proses
untuk membuat bootstrap cluster. Cluster bootstrap ini adalah cluster sementara
yang mengelola cluster hybrid, admin, atau mandiri selama upgrade.
Proses untuk mentransfer kepemilikan pengelolaan cluster ke cluster bootstrap disebut pivot. Upgrade lainnya mengikuti proses yang sama dengan upgrade cluster pengguna.
Selama proses upgrade, resource di cluster target tetap tidak aktif. Progres upgrade hanya tercermin dalam resource cluster bootstrap.
Jika perlu, Anda dapat mengakses cluster bootstrap untuk membantu memantau dan men-debug proses upgrade. Cluster bootstrap dapat diakses melalui
bmctl-workspace/.kindkubeconfig.
Untuk mentransfer kepemilikan pengelolaan cluster kembali setelah upgrade selesai, cluster akan memindahkan resource dari cluster bootstrap ke cluster yang diupgrade. Tidak ada langkah manual yang Anda lakukan untuk memutar cluster selama proses upgrade. Cluster bootstrap dihapus setelah upgrade cluster berhasil.
Pengosongan node
Upgrade cluster Google Distributed Cloud dapat menyebabkan gangguan aplikasi saat node dikosongkan. Proses penghentian ini menyebabkan semua Pod yang berjalan di node dimatikan dan dimulai ulang di node yang tersisa di cluster.
Deployment dapat digunakan untuk mentoleransi gangguan tersebut. Deployment dapat menentukan beberapa replika aplikasi atau layanan yang harus dijalankan. Aplikasi dengan beberapa replika akan mengalami sedikit atau tanpa gangguan selama upgrade.
PodDisruptionBudgets (PDB)
Saat Anda mengupgrade cluster, Google Distributed Cloud menggunakan alur mode pemeliharaan untuk menguras node.
Mulai rilis 1.29, node dikuras dengan Eviction API, yang mematuhi PodDisruptionBudgets (PDB). PDB dapat digunakan untuk memastikan sejumlah replika yang ditentukan selalu berjalan di cluster dalam kondisi berjalan normal.
PDB memungkinkan Anda membatasi gangguan pada workload saat Pod-nya perlu dijadwalkan ulang. Pengurasan node berbasis pengusiran tersedia sebagai GA untuk rilis 1.29.
Pada rilis 1.28 dan yang lebih lama, Google Distributed Cloud tidak mematuhi PDB saat pengurasan node selama upgrade. Sebaliknya, proses pengurasan node adalah upaya terbaik. Beberapa
Pod mungkin macet dalam status Terminating dan menolak untuk keluar dari node. Upgrade akan dilanjutkan, meskipun Pod mengalami masalah, saat proses pengurasan pada node memerlukan waktu lebih dari 20 menit.
Untuk mengetahui informasi selengkapnya, lihat Mengaktifkan mode pemeliharaan pada node.
Langkah berikutnya
- Tinjau praktik terbaik untuk upgrade Google Distributed Cloud
- Mengupgrade Google Distributed Cloud
- Memecahkan masalah upgrade cluster