Cluster Anthos on bare metal kini menjadi Google Distributed Cloud (khusus software) untuk bare metal. Untuk mengetahui informasi selengkapnya, lihat ringkasan produk.

Halaman ini diterjemahkan oleh Cloud Translation API.

Mengupgrade cluster

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.

Halaman ini ditujukan untuk Admin, arsitek, serta Operator yang mengelola infrastruktur teknologi yang mendasarinya. Untuk mempelajari lebih lanjut tentang peran dan contoh tugas yang kami rujuk dalam konten Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise yang umum.

Rencanakan upgrade Anda

Bagian ini berisi informasi dan tautan ke informasi yang harus Anda pertimbangkan sebelum mengupgrade cluster. Untuk informasi selengkapnya tentang upgrade, termasuk aturan pembuatan versi untuk cluster dan node pool, lihat Siklus proses dan tahapan upgrade 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.30, Anda dapat meminta kumpulan node pekerja pada 1.30, 1.29, dan Versi 1.28.

Sebelum Anda dapat mengupgrade cluster, semua kumpulan node pekerja harus berada di yang kompatibel dengan versi cluster saat ini dan target versi cluster baru.

Misalnya, jika Anda memiliki cluster di versi 1.29 dan kumpulan node pekerja di versi 1.29, versi 1.28, dan versi 1.16, Anda harus mengupgrade versi 1.16 ke versi 1.28 atau 1.29 sebelum Anda dapat mengupgrade cluster ke versi 1,30.

Untuk informasi selengkapnya, termasuk daftar versi kumpulan node pekerja yang didukung didukung oleh versi cluster tertentu (berlaku untuk versi 1.29 dan yang lebih lama), lihat Aturan pembuatan versi kumpulan node

1,30

Pada rilis 1.30, 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.30.

Kumpulan node pada versi patch mana pun dari versi minor 1.28 dan 1.29 dapat diupgrade ke patch versi 1.30, jika versi kumpulan node sama atau lebih rendah dari versi cluster.

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.
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.29.0 dan memiliki dua kumpulan node pekerja: wpool01 dan wpool02. Juga, anggaplah Anda ingin untuk mengupgrade bidang kontrol dan wpool01 ke 1.30.0-gke.1930, tetapi Anda ingin wpool02 agar tetap berada di versi 1.29.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.30.0-gke.1930
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.30.0-gke.1930
  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.29.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. Setel anthosBareMetalVersion 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 apa pun. 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.30.0-gke.1930, tetapi kumpulan node wpool02 masih berada di versi lama, sebelum upgrade cluster versi 1.29.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.30.0-gke.1930
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.30.0-gke.1930
  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.

Fitur ini tidak berada pada fase peluncuran yang sama untuk semua versi cluster yang didukung:

1,30

Untuk cluster versi 1.30 (cluster dengan node bidang kontrol pada versi 1.30), kemampuan rollback kumpulan node bersifat GA dan diaktifkan secara default.

1,29

Kemampuan rollback kumpulan node tersedia untuk Pratinjau untuk cluster versi 1.29 (cluster dengan node bidang kontrol pada versi 1.29). Meskipun fitur ini di Pratinjau, Anda harus menambahkan anotasi berikut ke resource Cluster untuk mengaktifkan fitur:

preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable

1,28

Kemampuan rollback kumpulan node tidak tersedia untuk cluster pada skala minor versi 1.28 atau yang lebih lama.

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. Menetapkan anthosBareMetalVersion ke cluster (pra-upgrade) sebelumnya .
```
...
---
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
  ...
```
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 Setelan nodePoolUpgradeStrategy. Demikian juga, nilai dari spec.upgradeStrategy.parallelUpgrade.concurrentNodes dalam NodePool spesifikasi menentukan jumlah node yang di-roll back secara paralel.
Gunakan bmctl update untuk menerapkan perubahan spesifikasi NodePool 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. Perintah bmctl update cluster akan langsung keluar, tetapi proses rollback akan terus berjalan. Jangan lakukan operasi lain di cluster saat rollback sedang berlangsung.
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 resource NodePool disetel ke versi rollback target.

Jangan gunakan bmctl update dan kubectl apply -f secara bergantian saat mengedit file konfigurasi cluster. Ketika digunakan secara bergantian, isi diisi oleh {i>header <i}dari spesifikasi cluster mungkin tidak sengaja dihapus. Misalnya, Anda mungkin menggunakan bmctl update untuk memperbarui file konfigurasi cluster agar mengonfigurasi duplikat registry. Cluster tersebut kemudian telah mengisi spec.nodeConfig.registryMirrors setelah rekonsiliasi.

Jika Anda kemudian mencoba membuat perubahan pada cluster menggunakan cluster dengan perintah kubectl apply -f, spec.nodeConfig.registryMirrors diisi oleh rekonsiliasi pada cluster tersebut akan dihapus. Perilaku ini terjadi karena konfigurasi tidak ada di spesifikasi konfigurasi cluster, tetapi ada di cluster.

`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.29.400-gke.86
  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. Jangan lakukan operasi lain di cluster saat rollback sedang berlangsung.
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 resource NodePool 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 dengan minimumAvailableNodes, nilai gabungan tidak boleh melebihi jumlah total node dalam kumpulan node. Sebagai misalnya, jika kumpulan node Anda memiliki 20 node dan minimumAvailableNodes ditetapkan ke 18, concurrentNodes tidak boleh lebih dari 2. Demikian pula, jika concurrentNodes 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 adalah 5, yang berarti 5 node diupgrade secara paralel. Kolom minimumAvailableNodes disetel ke 10, artinya minimal 10 node harus tersedia untuk workload selama proses upgrade.

Catatan: Anda tidak dapat menentukan strategi upgrade node untuk bidang kontrol atau muatan node pool.

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.30.0-gke.1930
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

Dalam contoh ini, kolom concurrentNodePools ditetapkan ke 0, 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`. Jika Anda tidak menentukan `concurrentNodes`, `minimumAvailableNodes` secara default adalah 2/3 ukuran kumpulan node. Jika Anda menentukan `concurrentNodes`, maka `minimumAvailableNodes` secara default adalah ukuran kumpulan node minus `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 Kolom anthosBareMetalVersion 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.30.0-gke.1930
```
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:

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.30

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.29

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 pada spesifikasi Cluster.

Untuk menjeda upgrade cluster yang aktif, gunakan langkah-langkah berikut:

Tambahkan nodePoolUpgradeStrategy.pause ke file konfigurasi cluster dan tetapkan ke true:

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 dari bmctl. Jika tidak, membuat bmctl tetap berjalan.

CLI bmctl tidak mendeteksi perubahan dalam status jeda upgrade, sehingga tidak keluar secara otomatis. Namun, saat Anda keluar dari bmctl, aktivitas tersebut akan berhenti mencatat log progres upgrade ke log cluster-upgrade-TIMESTAMP dalam folder cluster di workstation admin Anda dan Cloud Logging. Oleh karena itu, untuk jeda singkat, sebaiknya pertahankan bmctl sedang berjalan. Jika Anda membiarkan bmctl 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 ke false:

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 adalah false.

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 dalam status mereka:

kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces

Ganti kode berikut:

RESOURCE: nama resource yang ingin Anda dapatkan. Resource Cluster, NodePool, dan BareMetalMachine semuanya berisi Informasi status anthosBareMetalVersion.
ADMIN_KUBECONFIG: jalur cluster admin {i>kubeconfig<i}.

Contoh berikut menunjukkan format respons untuk BareMetalMachine resource kustom. Setiap BareMetalMachine 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 IP 192.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.