Saat menginstal versi baru bmctl
, Anda dapat mengupgrade cluster yang sudah ada dan dibuat dengan versi sebelumnya. Mengupgrade cluster ke
versi Google Distributed Cloud terbaru akan menghadirkan fitur dan perbaikan tambahan pada
cluster Anda. Hal ini juga memastikan bahwa cluster Anda tetap didukung.
Anda dapat mengupgrade cluster admin, hybrid, mandiri, atau pengguna dengan perintah bmctl upgrade cluster
, atau Anda dapat menggunakan kubectl
.
Untuk mempelajari proses upgrade dan aturan pembuatan versi lebih lanjut, lihat Siklus proses dan tahapan upgrade cluster.
Rencanakan upgrade Anda
Bagian ini berisi informasi dan link ke informasi yang harus Anda pertimbangkan sebelum mengupgrade cluster.
Praktik terbaik
Untuk mendapatkan informasi guna membantu Anda mempersiapkan upgrade cluster, lihat Praktik terbaik untuk upgrade cluster Google Distributed Cloud.
Upgrade pemeriksaan preflight
Pemeriksaan preflight dijalankan sebagai bagian dari upgrade cluster untuk memvalidasi status cluster dan kondisi node. Upgrade cluster tidak akan dilanjutkan jika pemeriksaan preflight gagal. Untuk mengetahui informasi selengkapnya tentang pemeriksaan preflight, lihat Memahami pemeriksaan preflight.
Anda dapat memeriksa apakah cluster siap untuk diupgrade dengan menjalankan pemeriksaan preflight sebelum menjalankan upgrade. Untuk mengetahui informasi selengkapnya, lihat Pemeriksaan preflight untuk upgrade.
Masalah umum
Untuk mengetahui informasi tentang potensi masalah terkait upgrade cluster, lihat Masalah umum Google Distributed Cloud untuk bare metal, lalu pilih kategori masalah Upgrade dan update.
Mengonfigurasi opsi upgrade
Sebelum memulai upgrade cluster, Anda dapat mengonfigurasi opsi upgrade berikut yang mengontrol cara kerja proses upgrade:
Upgrade kumpulan node pekerja selektif: upgrade kumpulan node pekerja tertentu secara terpisah dari cluster lainnya.
Upgrade paralel: konfigurasikan proses upgrade untuk mengupgrade grup node atau kumpulan node secara bersamaan.
Opsi ini dapat mengurangi risiko gangguan pada aplikasi dan layanan penting serta mengurangi keseluruhan waktu upgrade secara signifikan. Opsi ini sangat berguna untuk cluster besar dengan banyak node dan kumpulan node yang menjalankan beban kerja penting. Untuk informasi selengkapnya tentang fungsi opsi ini dan cara menggunakannya, lihat bagian berikut.
Upgrade kumpulan node pekerja selektif
Secara default, operasi upgrade cluster akan mengupgrade setiap node dan kumpulan node di cluster. Upgrade cluster dapat mengganggu dan menghabiskan waktu, karena mengakibatkan setiap node dihabiskan dan semua pod terkait dimulai ulang dan dijadwalkan ulang. Bagian ini menjelaskan cara menyertakan atau mengecualikan kumpulan node pekerja tertentu untuk upgrade cluster guna meminimalkan gangguan workload. Fitur ini hanya berlaku untuk cluster pengguna, hybrid, dan mandiri, karena cluster admin tidak mengizinkan kumpulan node pekerja.
Anda dapat menggunakan upgrade kumpulan node selektif dalam situasi berikut:
Untuk mendapatkan perbaikan keamanan tanpa mengganggu workload: Anda hanya dapat mengupgrade node bidang kontrol (dan node load balancer) untuk menerapkan perbaikan kerentanan Kubernetes tanpa mengganggu kumpulan node pekerja Anda.
Untuk mengonfirmasi pengoperasian yang tepat pada subset worker node yang telah diupgrade sebelum mengupgrade semua worker node: Anda dapat mengupgrade kumpulan node pekerja secara selektif untuk memastikan workload berjalan dengan benar pada kumpulan node yang diupgrade sebelum Anda mengupgrade kumpulan node lainnya.
Untuk mengurangi masa pemeliharaan: Mengupgrade cluster besar dapat menghabiskan waktu dan sulit untuk memprediksi secara akurat kapan upgrade akan selesai. Waktu upgrade cluster sebanding dengan jumlah node yang diupgrade. Mengurangi jumlah node yang diupgrade dengan mengecualikan kumpulan node akan mengurangi waktu upgrade. Anda melakukan upgrade beberapa kali, tetapi masa pemeliharaan yang lebih kecil dan lebih mudah diprediksi dapat membantu penjadwalan.
Dua kemiringan versi kumpulan node minor
Untuk cluster versi 1.28 dan yang lebih tinggi, versi kumpulan node pekerja dapat mencapai dua versi minor di belakang versi cluster (bidang kontrol). Dengan dukungan kemiringan versi n-2, Anda juga dapat melewati versi rilis minor saat mengupgrade kumpulan node pekerja dari dua versi minor di belakang cluster ke versi minor yang sama dengan cluster.
Dukungan kemiringan versi n-2 untuk kumpulan node pekerja ini memberi Anda fleksibilitas yang lebih besar untuk merencanakan upgrade fleet.
Misalnya, jika memiliki cluster versi 1.28, Anda dapat memiliki kumpulan node pekerja pada versi 1.28, 1.16, dan 1.15 tertentu. Untuk mengupgrade cluster ke versi 1.29, Anda harus mengupgrade kumpulan node pekerja 1,15 terlebih dahulu ke versi yang didukung untuk cluster versi 1.28 sebelum upgrade. Anda tidak perlu mengupgrade kumpulan node pekerja versi 1.16 ke versi 1.28 sebelum dapat mengupgrade cluster ke versi 1.29. Setelah cluster diupgrade ke versi 1.29, saat Anda memutuskan untuk mengupgrade kumpulan node worker versi 1.16 ke versi 1.29, Anda dapat melakukan upgrade dalam satu langkah, dengan melewati versi 1.28.
Untuk mengetahui informasi selengkapnya, termasuk daftar versi kumpulan node pekerja yang didukung yang didukung oleh versi cluster tertentu, lihat Aturan pembuatan versi kumpulan node
1,29
Pada rilis 1.29, dukungan kemiringan versi n-2 untuk kumpulan node pekerja adalah GA untuk semua jenis cluster. Fitur ini diaktifkan secara default untuk cluster pada versi 1.29.
Saat kami mentransisikan fitur ini dari Pratinjau Publik ke GA, cluster hybrid masih memerlukan anotasi pratinjau dalam situasi berikut. Jika memiliki
cluster hybrid versi 1.28.x dengan kumpulan node pekerja versi 1.16.y, Anda
harus menambahkan anotasi preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
ke cluster sebelum Anda mengupgradenya ke versi 1.29.z:
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: baremetal-demo
namespace: cluster-baremetal-demo
annotations:
preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
type: hybrid
profile: default
anthosBareMetalVersion: 1.28.400-gke.77
...
1,28
Dukungan kemiringan versi n-2 untuk kumpulan node pekerja tersedia untuk
Pratinjau di rilis 1.28. Untuk mengaktifkan
kemampuan Pratinjau ini, tambahkan
anotasi
preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
ke file konfigurasi cluster Anda:
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: baremetal-demo
namespace: cluster-baremetal-demo
annotations:
preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
...
Jika Anda tidak mengaktifkan kemampuan Pratinjau ini, distorsi versi maksimum antara kumpulan node pekerja dan cluster adalah satu versi minor.
Untuk mengetahui informasi selengkapnya tentang aturan pembuatan versi untuk mengupgrade kumpulan node pekerja secara selektif, lihat Aturan pembuatan versi kumpulan node dalam Siklus proses dan tahapan upgrade cluster.
Upgrade bidang kontrol cluster Anda dan kumpulan node yang dipilih
Untuk mengupgrade kumpulan node pekerja secara selektif pada upgrade cluster awal:
Untuk kumpulan node pekerja yang ingin Anda sertakan dalam upgrade cluster, buat salah satu perubahan berikut pada spesifikasi NodePool:
- Tetapkan
anthosBareMetalVersion
di spesifikasi NodePool ke versi upgrade target cluster. - Hapus kolom
anthosBareMetalVersion
dari spesifikasi NodePool atau setel ke string kosong. Secara default, kumpulan node pekerja disertakan dalam upgrade cluster.
- Tetapkan
Untuk kumpulan node pekerja yang ingin Anda kecualikan dari upgrade, tetapkan
anthosBareMetalVersion
ke versi cluster saat ini (sebelum upgrade):Lanjutkan upgrade seperti yang dijelaskan di bagian Memulai upgrade cluster.
Operasi upgrade cluster akan mengupgrade node berikut:
- Node bidang kontrol cluster.
- Kumpulan node load balancer, jika cluster Anda menggunakan salah satu (
spec.loadBalancer.nodePoolSpec
). Secara default, node load balancer dapat menjalankan workload reguler. Anda tidak dapat mengupgrade kumpulan node load balancer secara selektif. Kumpulan node load balancer selalu disertakan dalam upgrade cluster awal. - Kumpulan node pekerja yang belum Anda kecualikan dari upgrade.
Misalnya, cluster Anda menggunakan versi 1.28.0 dan
memiliki dua kumpulan node pekerja: wpool01
dan wpool02
. Selain itu, anggaplah Anda ingin mengupgrade bidang kontrol dan wpool01
ke 1.29.200-gke.243, tetapi Anda ingin wpool02
tetap menggunakan versi 1.28.0.
Cuplikan file konfigurasi cluster berikut menunjukkan cara mengubah konfigurasi cluster untuk mendukung upgrade parsial ini:
...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user001
namespace: cluster-user001
spec:
type: user
profile: default
anthosBareMetalVersion: 1.29.200-gke.243
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool01
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: 1.29.200-gke.243
nodes:
- address: 10.200.0.1
- address: 10.200.0.2
- address: 10.200.0.3
...
- address: 10.200.0.8
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool02
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: 1.28.0
nodes:
- address: 10.200.1.1
- address: 10.200.1.2
- address: 10.200.1.3
...
- address: 10.200.1.12
Mengupgrade node pool ke versi cluster saat ini
Jika telah mengecualikan kumpulan node dari upgrade cluster, Anda dapat menjalankan upgrade
cluster yang membawanya ke versi cluster target. Kumpulan node pekerja
yang telah dikecualikan dari upgrade cluster memiliki kolom anthosBareMetalVersion
dalam spesifikasi NodePool
yang ditetapkan ke versi cluster sebelumnya (sebelum upgrade).
Untuk meningkatkan kumpulan node pekerja ke versi cluster terbaru:
Edit spesifikasi
NodePool
di file konfigurasi cluster untuk kumpulan node pekerja yang ingin Anda pindahkan ke versi cluster saat ini. TetapkananthosBareMetalVersion
ke versi cluster saat ini (pasca-upgrade).Jika beberapa kumpulan node pekerja dipilih untuk diupgrade, nilai
spec.nodePoolUpgradeStrategy.concurrentNodePools
dalam spesifikasi cluster akan menentukan jumlah kumpulan node yang diupgrade secara paralel, jika ada. Jika Anda tidak ingin mengupgrade kumpulan node pekerja secara serentak, pilih satu kumpulan node dalam satu waktu untuk diupgrade.Lanjutkan upgrade seperti yang dijelaskan di bagian Memulai upgrade cluster.
Operasi upgrade cluster hanya mengupgrade kumpulan node pekerja yang sebelumnya dikecualikan, dan Anda telah menetapkan
anthosBareMetalVersion
ke versi cluster saat ini yang telah diupgrade.
Misalnya, Anda telah mengupgrade cluster ke versi
1.29.200-gke.243, tetapi kumpulan node wpool02
masih berada di cluster lama, yang merupakan cluster pra-upgrade versi 1.28.0. Beban kerja berjalan dengan baik pada node pool yang diupgrade, wpool01
, jadi sekarang Anda juga perlu meningkatkan wpool02
ke versi cluster saat ini. Untuk mengupgrade wpool02
, Anda dapat menghapus kolom anthosBareMetalVersion
atau menetapkan nilainya ke string kosong.
Cuplikan file konfigurasi cluster berikut menunjukkan cara mengubah konfigurasi cluster untuk mendukung upgrade parsial ini:
...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user001
namespace: cluster-user001
spec:
type: user
profile: default
anthosBareMetalVersion: 1.29.200-gke.243
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool01
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: 1.29.200-gke.243
nodes:
- address: 10.200.0.1
- address: 10.200.0.2
- address: 10.200.0.3
...
- address: 10.200.0.8
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool02
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: ""
nodes:
- address: 10.200.1.1
- address: 10.200.1.2
- address: 10.200.1.3
...
- address: 10.200.1.12
Me-roll back upgrade node pool
Ada banyak dependensi, seperti kompatibilitas dengan kubelet atau plugin, yang dapat memengaruhi performa workload Anda. Jika mengalami masalah setelah mengupgrade kumpulan node pekerja, Anda dapat melakukan roll back kumpulan node ke versi sebelumnya.
Kemampuan rollback kumpulan node tersedia untuk
Pratinjau untuk cluster versi 1.29 (cluster
dengan node bidang kontrol pada versi 1.29). Saat fitur ini berada dalam Pratinjau, Anda
harus menambahkan
anotasi
preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable
ke resource Cluster
untuk mengaktifkan fitur tersebut.
Untuk melakukan roll back upgrade kumpulan node, gunakan langkah-langkah berikut:
bmctl
Saat menggunakan bmctl
untuk me-roll back upgrade kumpulan node, Anda perlu mengedit file konfigurasi cluster dan menerapkan perubahan dengan perintah bmctl update
:
Edit spesifikasi
NodePool
dalam file konfigurasi cluster untuk kumpulan node pekerja yang ingin Anda roll back ke versi sebelumnya. TetapkananthosBareMetalVersion
ke versi cluster (pra-upgrade) sebelumnya.... --- apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool metadata: name: wpool01 namespace: cluster-user001 spec: clusterName: user001 anthosBareMetalVersion: 1.28.700-gke.150 nodes: - address: 10.200.0.1 - address: 10.200.0.2 - address: 10.200.0.3 ...
Jika beberapa kumpulan node pekerja dipilih untuk rollback, nilai
spec.nodePoolUpgradeStrategy.concurrentNodePools
di spesifikasi cluster akan menentukan jumlah kumpulan node yang di-roll back secara paralel. Jika Anda tidak ingin me-roll back kumpulan node pekerja secara serentak, pilih satu kumpulan node dalam satu waktu untuk melakukan rollback atau memperbarui setelannodePoolUpgradeStrategy
. Demikian juga, nilaispec.upgradeStrategy.parallelUpgrade.concurrentNodes
dalam spesifikasiNodePool
menentukan jumlah node yang di-roll back secara paralel.Gunakan
bmctl update
untuk menerapkan perubahan spesifikasiNodePool
Anda:bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
Ganti kode berikut:
CLUSTER_NAME
: nama cluster yang ingin Anda perbarui.ADMIN_KUBECONFIG
: jalur file kubeconfig cluster pengelola (admin, hybrid, atau mandiri).
Rollback akan dimulai secara otomatis.
Saat rollback berjalan, Google Distributed Cloud akan melakukan aktivitas berikut untuk setiap node:
- Alihkan node ke mode pemeliharaan.
- Jalankan tugas reset pada node untuk memperbaikinya.
- Jalankan pemeriksaan preflight mesin pada node.
- Jalankan tugas yang dijalankan mesin pada node untuk menginstal ulang pada versi rollback target (pra-upgrade).
- Hapus node dari mode pemeliharaan.
Di akhir rollback yang berhasil, nilai
nodePool.status.anthosBareMetalVersion
di resourceNodePool
akan ditetapkan ke versi rollback target.
kubectl
Anda dapat me-roll back upgrade kumpulan node menggunakan kubectl
untuk mengedit
resource NodePool
secara langsung:
Untuk me-roll back kumpulan node pekerja, buka resource
NodePool
untuk pengeditan:kubectl edit nodepool NODE_POOL_NAME \ --namespace CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG
Ganti kode berikut:
NODE_POOL_NAME
: nama kumpulan node yang Anda roll back.CLUSTER_NAMESPACE
: nama namespace tempat kumpulan node di-deploy. Ini adalah namespace cluster.ADMIN_KUBECONFIG
: jalur file kubeconfig cluster pengelola (admin, hybrid, atau mandiri).
Ubah nilai
spec.anthosBareMetalVersion
ke versi sebelumnya (pra-upgrade).... --- apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool metadata: name: wpool01 namespace: cluster-user001 spec: clusterName: user001 anthosBareMetalVersion: 1.28.700-gke.150 nodes: - address: 10.200.0.1 - address: 10.200.0.2 - address: 10.200.0.3 ...
Simpan dan tutup resource
NodePool
di editor Anda.Rollback akan dimulai secara otomatis.
Saat rollback berjalan, Google Distributed Cloud akan melakukan aktivitas berikut untuk setiap node:
- Alihkan node ke mode pemeliharaan.
- Jalankan tugas reset pada node untuk memperbaikinya.
- Jalankan pemeriksaan preflight mesin pada node.
- Jalankan tugas yang dijalankan mesin pada node untuk menginstal ulang pada versi rollback target (pra-upgrade).
- Hapus node dari mode pemeliharaan.
Di akhir rollback yang berhasil, nilai
nodePool.status.anthosBareMetalVersion
di resourceNodePool
akan ditetapkan ke versi rollback target.
Upgrade paralel
Dalam upgrade cluster default standar, setiap node cluster diupgrade secara berurutan, satu per satu. Bagian ini menunjukkan cara mengonfigurasi kumpulan node cluster dan worker sehingga beberapa node diupgrade secara paralel saat Anda mengupgrade cluster. Upgrade node secara paralel akan mempercepat upgrade cluster secara signifikan, terutama untuk cluster yang memiliki ratusan node.
Ada dua strategi upgrade paralel yang dapat digunakan untuk mempercepat upgrade cluster:
Upgrade node serentak: Anda dapat mengonfigurasi kumpulan node pekerja sehingga beberapa node diupgrade secara paralel. Upgrade node paralel dikonfigurasi dalam spesifikasi NodePool (
spec.upgradeStrategy.parallelUpgrade
) dan hanya node dalam kumpulan node pekerja yang dapat diupgrade secara paralel. Node di bidang kontrol atau kumpulan node load balancer hanya dapat diupgrade satu per satu. Untuk informasi selengkapnya, lihat Strategi upgrade node.Upgrade kumpulan node serentak: Anda dapat mengonfigurasi cluster agar beberapa kumpulan node diupgrade secara paralel. Hanya kumpulan node pekerja yang dapat diupgrade secara paralel. Kumpulan node bidang kontrol dan load balancer hanya dapat diupgrade satu per satu.
Strategi upgrade node
Anda dapat mengonfigurasi kumpulan node pekerja sehingga beberapa node diupgrade secara serentak (concurrentNodes
). Anda juga dapat menetapkan batas minimum untuk jumlah node yang dapat menjalankan beban kerja selama proses upgrade (minimumAvailableNodes
). Konfigurasi ini dibuat dalam spesifikasi NodePool. Untuk mengetahui informasi selengkapnya tentang kolom ini, lihat Referensi kolom konfigurasi cluster.
Strategi upgrade node hanya berlaku untuk kumpulan node pekerja. Anda tidak dapat menentukan strategi upgrade node untuk kumpulan node bidang kontrol atau load balancer. Selama upgrade cluster, node di bidang kontrol dan kumpulan node load balancer diupgrade secara berurutan, satu per satu. Kumpulan node bidang kontrol dan kumpulan node load balancer ditentukan dalam spesifikasi Cluster (controlPlane.nodePoolSpec.nodes
dan
loadBalancer.nodePoolSpec.nodes
).
Saat mengonfigurasi upgrade paralel untuk node, perhatikan batasan berikut:
Nilai
concurrentNodes
tidak boleh melebihi 50 persen dari jumlah node dalam kumpulan node, atau angka tetap 15, mana saja yang lebih kecil. Misalnya, jika kumpulan node memiliki 20 node, Anda tidak dapat menentukan nilai yang lebih besar dari 10. Jika kumpulan node Anda memiliki 100 node, 15 adalah nilai maksimum yang dapat Anda tentukan.Jika Anda menggunakan
concurrentNodes
bersama denganminimumAvailableNodes
, nilai gabungan tidak boleh melebihi jumlah total node dalam kumpulan node. Misalnya, jika kumpulan node Anda memiliki 20 node danminimumAvailableNodes
ditetapkan ke 18,concurrentNodes
tidak boleh melebihi 2. Demikian pula, jikaconcurrentNodes
ditetapkan ke 10,minimumAvailableNodes
tidak boleh melebihi 10.
Contoh berikut menunjukkan kumpulan node pekerja np1
dengan 10 node. Dalam upgrade, node diupgrade 5 dalam satu waktu dan minimal 4 node harus tetap tersedia agar upgrade dapat dilanjutkan:
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: np1
namespace: cluster-cluster1
spec:
clusterName: cluster1
nodes:
- address: 10.200.0.1
- address: 10.200.0.2
- address: 10.200.0.3
- address: 10.200.0.4
- address: 10.200.0.5
- address: 10.200.0.6
- address: 10.200.0.7
- address: 10.200.0.8
- address: 10.200.0.9
- address: 10.200.0.10
upgradeStrategy:
parallelUpgrade:
concurrentNodes: 5
minimumAvailableNodes: 4
Strategi upgrade kumpulan node
Anda dapat mengonfigurasi cluster sehingga beberapa kumpulan node pekerja diupgrade secara paralel. Kolom Boolean nodePoolUpgradeStrategy.concurrentNodePools
dalam
spesifikasi cluster menentukan apakah akan mengupgrade semua kumpulan node pekerja untuk suatu
cluster atau tidak secara serentak. Secara default (1
), kumpulan node diupgrade secara berurutan, satu per satu. Jika Anda menetapkan concurrentNodePools
ke 0
, setiap kumpulan node pekerja di cluster akan diupgrade secara paralel.
Bidang kontrol dan kumpulan node load balancing tidak terpengaruh oleh setelan ini.
Kumpulan node ini selalu diupgrade secara berurutan, satu per satu. Kumpulan node bidang kontrol dan kumpulan node load balancer ditentukan dalam spesifikasi Cluster (controlPlane.nodePoolSpec.nodes
dan loadBalancer.nodePoolSpec.nodes
).
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: cluster1
namespace: cluster-cluster1
spec:
...
nodePoolUpgradeStrategy:
concurrentNodePools: 0
...
Cara melakukan upgrade paralel
Bagian ini menjelaskan cara mengonfigurasi cluster dan kumpulan node pekerja untuk upgrade paralel.
Untuk melakukan upgrade paralel kumpulan node pekerja dan node dalam kumpulan node pekerja, lakukan langkah berikut:
Tambahkan bagian
upgradeStrategy
ke spesifikasi NodePool.Anda dapat menerapkan manifes ini secara terpisah atau sebagai bagian dari file konfigurasi cluster saat melakukan update cluster.
Berikut contohnya:
--- apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool metadata: name: np1 namespace: cluster-ci-bf8b9aa43c16c47 spec: clusterName: ci-bf8b9aa43c16c47 nodes: - address: 10.200.0.1 - address: 10.200.0.2 - address: 10.200.0.3 ... - address: 10.200.0.30 upgradeStrategy: parallelUpgrade: concurrentNodes: 5 minimumAvailableNodes: 10
Dalam contoh ini, nilai kolom
concurrentNodes
adalah5
, yang berarti 5 node diupgrade secara paralel. KolomminimumAvailableNodes
ditetapkan ke10
, yang berarti minimal 10 node harus tetap tersedia untuk beban kerja selama upgrade.Tambahkan bagian
nodePoolUpgradeStrategy
ke spesifikasi Cluster dalam file konfigurasi cluster.--- apiVersion: v1 kind: Namespace metadata: name: cluster-user001 --- apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: user001 namespace: cluster-user001 spec: type: user profile: default anthosBareMetalVersion: 1.29.200-gke.243 ... nodePoolUpgradeStrategy: concurrentNodePools: 0 ...
Dalam contoh ini, kolom
concurrentNodePools
disetel ke0
, yang berarti semua kumpulan node pekerja diupgrade secara serentak selama upgrade cluster. Strategi upgrade untuk node dalam kumpulan node ditentukan dalam spesifikasi NodePool.Upgrade cluster seperti yang dijelaskan di bagian Upgrade cluster admin, mandiri, campuran, atau pengguna sebelumnya.
Nilai default upgrade paralel
Upgrade paralel dinonaktifkan secara default dan kolom yang terkait dengan upgrade paralel dapat diubah. Anda dapat menghapus kolom atau menetapkannya kapan saja ke nilai defaultnya untuk menonaktifkan fitur tersebut sebelum upgrade berikutnya.
Tabel berikut mencantumkan kolom upgrade paralel dan nilai defaultnya:
Kolom | Nilai default | Arti |
---|---|---|
nodePoolUpgradeStrategy.concurrentNodePools (Spesifikasi cluster) |
1 |
Mengupgrade kumpulan node pekerja secara berurutan, satu per satu. |
upgradeStrategy.parallelUpgrade.concurrentNodes (spesifikasi NodePool) |
1 |
Mengupgrade node secara berurutan, satu per satu. |
upgradeStrategy.parallelUpgrade.minimumAvailableNodes (spesifikasi NodePool) |
Nilai minimumAvailableNodes default bergantung pada nilai concurrentNodes .
|
Upgrade akan terhenti setelah minimumAvailableNodes tercapai dan hanya berlanjut setelah jumlah node yang tersedia lebih dari minimumAvailableNodes . |
Memulai upgrade cluster
Bagian ini berisi petunjuk untuk mengupgrade cluster.
bmctl
Saat mendownload dan menginstal bmctl
versi baru, Anda dapat mengupgrade
cluster admin, hybrid, mandiri, dan pengguna yang dibuat dengan versi sebelumnya.
Untuk versi bmctl
tertentu, cluster hanya dapat diupgrade ke versi
yang sama.
Download
bmctl
terbaru seperti yang dijelaskan dalam download Google Distributed Cloud.Update
anthosBareMetalVersion
di file konfigurasi cluster ke versi target upgrade.Versi target upgrade harus cocok dengan versi file
bmctl
yang didownload. Cuplikan file konfigurasi cluster berikut menunjukkan kolomanthosBareMetalVersion
yang diupdate ke versi terbaru:--- apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: cluster1 namespace: cluster-cluster1 spec: type: admin # Anthos cluster version. anthosBareMetalVersion: 1.29.200-gke.243
Gunakan perintah
bmctl upgrade cluster
untuk menyelesaikan upgrade:bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
Ganti kode berikut:
CLUSTER_NAME
: nama cluster yang akan diupgrade.ADMIN_KUBECONFIG
: jalur ke file kubeconfig cluster admin.
Operasi upgrade cluster menjalankan pemeriksaan preflight untuk memvalidasi status cluster dan kondisi node. Upgrade cluster tidak akan dilanjutkan jika pemeriksaan preflight gagal. Untuk mengetahui informasi pemecahan masalah, lihat Memecahkan masalah penginstalan atau upgrade cluster.
Setelah semua komponen cluster berhasil diupgrade, operasi upgrade cluster akan melakukan health check cluster. Langkah terakhir ini memastikan bahwa cluster berada dalam kondisi pengoperasian yang baik. Jika tidak lulus semua health check, cluster akan terus berjalan hingga lulus. Jika semua health check lulus, upgrade berhasil diselesaikan.
Untuk mengetahui informasi selengkapnya tentang urutan peristiwa upgrade cluster, lihat Siklus proses dan tahapan upgrade cluster.
kubectl
Untuk mengupgrade cluster dengan kubectl
, lakukan langkah-langkah berikut:
Edit file konfigurasi cluster untuk menetapkan
anthosBareMetalVersion
ke versi target upgrade.Untuk memulai upgrade, jalankan perintah berikut:
kubectl apply -f CLUSTER_CONFIG_PATH
Ganti
CLUSTER_CONFIG_PATH
dengan jalur file konfigurasi cluster yang diedit.Seperti halnya proses upgrade dengan
bmctl
, pemeriksaan preflight dijalankan sebagai bagian dari upgrade cluster untuk memvalidasi status cluster dan kondisi node. Jika pemeriksaan preflight gagal, upgrade cluster akan dihentikan. Untuk memecahkan masalah kegagalan, periksa cluster dan log terkait, karena tidak ada cluster bootstrap yang dibuat. Untuk mengetahui informasi selengkapnya, lihat Memecahkan masalah penginstalan atau upgrade cluster.
Meskipun Anda tidak memerlukan versi terbaru bmctl
untuk mengupgrade pemroses dengan
kubectl
, sebaiknya Anda
mendownload bmctl
terbaru. Anda perlu bmctl
untuk
melakukan tugas lain, seperti health check dan pencadangan, untuk memastikan cluster
Anda tetap dalam urutan yang baik.
Jeda dan lanjutkan upgrade
Dengan fitur jeda dan lanjutkan upgrade, Anda dapat menjeda upgrade cluster sebelum selesai. Jika upgrade cluster dijeda, tidak ada upgrade node pekerja baru yang akan dipicu hingga upgrade dilanjutkan.
Fitur ini tersedia di (Pratinjau) untuk cluster dengan semua node bidang kontrol pada minor versi 1.28 atau yang lebih tinggi. Fitur ini GA untuk cluster dengan semua node bidang kontrol pada versi minor 1.29 atau yang lebih tinggi.
Sebaiknya jeda upgrade karena alasan berikut:
Anda mendeteksi masalah beban kerja cluster selama upgrade dan ingin menjeda upgrade untuk memeriksa masalahnya
Anda memiliki masa pemeliharaan yang singkat, jadi jeda upgrade di antara periode
Selama upgrade cluster dijeda, operasi berikut ini akan didukung:
- Menambahkan atau menghapus node
- Menambahkan atau menghapus kumpulan node
- Meningkatkan rentang jaringan layanan
- Memulihkan cluster dari cadangan
Jika node baru ditambahkan saat upgrade dijeda, tugas pemeriksaan mesin tidak akan dijalankan pada node tersebut hingga upgrade dilanjutkan dan diselesaikan.
Selama upgrade cluster dijeda, operasi cluster berikut tidak didukung:
Anda tidak dapat memulai upgrade cluster baru saat upgrade cluster yang aktif dijeda.
Aktifkan jeda dan lanjutkan upgrade
Google Distributed Cloud 1.29
Fitur jeda dan lanjutkan upgrade diaktifkan secara default untuk cluster dengan semua node bidang kontrol pada minor versi 1.29 atau yang lebih tinggi.
Google Distributed Cloud 1.28
Saat kemampuan menjeda dan melanjutkan upgrade berada dalam Pratinjau, Anda dapat mengaktifkannya dengan anotasi di resource Cluster.
Untuk mengaktifkan jeda dan lanjutkan upgrade, gunakan langkah-langkah berikut:
Tambahkan anotasi
preview.baremetal.cluster.gke.io/upgrade-pause-and-resume
ke file konfigurasi cluster Anda:apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: baremetal-demo namespace: cluster-baremetal-demo annotations: preview.baremetal.cluster.gke.io/upgrade-pause-and-resume spec: ...
Untuk menerapkan perubahan, update cluster Anda:
bmctl update CLUSTER_NAME
Kolom
nodePoolUpgradeStrategy.pause
dapat berubah. Anda dapat menambahkan dan memperbaruinya kapan saja.
Menjeda upgrade
Anda menjeda upgrade cluster dengan menetapkan nodePoolUpgradeStrategy.pause
ke true
di spesifikasi Cluster.
Untuk menjeda upgrade cluster yang aktif, gunakan langkah-langkah berikut:
Tambahkan
nodePoolUpgradeStrategy.pause
ke file konfigurasi cluster dan tetapkan ketrue
:apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: baremetal-demo namespace: cluster-baremetal-demo ... spec: ... nodePoolUpgradeStrategy: pause: true ...
Jika menggunakan
bmctl
untuk memulai upgrade, Anda memerlukan jendela terminal baru untuk melakukan langkah berikutnya.Untuk menerapkan perubahan, update cluster Anda:
bmctl update CLUSTER_NAME
Operasi upgrade dijeda. Tidak ada upgrade node baru yang dipicu.
Jika Anda menggunakan
bmctl
untuk memulai upgrade dan Anda berencana melakukan jeda yang lama, tekan Control+C untuk keluar daribmctl
. Jika tidak, terusbmctl
berjalan.CLI
bmctl
tidak mendeteksi perubahan dalam status jeda upgrade, sehingga tidak otomatis keluar. Namun, saat Anda keluar daribmctl
, tindakan ini akan berhenti mencatat progres upgrade ke file logcluster-upgrade-TIMESTAMP
di folder cluster pada workstation admin Anda dan ke Cloud Logging. Oleh karena itu, untuk jeda singkat, sebaiknyabmctl
terus berjalan. Jika Anda membiarkanbmctl
berjalan dalam waktu lama saat upgrade dijeda, akhirnya waktu upgrade akan habis.
Melanjutkan upgrade yang dijeda
Anda dapat melanjutkan upgrade cluster yang dijeda dengan menetapkan
nodePoolUpgradeStrategy.pause
ke false
di spesifikasi Cluster atau menghapus
nodePoolUpgradeStrategy.pause
dari spesifikasi.
Untuk melanjutkan upgrade cluster yang dijeda, gunakan langkah-langkah berikut:
Tetapkan
nodePoolUpgradeStrategy.pause
ke file konfigurasi cluster dan tetapkan kefalse
:apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: baremetal-demo namespace: cluster-baremetal-demo ... spec: ... nodePoolUpgradeStrategy: pause: false ...
Atau, Anda dapat menghapus kolom
pause
karena defaultnya adalahfalse
.Untuk menerapkan perubahan, update cluster Anda:
bmctl update CLUSTER_NAME
Operasi upgrade akan dilanjutkan dari bagian terakhirnya.
Untuk memeriksa status upgrade, pertama-tama dapatkan daftar resource yang memiliki
anthosBareMetalVersion
dalamstatus
-nya:kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces
Ganti kode berikut:
RESOURCE
: nama resource yang ingin Anda dapatkan. ResourceCluster
,NodePool
, danBareMetalMachine
semuanya berisi informasi statusanthosBareMetalVersion
.ADMIN_KUBECONFIG
: jalur file kubeconfig cluster admin.
Contoh berikut menunjukkan format respons untuk resource kustom
BareMetalMachine
. SetiapBareMetalMachine
sesuai dengan satu node cluster.NAMESPACE NAME CLUSTER READY INSTANCEID MACHINE ABM VERSION DESIRED ABM VERSION cluster-nuc-admin001 192.0.2.52 nuc-admin001 true baremetal://192.0.2.52 192.0.2.52 1.28.0 1.28.0 cluster-nuc-user001 192.0.2.53 nuc-user001 true baremetal://192.0.2.53 192.0.2.53 1.16.2 1.16.2 cluster-nuc-user001 192.0.2.54 nuc-user001 true baremetal://192.0.2.54 192.0.2.54 1.16.2 1.16.2
Untuk memeriksa
status.anthosBareMetalVersion
(resource versi saat ini), ambil detail untuk setiap resource:kubectl describe RESOURCE RESOURCE_NAME \ --kubeconfig ADMIN_KUBECONFIG \ --namespace CLUSTER_NAMESPACE
Contoh berikut menunjukkan detail
BareMetalMachine
untuk node cluster dengan alamat IP192.0.2.53
:Name: 192.0.2.53 Namespace: cluster-nuc-user001 ... API Version: infrastructure.baremetal.cluster.gke.io/v1 Kind: BareMetalMachine Metadata: Creation Timestamp: 2023-09-22T17:52:09Z ... Spec: Address: 192.0.2.53 Anthos Bare Metal Version: 1.16.2 ... Status: Anthos Bare Metal Version: 1.16.2
Dalam contoh ini, node berada di Google Distributed Cloud versi 1.16.2.