Jika menginstal bmctl
versi baru, Anda dapat mengupgrade aplikasi yang sudah ada
cluster yang dibuat dengan versi sebelumnya. Mengupgrade cluster ke
Google Distributed Cloud versi terbaru menghadirkan fitur dan perbaikan tambahan
. Hal ini juga memastikan bahwa cluster Anda tetap
didukung.
Anda dapat mengupgrade cluster admin, hybrid, mandiri, atau pengguna dengan
bmctl upgrade cluster
, atau Anda dapat menggunakan kubectl
.
Untuk mempelajari lebih lanjut proses upgrade dan aturan pembuatan versi, lihat Siklus proses dan tahapan upgrade cluster.
Rencanakan upgrade Anda
Bagian ini berisi informasi dan tautan 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 cluster dan kondisi node. Upgrade cluster tidak akan dilanjutkan jika preflight gagalnya pemeriksaan. Untuk mengetahui informasi selengkapnya tentang pemeriksaan preflight, lihat Memahami pemeriksaan preflight.
Anda dapat memeriksa apakah cluster siap untuk diupgrade dengan menjalankan preflight diperiksa sebelum menjalankan peningkatan versi. Untuk informasi selengkapnya, lihat Pemeriksaan preflight untuk upgrade.
Masalah umum
Untuk informasi tentang potensi masalah terkait upgrade cluster, lihat Google Distributed Cloud untuk masalah umum bare metal dan pilih kategori masalah Upgrade dan update.
Mengonfigurasi opsi upgrade
Sebelum memulai upgrade cluster, Anda dapat mengonfigurasi upgrade berikut opsi yang mengontrol cara kerja proses upgrade:
Upgrade kumpulan node pekerja selektif: upgrade spesifik kumpulan node pekerja secara terpisah dari cluster lainnya.
Upgrade paralel: mengonfigurasi proses upgrade ke mengupgrade grup node atau kumpulan node secara bersamaan.
Opsi ini dapat mengurangi risiko gangguan pada aplikasi penting dan dan mengurangi waktu upgrade secara signifikan. Opsi ini sangat berguna untuk cluster besar dengan banyak node dan kumpulan node yang berjalan yang sangat penting. Untuk informasi selengkapnya tentang fungsi opsi ini dan cara kerjanya cara menggunakannya, lihat bagian berikut.
Upgrade kumpulan node pekerja selektif
Secara default, operasi upgrade cluster akan mengupgrade setiap node dan node pool di gugus ini. Upgrade cluster dapat mengganggu dan menghabiskan waktu, karena mengakibatkan setiap node dikosongkan 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 beban kerja. Fitur ini hanya berlaku untuk cluster pengguna, hybrid, dan mandiri, karena admin tidak mengizinkan kumpulan node pekerja.
Anda dapat menggunakan upgrade kumpulan node selektif dalam situasi berikut:
Untuk mengambil perbaikan keamanan tanpa mengganggu workload: Anda dapat mengupgrade hanya node bidang kontrol (dan node load balancer) untuk menerapkan Kubernetes perbaikan kerentanan tanpa mengganggu kumpulan node pekerja Anda.
Untuk mengonfirmasi operasi yang tepat dari subset worker node yang diupgrade sebelum mengupgrade semua worker node: Anda dapat mengupgrade kumpulan node pekerja secara selektif untuk memastikan workload berjalan dengan baik pada upgrade node pool sebelum Anda mengupgrade kumpulan node lainnya.
Untuk mengurangi masa pemeliharaan: Mengupgrade cluster besar memerlukan waktu yang cukup lama 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 node akan mengurangi waktu upgrade. Anda melakukan {i>upgrade <i}berkali-kali, tetapi semakin kecil, masa pemeliharaan yang lebih terprediksi 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 n-2 dukungan yang tidak didukung oleh versi tertentu, 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 untuk merencanakan upgrade fleet Anda.
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 harus mengupgrade versi 1.16 kumpulan node worker ke versi 1.28 sebelum Anda dapat mengupgrade cluster ke versi 1.29. Setelah cluster diupgrade ke versi 1.29, Anda memutuskan untuk mengupgrade kumpulan node pekerja versi 1.16 ke versi 1.29, Anda dapat upgrade dalam satu langkah, melewati versi 1.28.
Untuk informasi selengkapnya, termasuk daftar versi kumpulan node pekerja yang didukung 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 di versi 1.29.
Seiring kami mentransisikan fitur ini dari Pratinjau Publik ke GA, cluster hybrid
masih memerlukan anotasi pratinjau dalam situasi berikut. Jika Anda memiliki
cluster hibrida versi 1.28.x dengan kumpulan node pekerja versi 1.16.y, Anda
harus menambahkan 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
Preview di rilis 1.28. Untuk mengaktifkannya
Kemampuan Pratinjau, tambahkan
preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
anotasi 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 merupakan salah satu versi minor.
Untuk informasi selengkapnya tentang aturan pembuatan versi untuk mengupgrade worker secara selektif kumpulan node, lihat Pembuatan versi kumpulan node aturan dalam Lifecycle dan 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 cluster upgrade, buat salah satu perubahan berikut pada spesifikasi NodePool:
- Menetapkan
anthosBareMetalVersion
di spesifikasi NodePool ke target cluster upgrade ke versi upgrade. - Hapus kolom
anthosBareMetalVersion
dari spesifikasi NodePool. atau setel menjadi {i>string<i} kosong. Secara default, kumpulan node pekerja disertakan dalam upgrade cluster.
- Menetapkan
Untuk kumpulan node pekerja yang ingin Anda kecualikan dari upgrade, tetapkan
anthosBareMetalVersion
ke versi (pra-upgrade) saat ini :Lanjutkan upgrade seperti yang dijelaskan di Mulai upgrade cluster.
Operasi upgrade cluster akan mengupgrade node berikut:
- Node bidang kontrol cluster.
- Kumpulan node load balancer, jika cluster Anda menggunakannya
(
spec.loadBalancer.nodePoolSpec
). Secara default, node load balancer dapat dan menjalankan workload reguler. Anda tidak dapat mengupgrade node load balancer secara selektif paket data, cluster tersebut akan selalu disertakan dalam upgrade cluster awal. - Kumpulan node pekerja yang belum Anda kecualikan dari upgrade.
Misalnya, cluster Anda berada di versi 1.28.0 dan
memiliki dua kumpulan node pekerja: wpool01
dan wpool02
. Juga, anggaplah Anda ingin
untuk mengupgrade bidang kontrol dan wpool01
ke 1.29.400-gke.86, tetapi Anda ingin
wpool02
agar tetap berada di versi 1.28.0.
Cuplikan file konfigurasi cluster berikut menunjukkan cara memodifikasi konfigurasi cluster Anda 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.400-gke.86
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool01
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: 1.29.400-gke.86
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 Anda telah mengecualikan kumpulan node dari upgrade cluster, Anda dapat menjalankan cluster
upgrade yang membawanya ke versi cluster target. Kumpulan node pekerja
yang telah dikecualikan dari upgrade cluster memiliki anthosBareMetalVersion
di spesifikasi NodePool
yang ditetapkan ke versi cluster sebelumnya (pra-upgrade).
Untuk meningkatkan kumpulan node pekerja ke versi cluster terbaru:
Mengedit spesifikasi
NodePool
di file konfigurasi cluster untuk worker kumpulan node yang ingin Anda pindahkan ke versi cluster saat ini. SetelanthosBareMetalVersion
ke versi cluster saat ini (pasca-upgrade).Jika beberapa kumpulan node pekerja dipilih untuk diupgrade, nilai dari
spec.nodePoolUpgradeStrategy.concurrentNodePools
di spesifikasi cluster menentukan jumlah kumpulan node yang diupgrade secara paralel, jika ini. Jika Anda tidak ingin mengupgrade kumpulan node pekerja secara serentak, pilih salah satu kumpulan node sekaligus untuk upgrade.Lanjutkan upgrade seperti yang dijelaskan di Mulai upgrade cluster.
Operasi upgrade cluster hanya mengupgrade worker yang sebelumnya dikecualikan kumpulan node yang telah Anda tetapkan
anthosBareMetalVersion
-nya ke nilai saat ini, versi cluster yang telah diupgrade.
Misalnya, Anda telah mengupgrade cluster ke versi
1.29.400-gke.86, tetapi kumpulan node wpool02
masih berada di versi lama, sebelum diupgrade
cluster versi 1.28.0. Beban kerja berjalan
dengan baik pada
kumpulan node diupgrade, wpool01
, jadi sekarang Anda ingin memindahkan wpool02
ke
versi cluster saat ini juga. Untuk mengupgrade wpool02
, Anda dapat menghapus
anthosBareMetalVersion
atau tetapkan nilainya ke string kosong.
Cuplikan file konfigurasi cluster berikut menunjukkan cara memodifikasi konfigurasi cluster Anda 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.400-gke.86
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool01
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: 1.29.400-gke.86
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 Anda menemukan setelah mengupgrade kumpulan node pekerja, Anda dapat me-roll back kumpulan node ke dari 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 dalam Pratinjau, Anda
harus menambahkan
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 Anda menggunakan bmctl
untuk melakukan roll back upgrade kumpulan node, Anda mengedit cluster
file konfigurasi Anda dan terapkan perubahan dengan perintah bmctl update
:
Edit spesifikasi
NodePool
dalam file konfigurasi cluster untuk kumpulan node pekerja yang ingin Anda roll back ke versi sebelumnya. MenetapkananthosBareMetalVersion
ke cluster (pra-upgrade) sebelumnya .... --- apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool metadata: name: wpool01 namespace: cluster-user001 spec: clusterName: user001 anthosBareMetalVersion: 1.28.800-gke.111 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
inci spesifikasi cluster menentukan jumlah kumpulan node yang di-roll back paralel. Jika Anda tidak ingin me-roll back kumpulan node pekerja secara serentak, memilih satu kumpulan node dalam satu waktu untuk SetelannodePoolUpgradeStrategy
. Demikian juga, nilai darispec.upgradeStrategy.parallelUpgrade.concurrentNodes
dalamNodePool
spesifikasi 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 Anda inginkan untuk memperbarui.ADMIN_KUBECONFIG
: jalur kubeconfig file cluster pengelola (admin, hybrid, atau mandiri).
Rollback akan dimulai secara otomatis.
Saat rollback berjalan, Google Distributed Cloud akan melakukan hal berikut aktivitas untuk setiap {i>node<i}:
- Alihkan node ke mode pemeliharaan.
- Jalankan tugas reset pada node untuk memperbaikinya.
- Jalankan preflight mesin pemeriksaan di {i>node<i}.
- Menjalankan tugas machine-init pada node untuk menginstal ulang pada target versi rollback (pra-upgrade).
- Hapus node dari mode pemeliharaan.
Di akhir rollback yang berhasil, nilai
nodePool.status.anthosBareMetalVersion
dalam resourceNodePool
disetel ke versi rollback target.
kubectl
Anda dapat melakukan roll back upgrade kumpulan node menggunakan kubectl
untuk mengedit
NodePool
resource secara langsung:
Untuk melakukan 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 Anda melakukan roll back.CLUSTER_NAMESPACE
: nama namespace di tempat node pool di-deploy. Ini adalah namespace cluster.ADMIN_KUBECONFIG
: jalur kubeconfig file cluster pengelola (admin, hybrid, atau mandiri).
Ubah nilai
spec.anthosBareMetalVersion
ke nilai sebelumnya (pra-upgrade).... --- apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool metadata: name: wpool01 namespace: cluster-user001 spec: clusterName: user001 anthosBareMetalVersion: 1.28.800-gke.111 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 hal berikut aktivitas untuk setiap {i>node<i}:
- Alihkan node ke mode pemeliharaan.
- Jalankan tugas reset pada node untuk memperbaikinya.
- Jalankan preflight mesin pemeriksaan di {i>node<i}.
- Menjalankan tugas machine-init pada node untuk menginstal ulang pada target versi rollback (pra-upgrade).
- Hapus node dari mode pemeliharaan.
Di akhir rollback yang berhasil, nilai
nodePool.status.anthosBareMetalVersion
dalam resourceNodePool
disetel ke versi rollback target.
Upgrade paralel
Pada 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 Anda. Mengupgrade node secara paralel akan mempercepat upgrade cluster secara signifikan, terutama untuk cluster yang memiliki ratusan node.
Ada dua strategi upgrade paralel yang dapat Anda gunakan untuk mempercepat upgrade cluster:
Upgrade node serentak: Anda dapat mengonfigurasi kumpulan node pekerja sehingga beberapa node di-upgrade secara paralel. Upgrade node paralel adalah yang dikonfigurasi dalam spesifikasi NodePool (
spec.upgradeStrategy.parallelUpgrade
) dan hanya node dalam kumpulan node pekerja yang dapat diupgrade secara paralel. Node di kumpulan node bidang kontrol atau load balancer hanya dapat diupgrade satu per satu baik. 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 workload selama proses upgrade
(minimumAvailableNodes
). Konfigurasi ini dibuat dalam spesifikasi NodePool. Sebagai
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 cluster
upgrade, node di bidang kontrol, dan kumpulan node load balancer
secara berurutan, satu per satu. Mengontrol kumpulan node bidang dan node load balancer
kumpulan 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 jumlah di kumpulan node, atau angka tetap 15, mana saja yang lebih kecil. Misalnya, jika kumpulan node memiliki 20 node, Anda tidak dapat menentukan nilai 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. Sebagai misalnya, jika kumpulan node Anda memiliki 20 node danminimumAvailableNodes
ditetapkan ke 18,concurrentNodes
tidak boleh lebih dari 2. Demikian pula, jikaconcurrentNodes
ditetapkan ke 10,minimumAvailableNodes
tidak boleh melebihi 10.
Contoh berikut menunjukkan kumpulan node pekerja np1
dengan 10 node. Di
meng-upgrade, node meng-upgrade 5 pada satu waktu dan setidaknya 4 node harus tetap
tersedia untuk proses upgrade agar 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 bisa mengonfigurasi cluster agar beberapa kumpulan node pekerja diupgrade dalam
paralel. Kolom Boolean nodePoolUpgradeStrategy.concurrentNodePools
di
spesifikasi cluster menentukan apakah akan mengupgrade semua kumpulan node pekerja atau tidak
cluster 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 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. 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 node pekerja gabungan, lakukan hal berikut:
Tambahkan bagian
upgradeStrategy
ke spesifikasi NodePool.Anda dapat menerapkan manifes ini secara terpisah atau sebagai bagian dari cluster pada file konfigurasi terakhir saat Anda 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
disetel ke10
, artinya minimal 10 node harus tersedia untuk workload selama proses upgrade.Tambahkan bagian
nodePoolUpgradeStrategy
ke spesifikasi Cluster di file konfigurasi cluster Anda.--- 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.400-gke.86 ... nodePoolUpgradeStrategy: concurrentNodePools: 0 ...
Dalam contoh ini, kolom
concurrentNodePools
ditetapkan 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 sebagaimana dijelaskan dalam penjelasan sebelumnya Mengupgrade cluster admin, mandiri, hybrid, atau pengguna bagian.
Nilai default upgrade paralel
Upgrade paralel dinonaktifkan secara default dan kolom yang terkait dengan paralel upgrade dapat berubah. Anda dapat menghapus kolom atau menyetelnya kapan saja ke nilai defaultnya untuk menonaktifkan fitur 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
Jika mendownload dan menginstal versi baru bmctl
, Anda dapat mengupgrade
admin, hybrid, mandiri, dan pengguna yang
dibuat dengan versi sebelumnya.
Untuk versi bmctl
tertentu, cluster dapat diupgrade ke versi yang sama
saja.
Tetapkan kredensial pengguna Anda sebagai Application Default Credentials (ADC):
gcloud auth application-default login
Ikuti petunjuk guna memilih Akun Google Anda untuk ADC. Untuk selengkapnya informasi, lihat Menyiapkan Default Aplikasi Kredensial.
Download
bmctl
terbaru seperti yang dijelaskan di Download Google Distributed Cloud.Update
anthosBareMetalVersion
di file konfigurasi cluster ke upgrade versi target.Versi target upgrade harus cocok dengan versi yang didownload File
bmctl
. Cuplikan file konfigurasi cluster berikut menunjukkan KolomanthosBareMetalVersion
diperbarui 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.400-gke.86
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 cluster admin {i>kubeconfig<i}.
Operasi upgrade cluster menjalankan pemeriksaan preflight untuk memvalidasi cluster dan kondisi node. Upgrade cluster tidak akan dilanjutkan jika pemeriksaan preflight gagal. Untuk informasi pemecahan masalah, lihat Memecahkan masalah penginstalan atau upgrade cluster.
Ketika semua komponen cluster berhasil diupgrade, model operasi upgrade cluster akan melakukan health check cluster. Langkah terakhir ini memastikan bahwa cluster berada dalam kondisi pengoperasian yang baik. Jika cluster tidak lulus semua health check, mereka akan terus berjalan hingga lulus. Kapan 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 upgrade versi target.Untuk memulai upgrade, jalankan perintah berikut:
kubectl apply -f CLUSTER_CONFIG_PATH
Ganti
CLUSTER_CONFIG_PATH
dengan jalur file konfigurasi cluster yang diedit.Seperti proses upgrade dengan
bmctl
, pemeriksaan preflight dijalankan sebagai bagian dari upgrade cluster untuk memvalidasi status cluster dan kondisi node. Jika preflight pemeriksaan gagal, upgrade cluster dihentikan. Untuk memecahkan masalah kegagalan, memeriksa cluster dan log terkait, karena tidak ada cluster bootstrap yang dibuat. Sebagai informasi selengkapnya, lihat Memecahkan masalah penginstalan atau upgrade cluster.
Meskipun Anda tidak memerlukan versi terbaru bmctl
untuk mengupgrade pemroses dengan
kubectl
, sebaiknya Anda
download bmctl
terbaru. Anda perlu bmctl
untuk
melakukan tugas lain, seperti health check dan pencadangan, untuk memastikan
cluster tetap dalam kondisi baik.
Jeda dan lanjutkan upgrade
Dengan fitur jeda dan lanjutkan upgrade, Anda dapat menjeda upgrade cluster sebelum hingga akhir. Jika upgrade cluster dijeda, tidak ada upgrade node pekerja baru yang akan dipicu hingga upgrade dilanjutkan.
Fitur ini tersedia di (Pratinjau) untuk dengan semua node bidang kontrol pada versi minor 1.28 atau yang lebih tinggi. Tujuan GA untuk cluster dengan semua node bidang kontrol pada versi minor 1.29 atau lebih tinggi.
Sebaiknya jeda upgrade karena alasan berikut:
Anda mendeteksi masalah pada beban kerja cluster selama upgrade dan Anda ingin menjeda upgrade untuk melihat masalahnya.
Anda memiliki masa pemeliharaan yang singkat, jadi Anda ingin menjeda peningkatan versi antar jendela
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
Saat node baru ditambahkan saat upgrade dijeda, tugas pemeriksaan mesin tidak tetap dijalankan hingga peningkatan dilanjutkan dan selesai.
Selama upgrade cluster dijeda, operasi cluster berikut tidak didukung:
Anda tidak dapat memulai upgrade cluster baru saat upgrade cluster aktif sedang 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 versi minor 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:
Menambahkan
preview.baremetal.cluster.gke.io/upgrade-pause-and-resume
anotasi 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
Tujuan
nodePoolUpgradeStrategy.pause
kolom tersebut dapat berubah. Anda dapat menambahkan dan memperbaruinya kapan saja.
Menjeda upgrade
Anda menjeda upgrade cluster dengan menetapkan nodePoolUpgradeStrategy.pause
ke true
yang tersedia 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 selanjutnya.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 untuk untuk jeda yang lama, tekan Control+C untuk keluar daribmctl
. Jika tidak, membuatbmctl
tetap berjalan.CLI
bmctl
tidak mendeteksi perubahan dalam status jeda upgrade, sehingga tidak keluar secara otomatis. Namun, saat Anda keluar daribmctl
, aktivitas tersebut akan berhenti mencatat log progres upgrade ke logcluster-upgrade-TIMESTAMP
dalam folder cluster di workstation admin Anda dan Cloud Logging. Oleh karena itu, untuk jeda singkat, sebaiknya pertahankanbmctl
sedang berjalan. Jika Anda membiarkanbmctl
berjalan dalam waktu lama saat upgrade dijeda, yang pada akhirnya kehabisan waktu.
Melanjutkan upgrade yang dijeda
Anda melanjutkan upgrade cluster yang dijeda dengan salah satu setelan
nodePoolUpgradeStrategy.pause
hingga false
dalam spesifikasi Cluster atau penghapusan
nodePoolUpgradeStrategy.pause
dari spesifikasi.
Untuk melanjutkan upgrade cluster yang dijeda, gunakan langkah-langkah berikut:
Setel
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
mereka: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 cluster admin {i>kubeconfig<i}.
Contoh berikut menunjukkan format respons untuk
BareMetalMachine
resource kustom. 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
(versi terbaru resource), mengambil detail untuk setiap resource:kubectl describe RESOURCE RESOURCE_NAME \ --kubeconfig ADMIN_KUBECONFIG \ --namespace CLUSTER_NAMESPACE
Contoh berikut menunjukkan detail
BareMetalMachine
untuk cluster node 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.