Saat Anda mengupgrade GKE di Bare Metal, 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 GKE Anda di cluster Bare Metal 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 merekonsiliasi status.anthosBareMetalVersion
ke spec.anthosBareMetalVersion sehingga keduanya menampilkan versi target.
Kemiringan versi
Kecenderungan versi adalah perbedaan versi antara cluster admin dan cluster pengguna terkelolanya. Cluster GKE pada Bare Metal mengikuti gaya yang sama dengan Kubernetes: cluster admin dapat memiliki maksimal satu versi minor sebelum cluster terkelolanya.
Aturan versi untuk upgrade
Saat mendownload dan menginstal bmctl versi baru, Anda dapat mengupgrade
cluster admin, hybrid, mandiri, dan pengguna yang dibuat atau diupgrade dengan
versi bmctl yang lebih lama. 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 bmctl
versi 1.16.7, Anda dapat mengupgrade cluster ke versi
1.16.7 saja.
Melakukan patch upgrade versi
Untuk versi minor tertentu, Anda dapat mengupgrade ke versi patch yang lebih tinggi. Artinya,
Anda dapat mengupgrade cluster versi 1.16.X
ke versi
1.16.Y selama
Y lebih besar dari
X. Misalnya, Anda dapat mengupgrade dari
1.15.0 ke 1.15.1 dan dapat mengupgrade dari
1.15.1 ke 1.15.3. 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 minor berikutnya, terlepas dari
versi patch-nya. Artinya, Anda dapat melakukan upgrade 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 kasus ini, versi patch, X dan
Y, tidak memengaruhi logika upgrade. Misalnya, Anda dapat mengupgrade dari 1.15.3 ke 1.16.7.
Anda tidak dapat melewati versi minor saat mengupgrade cluster. Jika Anda mencoba melakukan upgrade ke versi minor yang memiliki dua atau beberapa versi minor yang lebih tinggi daripada versi cluster, bmctl akan menampilkan error. Misalnya, Anda tidak dapat mengupgrade cluster versi
1.14.0 ke versi 1.16.0.
Cluster admin dapat mengelola cluster pengguna yang berada di versi minor yang sama atau sebelumnya. Cluster pengguna terkelola tidak boleh lebih dari satu versi minor yang lebih rendah dari cluster admin. Jadi, sebelum mengupgrade cluster admin ke versi minor baru, pastikan semua cluster pengguna terkelola memiliki versi minor yang sama dengan cluster admin.
Contoh dalam petunjuk upgrade berikut menunjukkan
proses upgrade dari versi 1.15.2 ke GKE pada Bare Metal
1.16.7.
Aturan pembuatan versi kumpulan node
Saat Anda mengupgrade kumpulan node secara selektif, aturan versi berikut akan berlaku:
Versi cluster harus lebih besar dari atau sama dengan versi kumpulan node pekerja.
Kemiringan maksimum antara versi cluster dan versi kumpulan node pekerja adalah satu versi minor.
Kumpulan node pekerja tidak boleh berada pada versi yang dirilis lebih lambat dari versi cluster.
Misalnya, dengan cluster di versi 1.15.4, yang tidak tersedia saat versi 1.16.0 dirilis, Anda tidak dapat mengupgrade ke versi 1.16.0 dan membiarkan kumpulan node pekerja di versi 1.15.4. Demikian pula, jika Anda telah mengupgrade ke versi 1.16.0, tetapi memilih untuk membiarkan kumpulan node pekerja di versi 1.15.2, Anda tidak dapat mengupgrade kumpulan node pekerja ke versi 1.15.4.
Tabel berikut mencantumkan versi kumpulan node yang didukung yang diizinkan untuk versi cluster tertentu:
| Versi cluster (bidang kontrol) | Versi kumpulan node pekerja yang didukung | |||
|---|---|---|---|---|
| 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 node dan level cluster. Pada tingkat cluster, komponen berikut diupgrade:
- Komponen cluster untuk jaringan, kemampuan observasi, dan penyimpanan.
- Untuk admin, hybrid, dan cluster mandiri, pengontrol siklus proses.
gke-connect-agent.
Node dalam cluster berjalan sebagai salah satu peran berikut, dengan berbagai komponen yang diupgrade, bergantung pada peran node:
| Peran node | Fungsi | Komponen yang akan diupgrade |
|---|---|---|
| Pekerja | Menjalankan workload pengguna | Kubelet, runtime container (Docker atau dalam container) |
| Bidang kontrol | Menjalankan bidang kontrol Kubernetes, pengontrol siklus proses cluster, dan add-on platform edisi Google Kubernetes Engine (GKE) Enterprise | Bidang kontrol Kubernetes Pod statis (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 Keepalive yang menyalurkan traffic ke
kube-apiserver, dan menjalankan speaker MetalLB untuk mengklaim alamat IP
virtual |
Pod statis load balancer bidang kontrol (HAProxy, Keepalive)
Speaker MetalLB |
Ekspektasi periode nonaktif
Tabel berikut menjelaskan periode nonaktif yang diperkirakan dan potensi dampaknya saat Anda mengupgrade cluster. Tabel ini mengasumsikan bahwa Anda memiliki beberapa node cluster dan satu bidang kontrol HA. Jika Anda menjalankan cluster mandiri atau tidak memiliki bidang kontrol HA, periode nonaktif tambahan akan terjadi. Kecuali dinyatakan lain, periode nonaktif ini berlaku untuk upgrade cluster admin dan pengguna:
| Komponen | Ekspektasi periode nonaktif | Kapan 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 habis dan diupgrade. Periode nonaktif harus kurang dari 5 menit.
DaemonSets dapat terus berfungsi tanpa periode nonaktif. |
Setelah node bidang kontrol menyelesaikan upgrade. |
| Antarmuka jaringan container (CNI) | Tidak ada periode nonaktif untuk rute jaringan yang ada. DaemonSet men-deploy dua kali dua tanpa periode nonaktif. Operator habis dan diupgrade. Periode nonaktif kurang dari 5 menit. |
Setelah node bidang kontrol menyelesaikan upgrade. |
| MetalLB (khusus cluster pengguna) | Operator habis dan diupgrade. Periode nonaktif kurang dari 5 menit.
Layanan yang ada tidak mengalami periode nonaktif |
Setelah node bidang kontrol menyelesaikan upgrade. |
| CoreDNS dan DNS Autocomplete (khusus cluster pengguna) | CoreDNS memiliki beberapa replika dengan penskala otomatis. Biasanya tidak periode nonaktif. | Setelah node bidang kontrol menyelesaikan upgrade. |
| Penyedia volume lokal | Tidak ada periode nonaktif untuk volume persisten yang disediakan (PV) yang ada.
Operator mungkin mengalami periode nonaktif selama 5 menit. |
Setelah node bidang kontrol menyelesaikan upgrade. |
| Istio / ingress | Operator Istio dihabiskan dan diupgrade. Periode nonaktif sekitar 5 menit. Traffic masuk terkonfigurasi yang sudah ada akan terus berfungsi. |
Setelah node bidang kontrol menyelesaikan upgrade. |
| Operator sistem lainnya | Periode nonaktif 5 menit saat dihabiskan dan diupgrade. | Setelah node bidang kontrol menyelesaikan upgrade. |
| Workload 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 preflight untuk upgrade cluster pengguna:
Diagram sebelumnya menjelaskan langkah-langkah yang terjadi selama upgrade:
- Perintah
bmctl upgrade clustermembuat resource kustomPreflightCheck. - Pemeriksaan preflight ini menjalankan pemeriksaan tambahan, seperti pemeriksaan upgrade cluster, pemeriksaan kondisi jaringan, dan health check node.
- Hasil pemeriksaan tambahan ini digabungkan untuk melaporkan kemampuan cluster agar berhasil melakukan upgrade ke versi target.
Jika pemeriksaan preflight berhasil dan tidak ada masalah pemblokiran, komponen dalam cluster akan diupgrade dalam urutan tertentu, seperti yang ditunjukkan dalam diagram berikut:
Pada diagram sebelumnya, komponen diupgrade secara berurutan sebagai berikut:
- Upgrade dimulai dengan mengupdate kolom
spec.anthosBareMetalVersion. - Load balancer bidang kontrol telah diupgrade.
- Kumpulan node bidang kontrol diupgrade.
- Secara paralel, GKE connect diupgrade, add-on cluster diupgrade, dan kumpulan node load balancer diupgrade.
- Setelah kumpulan node load balancer berhasil diupgrade, kumpulan node pekerja akan diupgrade.
Jika semua komponen telah diupgrade, health check cluster akan berjalan.
Health check terus berjalan hingga semua pemeriksaan lulus.
Jika semua health check lulus, upgrade akan selesai.
Setiap komponen memiliki kolom statusnya sendiri di dalam resource kustom Cluster. Anda dapat memeriksa status di kolom berikut untuk memahami progres upgrade:
| Urutan | Nama kolom | Arti |
|---|---|---|
| 1 | status.controlPlaneNodepoolStatus |
Status disalin dari status kumpulan node bidang kontrol. Kolom ini berisi versi node kumpulan node bidang kontrol |
| 2 | status.anthosBareMetalLifecycleControllersManifestsVersion
|
Versi lifecycles-controllers-manager 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 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 final versi yang diupgrade. |
Detail upgrade cluster mandiri, admin, dan hybrid
Mulai bmctl versi 1.15.0, perilaku upgrade default untuk
cluster yang dikelola sendiri (admin, campuran, atau mandiri) adalah upgrade yang sudah diterapkan.
Artinya, saat Anda mengupgrade cluster ke versi 1.15.0 atau yang lebih baru, upgrade
akan menggunakan pengontrol siklus proses, bukan cluster bootstrap, untuk mengelola seluruh
proses upgrade. Perubahan ini menyederhanakan proses dan mengurangi persyaratan
resource, yang membuat upgrade cluster lebih andal dan skalabel.
Meskipun menggunakan cluster bootstrap untuk mengupgrade tidak direkomendasikan, opsi tersebut masih tersedia. Untuk menggunakan cluster bootstrap saat melakukan upgrade, jalankan
perintah bmctl upgrade dengan flag --use-bootstrap=true.
Tahapan upgrade dapat berbeda, bergantung pada metode yang Anda
gunakan.
Upgrade yang diterapkan
Proses upgrade default yang diterapkan untuk cluster yang dikelola sendiri mirip dengan
proses upgrade cluster pengguna. Namun, saat Anda menggunakan proses upgrade
yang diterapkan, versi baru preflightcheck-operator akan di-deploy sebelum
pemeriksaan preflight cluster dan health check berjalan:
Seperti upgrade cluster pengguna, proses upgrade dimulai dengan mengupdate
kolom Cluster.spec.anthosBareMetalVersion ke versi target. Dua
langkah tambahan berjalan sebelum komponen diupdate, seperti yang ditunjukkan dalam diagram
berikut: lifecycle-controller-manager mengupgrade sendiri ke versi
target, lalu men-deploy versi target anthos-cluster-operator. anthos-cluster-operator
ini melakukan langkah-langkah proses upgrade yang tersisa:
Setelah berhasil, anthos-cluster-operator merekonsiliasi versi target dari
spec.anthosBareMetalVersion menjadi status.anthosBareMetalVersion.
Mengupgrade dengan cluster bootstrap
Proses untuk mengupgrade admin, cluster hybrid, atau cluster 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 hybrid, admin, atau mandiri selama upgrade.
Proses untuk mentransfer kepemilikan pengelolaan cluster ke cluster bootstrap disebut pivot. Upgrade lainnya mengikuti proses yang sama seperti 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 mengalihkan resource dari cluster bootstrap ke cluster yang telah diupgrade. Tidak ada langkah manual yang Anda lakukan untuk mengalihkan cluster selama proses upgrade. Cluster bootstrap akan dihapus setelah upgrade cluster berhasil.
Pengosongan node
GKE pada upgrade cluster Bare Metal dapat menyebabkan gangguan aplikasi saat node dikosongkan. Proses pengosongan ini menyebabkan semua Pod yang berjalan pada node dimatikan dan dimulai ulang pada node yang tersisa dalam cluster.
Deployment dapat digunakan untuk menoleransi gangguan tersebut. Deployment dapat menentukan beberapa replika dari suatu aplikasi atau layanan yang harus berjalan. Aplikasi dengan beberapa replika akan mengalami sedikit atau tidak ada gangguan sama sekali selama upgrade.
Anggaran gangguan pod (PDB)
Anggaran gangguan pod (PDB) dapat digunakan untuk memastikan bahwa jumlah replika yang ditentukan selalu berjalan di cluster dalam kondisi berjalan normal. PDB memungkinkan Anda
membatasi gangguan pada beban kerja saat Pod-nya perlu dijadwalkan ulang.
Namun, GKE pada Bare Metal tidak mematuhi PDB saat node terkuras selama upgrade.
Sebaliknya, proses pengosongan node adalah upaya terbaik. Beberapa Pod mungkin macet dalam
status Terminating dan menolak untuk mengosongkan node. Upgrade akan dilanjutkan, bahkan
dengan Pod yang macet, jika proses pengosongan node memerlukan waktu lebih dari 20 menit.
Langkah selanjutnya
- Tinjau praktik terbaik untuk GKE pada upgrade Bare Metal
- Mengupgrade cluster
- Memecahkan masalah upgrade cluster