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 komponen dan tahap upgrade
cluster.
Ringkasan
Proses upgrade akan 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 merekonsiliasi
status.anthosBareMetalVersion ke
spec.anthosBareMetalVersion sehingga keduanya menampilkan
versi target.
Skew versi cluster
Skew 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 akan berlaku:
1,30
Aturan berikut berlaku untuk cluster pengguna yang dikelola oleh cluster admin versi 1.30 atau cluster campuran:
Versi cluster pengguna tidak boleh lebih tinggi dari versi cluster pengelola (admin atau campuran).
(1.30 GA) 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 skew versi n-2 ini merupakan GA untuk mengelola cluster pada versi 1.30.
(1.30 GA) Untuk cluster pengelola tertentu pada versi 1.30, cluster pengguna tidak perlu memiliki versi minor yang sama. 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 armada. Misalnya, Anda tidak diwajibkan untuk 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 versi 1.29 atau cluster campuran:
Versi cluster pengguna tidak boleh lebih tinggi dari versi cluster pengelola (admin atau campuran).
(1.29 Pratinjau) Cluster pengguna dapat memiliki hingga dua versi minor di bawah versi cluster pengelola. Misalnya, cluster admin versi 1.29 dapat mengelola cluster pengguna 1.16. Pengelolaan skew versi n-2 ini tersedia sebagai kemampuan Pratinjau untuk mengelola cluster pada versi 1.29.
(1.29 Pratinjau) Untuk cluster pengelolaan tertentu, cluster pengguna tidak perlu memiliki versi minor yang sama dengan cluster lainnya. Misalnya, cluster admin versi 1.29 dapat mengelola cluster pengguna versi 1.29, versi 1.28, dan versi 1.16. Pengelolaan skew versi campuran ini tersedia sebagai kemampuan Pratinjau untuk mengelola cluster pada versi 1.29.
Kemampuan pengelolaan multi-skew Pratinjau memberi Anda fleksibilitas yang lebih besar untuk merencanakan upgrade perangkat. Misalnya, Anda tidak diwajibkan untuk 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 atau cluster campuran versi 1.28 atau yang lebih lama:
Versi cluster pengguna tidak boleh lebih tinggi dari versi cluster pengelola (admin atau campuran).
Cluster pengguna dapat memiliki versi minor hingga satu versi di bawah versi cluster pengelola. Misalnya, cluster admin versi 1.28 tidak dapat mengelola cluster pengguna pada versi 1.15.
Untuk cluster pengelola tertentu, semua cluster pengguna terkelola harus berada di versi minor yang sama.
Untuk informasi tentang aturan penyimpangan versi untuk node pool, lihat Aturan pembuatan versi node pool.
Aturan versi
Saat mendownload dan menginstal bmctl versi baru, Anda dapat mengupgrade
cluster admin, campuran, 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 menggunakan versi
1.30.400-gke.133 dari bmctl, Anda hanya dapat mengupgrade cluster ke versi
1.30.400-gke.133.
Upgrade versi patch
Untuk versi minor tertentu, Anda dapat mengupgrade ke versi patch yang lebih tinggi. Artinya,
Anda dapat mengupgrade cluster versi
1.30.X ke versi
1.30.Y selama
Y lebih besar dari
X. Misalnya, Anda dapat mengupgrade dari
1.29.0 ke 1.29.100 dan Anda dapat mengupgrade dari
1.29.100 ke 1.29.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. 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. Dalam hal ini, versi patch, X dan
Y, tidak memengaruhi logika upgrade. Misalnya, Anda dapat mengupgrade dari 1.29.800-gke.111 ke
1.30.400-gke.133.
Anda tidak dapat melewati versi minor saat mengupgrade cluster. Jika Anda mencoba mengupgrade
ke versi minor yang dua versi minor atau lebih tinggi dari versi cluster
saat ini, bmctl akan menampilkan error. Misalnya, Anda tidak dapat mengupgrade
cluster versi 1.28.0 ke versi 1.30.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 penyimpangan versi) bervariasi menurut versi cluster. Sebelum mengupgrade cluster pengelola ke versi minor baru, pastikan versi cluster pengguna terkelola akan tetap mematuhi aturan kemiringan versi cluster untuk versi upgrade target.
Aturan pembuatan versi node pool
Saat Anda mengupgrade node pool secara selektif, aturan versi berikut akan berlaku:
1,30
Versi cluster harus lebih besar dari atau sama dengan versi node pool pekerja.
Penyimpangan versi maksimum antara kumpulan node pekerja dan cluster adalah dua versi minor.
Kumpulan node pekerja dapat berada di versi patch dari versi minor yang kompatibel.
1,29
Versi cluster harus lebih besar dari atau sama dengan versi node pool pekerja.
(1.29 GA) Penyimpangan versi maksimum antara kumpulan node pekerja dan cluster adalah dua versi minor.
Node pool pekerja tidak boleh menggunakan versi yang dirilis secara kronologis setelah 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 node pool pekerja pada 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) Penyimpangan versi maksimum antara node pool pekerja dan cluster adalah dua versi minor saat fitur Pratinjau penyimpangan versi n-2 diaktifkan. Jika Anda tidak mengaktifkan kemampuan ini, ketidaksesuaian versi maksimum antara kumpulan node pekerja dan cluster adalah satu versi minor.
Node pool pekerja tidak boleh menggunakan versi yang dirilis secara kronologis setelah 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 node pool pekerja pada 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.
Penyimpangan versi maksimum antara kumpulan node pekerja dan cluster adalah satu versi minor.
Node pool pekerja tidak boleh menggunakan versi yang dirilis secara kronologis setelah 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 node pool pekerja pada 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
Untuk node pool pada versi minor yang kompatibel, versi 1.29 atau versi 1.28, semua versi patch kompatibel dengan cluster pada versi patch apa pun dari versi minor 1.30.
1,29
| Versi cluster (bidang kontrol) | Versi kumpulan node pekerja yang didukung (versi yang ditambahkan dalam cetak tebal) | |||
|---|---|---|---|---|
| 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 cetak tebal) | |||
|---|---|---|---|---|
| 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 dicetak 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, observasi, dan penyimpanan.
- Untuk cluster admin, campuran, dan mandiri, pengontrol siklus proses.
gke-connect-agent.
Node dalam cluster berjalan sebagai salah satu peran berikut, dengan komponen yang berbeda 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 Enterprise Google Kubernetes Engine (GKE) | 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 Enterprise Google Kubernetes Engine (GKE) seperti stackdriver-log-aggregator dan
gke-connect-agent |
| Load balancer bidang kontrol | Menjalankan HAProxy dan Keepalived yang menyalurkan traffic ke
kube-apiserver, dan menjalankan speaker MetalLB untuk mengklaim alamat IP
virtual |
Pod statis load balancer bidang kontrol (HAProxy, Keepalived)
Speaker MetalLB |
Perkiraan periode nonaktif
Tabel berikut menjelaskan perkiraan periode nonaktif dan potensi dampaknya saat Anda mengupgrade cluster. Tabel ini mengasumsikan bahwa Anda memiliki beberapa node cluster dan bidang kontrol HA. Jika Anda menjalankan cluster mandiri atau tidak memiliki panel kontrol HA, perkirakan periode nonaktif tambahan. Kecuali jika dinyatakan lain, periode nonaktif ini berlaku untuk upgrade cluster admin dan pengguna:
| Komponen | Perkiraan periode nonaktif | Saat periode nonaktif terjadi |
|---|---|---|
Server API bidang kontrol Kubernetes (kube-apiserver),
etcd, dan penjadwal |
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 mengalihkan traffic. | Awal proses upgrade. |
Kemampuan observasi pipeline-stackdriver dan
metrics-server |
Operator dikosongkan dan diupgrade. Waktu nonaktif harus kurang dari 5 menit.
DaemonSet terus berfungsi tanpa periode nonaktif. |
Setelah node control plane 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 dikosongkan dan diupgrade. Periode nonaktif kurang dari 5 menit. |
Setelah node control plane selesai diupgrade. |
| MetalLB (khusus cluster pengguna) | Operator dikosongkan dan diupgrade. Periode nonaktif kurang dari 5 menit.
Tidak ada periode nonaktif untuk layanan yang ada |
Setelah node control plane selesai diupgrade. |
| CoreDNS dan autoscaler DNS (khusus cluster pengguna) | CoreDNS memiliki beberapa replika dengan autoscaler. Biasanya tidak ada periode nonaktif. | Setelah node control plane 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 control plane selesai diupgrade. |
| Istio / ingress | Operator Istio dikosongkan dan diupgrade. Periode nonaktif
sekitar 5 menit. Ingress yang sudah dikonfigurasi akan terus berfungsi. |
Setelah node control plane selesai diupgrade. |
| Operator sistem lainnya | Periode nonaktif 5 menit saat baterai habis dan diupgrade. | Setelah node control plane selesai diupgrade. |
| Beban kerja pengguna | Bergantung pada penyiapan, seperti apakah sangat tersedia. Tinjau deployment workload Anda sendiri untuk memahami potensi dampaknya. |
Saat node pekerja 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-penerbangan berhasil dan tidak ada masalah pemblokiran, komponen dalam cluster akan diupgrade dalam urutan yang ditentukan, seperti yang ditunjukkan dalam diagram berikut:
Pada diagram sebelumnya, komponen diupgrade secara berurutan sebagai berikut:
- Upgrade dimulai dengan memperbarui kolom
spec.anthosBareMetalVersion. - Load balancer control plane diupgrade.
- Node pool bidang kontrol diupgrade.
- Secara paralel, GKE Connect diupgrade, add-on cluster diupgrade, dan node pool load balancer diupgrade.
- Setelah kumpulan node load balancer berhasil diupgrade, kumpulan node pekerja akan diupgrade.
Setelah semua komponen diupgrade, health check cluster akan berjalan.
Pemeriksaan kondisi terus berjalan hingga semua pemeriksaan lulus.
Jika semua pemeriksaan kondisi lulus, upgrade akan 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 ini menyertakan versi node kumpulan node bidang kontrol |
| 2 | status.anthosBareMetalLifecycleControllersManifestsVersion
|
Versi lifecycles-controllers-manager yang diterapkan ke
cluster. Kolom ini hanya tersedia untuk cluster admin, mandiri, atau hibrida. |
| 2 | status.anthosBareMetalManifestsVersion |
Versi cluster dari manifes yang terakhir diterapkan. |
| 2 | status.controlPlaneLoadBalancerNodepoolStatus |
Status disalin dari status kumpulan node load balancer bidang kontrol. Kolom ini kosong jika tidak ada load balancer bidang kontrol terpisah yang ditentukan di 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 bmctl versi 1.15.0, perilaku upgrade default untuk
cluster yang dikelola sendiri (admin, campuran, atau mandiri) adalah upgrade langsung.
Artinya, saat Anda mengupgrade cluster ke versi 1.15.0 atau yang lebih tinggi, upgrade tersebut
akan 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 skalabel.
Meskipun penggunaan cluster bootstrap untuk upgrade tidak direkomendasikan, opsi ini
masih tersedia. Untuk menggunakan cluster bootstrap saat mengupgrade, jalankan perintah bmctl upgrade dengan flag --use-bootstrap=true.
Tahapan upgrade berbeda, bergantung pada metode yang Anda
gunakan.
Upgrade langsung
Proses upgrade in-place default untuk cluster yang dikelola sendiri mirip dengan
proses upgrade cluster pengguna. Namun, saat Anda menggunakan proses upgrade di tempat, versi baru preflightcheck-operator 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. anthos-cluster-operator ini
akan melakukan langkah-langkah yang tersisa dari proses upgrade:
Setelah berhasil, anthos-cluster-operator akan merekonsiliasi versi target dari
spec.anthosBareMetalVersion ke status.anthosBareMetalVersion.
Mengupgrade dengan cluster bootstrap
Proses untuk mengupgrade cluster admin, campuran, atau mandiri mirip dengan cluster pengguna yang dibahas di bagian sebelumnya.
Perbedaan utamanya adalah perintah bmctl upgrade cluster memulai proses
untuk membuat cluster bootstrap. Cluster bootstrap ini adalah cluster sementara
yang mengelola cluster campuran, 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 berlaku. 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 kembali kepemilikan pengelolaan cluster setelah upgrade selesai, cluster akan memutar 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 karena 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 tidak ada gangguan selama upgrade.
PodDisruptionBudgets (PDB)
Saat Anda mengupgrade cluster, Google Distributed Cloud menggunakan alur mode pemeliharaan untuk menghabiskan node.
Mulai rilis 1.29, node dikosongkan dengan Eviction API, yang
menghormati PodDisruptionBudgets (PDB). PDB dapat digunakan untuk memastikan bahwa jumlah replika yang ditentukan selalu berjalan di cluster dalam kondisi berjalan normal.
PDB memungkinkan Anda membatasi gangguan pada workload saat Pod-nya perlu
dijadwalkan ulang. Pengosongan 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 node
habis selama upgrade. Sebagai gantinya, proses pengosongan node adalah upaya terbaik. Beberapa Pod mungkin terjebak dalam status Terminating dan menolak untuk mengosongkan node. Upgrade
akan dilanjutkan, bahkan dengan Pod yang macet, jika proses pengosongan di node
memerlukan waktu lebih dari 20 menit.
Untuk informasi selengkapnya, lihat Memasukkan node ke dalam mode pemeliharaan.
Langkah selanjutnya
- Tinjau praktik terbaik untuk upgrade Google Distributed Cloud
- Mengupgrade Google Distributed Cloud
- Memecahkan masalah upgrade cluster