Mengupgrade cluster

Saat menginstal bmctl versi baru, Anda dapat mengupgrade cluster yang ada yang dibuat dengan versi sebelumnya. Mengupgrade cluster ke versi Google Distributed Cloud terbaru akan menghadirkan fitur dan perbaikan tambahan ke 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 lebih lanjut proses upgrade dan aturan pembuatan versi, lihat Siklus proses dan tahap upgrade cluster.

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

Catatan: Saat mengupgrade Google Distributed Cloud dari versi dengan patch keamanan ke rilis minor berikutnya, sebaiknya upgrade ke versi patch tertinggi yang tersedia untuk memastikan Anda memiliki patch keamanan terbaru. Selalu tinjau catatan rilis sebelum mengupgrade agar Anda mengetahui apa saja yang telah berubah, termasuk perbaikan keamanan dan masalah umum. Downgrade ke versi cluster yang lebih rendah tidak didukung.

Merencanakan upgrade

Bagian ini berisi informasi dan link ke informasi yang harus Anda pertimbangkan sebelum mengupgrade cluster. Untuk mengetahui informasi selengkapnya tentang upgrade, termasuk aturan pembuatan versi untuk cluster dan node pool, lihat Siklus proses dan tahap upgrade cluster.

Praktik terbaik

Untuk informasi yang dapat membantu Anda mempersiapkan upgrade cluster, lihat Praktik terbaik untuk upgrade cluster Google Distributed Cloud.

Pemeriksaan preflight upgrade

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 sudah 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 dan 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 node pool worker selektif: mengupgrade node pool worker tertentu secara terpisah dari bagian cluster lainnya.

• Upgrade paralel: mengonfigurasi proses upgrade untuk mengupgrade grup node atau node pool secara bersamaan.

Opsi ini dapat mengurangi risiko gangguan pada aplikasi dan layanan penting serta mengurangi waktu upgrade secara keseluruhan secara signifikan. Opsi ini sangat berguna untuk cluster besar dengan banyak node dan node pool yang menjalankan workload penting. Untuk mengetahui informasi selengkapnya tentang fungsi opsi ini dan cara menggunakannya, lihat bagian berikut.

Lewati upgrade

Mulai versi 1.33, Google Distributed Cloud mendukung upgrade lewati untuk semua jenis cluster, sehingga Anda dapat mengupgrade cluster ke versi target (1.33 atau lebih tinggi) yang dua versi minor lebih tinggi dari versi saat ini dalam satu operasi. Misalnya, Anda dapat mengupgrade dari versi 1.N.X langsung ke versi 1.N+2.Z dengan satu operasi.

Daftar berikut menunjukkan tahap peluncuran untuk fitur ini per versi, dengan versi sebagai versi target upgrade:

• 1.34 dan yang lebih tinggi: GA
• 1.33: Pratinjau
• 1.32 dan yang lebih lama: Tidak tersedia

Upgrade lewati membantu Anda mengakses fitur dan perbaikan terbaru lebih cepat daripada dengan upgrade inkremental. Upgrade lewati juga dapat memperpanjang waktu antara operasi upgrade yang diperlukan, sehingga mengurangi potensi gangguan. Anda dapat menggunakan lewati upgrade bersama dengan opsi upgrade lainnya, seperti upgrade node pool worker selektif dan upgrade paralel.

Selama upgrade lewati, sistem akan mengupgrade cluster ke versi minor perantara, lalu segera mengupgradenya ke versi target. Versi perantara ini memiliki implikasi jika Anda menggunakan mirror registry. Untuk mengetahui informasi selengkapnya, lihat Persyaratan tambahan untuk mirror registry.

Melewati upgrade untuk cluster tersedia dalam Pratinjau untuk versi 1.33. Sebaiknya jangan melakukan upgrade lewati dari 1.31 ke 1.33 dengan cluster produksi.

Melewati prasyarat upgrade

Proses untuk melakukan upgrade lewati tidak berbeda dengan melakukan upgrade berurutan, tetapi ada beberapa prasyarat tambahan:

1. Pastikan cluster berada dalam status yang memungkinkan upgrade lewati tanpa melanggar aturan versi cluster dan node pool:

   • Sebelum memulai upgrade lewati untuk cluster admin atau hybrid, pastikan semua cluster pengguna terkelolanya berada di versi minor yang sama dengan cluster pengelola.

   • Sebelum memulai upgrade lewati untuk cluster pengguna, pastikan cluster Anda memenuhi kriteria berikut:

     • Admin pengelolaan atau cluster hybrid terkait memiliki dua versi minor yang lebih tinggi daripada cluster pengguna.

     • Semua kumpulan worker node untuk cluster pengguna berada di versi minor yang sama dengan cluster pengguna.

2. Tambahkan anotasi preview.baremetal.cluster.gke.io/skip-minor-version-cluster-upgrade ke file konfigurasi cluster:

   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: baremetal-demo
     namespace: cluster-baremetal-demo
     annotations:
       preview.baremetal.cluster.gke.io/skip-minor-version-cluster-upgrade: "enable"
   spec:
     type: user
     profile: default
     anthosBareMetalVersion:   1.36.200-gke.118
     ...
   

3. Perbarui anthosBareMetalVersion dalam file konfigurasi cluster ke versi target upgrade dari upgrade lewati.

Seperti upgrade berurutan, Anda dapat memulai upgrade lewati dengan bmctl upgrade cluster atau kubectl apply.

Persyaratan tambahan untuk mirror registry

Jika Anda mengambil image container dari mirror registry untuk mengupgrade cluster, mirror registry Anda harus memiliki image untuk versi target dan versi perantara dari upgrade lewati.

Untuk menyiapkan mirror registry Anda untuk upgrade lewati, ikuti langkah-langkah berikut:

1. Dengan menggunakan versi bmctl yang sesuai dengan versi target upgrade lewati, cari tahu versi perantara untuk upgrade lewati:

   bmctl upgrade intermediate-version
   

   Respons perintah terdiri dari versi patch Google Distributed Cloud tertentu yang digunakan sistem sebagai versi perantara selama upgrade lewati. Misalnya, untuk bmctl versi 1.33.0-gke.799, responsnya akan terlihat seperti berikut:

   1.32.200-gke.104
   

2. Download paket image untuk versi target dan versi perantara.

   Untuk mengetahui informasi selengkapnya, lihat Mendownload paket image.

3. Kirim paket image untuk versi target dan versi perantara ke duplikasi registry sebelum memulai upgrade lewati.

   Menghosting image container untuk versi target dan perantara memerlukan kapasitas disk tambahan untuk mirror registry Anda.

Seperti upgrade berurutan, Anda dapat memulai upgrade lewati dengan bmctl upgrade cluster atau kubectl apply.

Upgrade node pool worker selektif

Secara default, operasi upgrade cluster akan mengupgrade setiap node dan node pool dalam cluster. Upgrade cluster dapat mengganggu dan memakan waktu, karena menyebabkan setiap node dikosongkan dan semua pod terkait dimulai ulang dan dijadwalkan ulang. Bagian ini menjelaskan cara menyertakan atau mengecualikan node pool worker tertentu untuk upgrade cluster guna meminimalkan gangguan workload. Fitur ini hanya berlaku untuk cluster pengguna, hybrid, dan mandiri, karena cluster admin tidak mengizinkan node pool worker.

Anda dapat menggunakan upgrade node pool selektif dalam situasi berikut:

• Untuk mengambil perbaikan keamanan tanpa mengganggu workload: Anda dapat mengupgrade hanya node bidang kontrol (dan node load balancer) untuk menerapkan perbaikan kerentanan Kubernetes tanpa mengganggu worker node pool.

• Untuk mengonfirmasi pengoperasian yang tepat dari subset worker node yang diupgrade sebelum mengupgrade semua worker node: Anda dapat mengupgrade worker node pool secara selektif untuk memastikan bahwa workload berjalan dengan baik pada node pool yang diupgrade sebelum Anda mengupgrade node pool lain.

• Untuk mengurangi masa pemeliharaan: Mengupgrade cluster besar dapat memakan 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 node pool akan mengurangi waktu upgrade. Anda melakukan upgrade beberapa kali, tetapi masa pemeliharaan yang lebih kecil dan lebih dapat diprediksi dapat membantu penjadwalan.

Ketidaksesuaian versi node pool dua versi minor

Untuk cluster versi 1.28 dan yang lebih tinggi, versi node pool worker dapat berisi hingga dua versi minor di belakang versi cluster (bidang kontrol). Dengan dukungan ketidaksesuaian versi n-2, Anda juga dapat melewati versi rilis minor saat mengupgrade worker node pool dari dua versi minor di belakang cluster ke versi minor yang sama dengan cluster.

Dukungan ketidakselarasan versi n-2 untuk worker node pool memberi Anda lebih banyak fleksibilitas untuk merencanakan upgrade fleet.

Misalnya, jika Anda memiliki cluster versi 1.36, Anda dapat memiliki node pool worker pada versi 1.36, 1.35, dan 1.34 tertentu.

Sebelum Anda dapat mengupgrade cluster, semua node pool worker harus berada pada versi yang kompatibel dengan versi cluster saat ini dan versi cluster target.

Misalnya, jika Anda memiliki cluster di versi 1.29 dan node pool worker di versi 1.29, versi 1.28, dan versi 1.16, Anda harus mengupgrade node pool versi 1.16 ke versi 1.28 atau 1.29 sebelum dapat mengupgrade cluster ke versi 1.30.

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

1.30 dan yang lebih baru

Dalam rilis 1.30, dukungan penyimpangan versi n-2 untuk worker node pool tersedia secara umum untuk semua jenis cluster. Fitur ini diaktifkan secara default untuk cluster di versi 1.30.

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

1,29

Dalam rilis 1.29, dukungan penyimpangan versi n-2 untuk worker node pool tersedia secara umum untuk semua jenis cluster. Fitur ini diaktifkan secara default untuk cluster di versi 1.29.

Saat kami mentransisikan fitur ini dari Pratinjau Publik ke GA, cluster hybrid masih memerlukan anotasi pratinjau dalam situasi berikut. Jika Anda memiliki cluster hybrid versi 1.28.x dengan node pool worker versi 1.16.y, Anda harus menambahkan anotasi preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable ke cluster sebelum 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

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum di Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Dukungan penyimpangan versi n-2 untuk worker node pool tersedia untuk Pratinjau dalam 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, perbedaan versi maksimum antara node pool worker dan cluster adalah satu versi minor.

Untuk mengetahui informasi selengkapnya tentang aturan pembuatan versi untuk mengupgrade node pool worker secara selektif, lihat Aturan pembuatan versi node pool di Siklus proses dan tahapan upgrade cluster.

Mengupgrade bidang kontrol cluster dan node pool yang dipilih

Untuk mengupgrade node pool worker secara selektif dalam upgrade cluster awal:

1. Untuk worker node pool yang ingin Anda sertakan dalam upgrade cluster, lakukan salah satu perubahan berikut pada spesifikasi NodePool:

   • Tetapkan anthosBareMetalVersion dalam spesifikasi NodePool ke versi upgrade target cluster.
   • Hapus kolom anthosBareMetalVersion dari spesifikasi NodePool atau tetapkan ke string kosong. Secara default, worker node pool disertakan dalam upgrade cluster.

2. Untuk node pool worker yang ingin Anda kecualikan dari upgrade, tetapkan anthosBareMetalVersion ke versi cluster saat ini (pra-upgrade):

3. Lanjutkan upgrade Anda seperti yang dijelaskan dalam Memulai upgrade cluster.

   Operasi upgrade cluster mengupgrade node berikut:

   • Node bidang kontrol cluster.
   • Node pool load balancer, jika cluster Anda menggunakannya (spec.loadBalancer.nodePoolSpec). Secara default, node load balancer dapat menjalankan workload reguler. Anda tidak dapat mengupgrade node pool load balancer secara selektif, node pool ini selalu disertakan dalam upgrade cluster awal.
   • Node pool worker yang belum Anda kecualikan dari upgrade.

Misalnya, cluster Anda berada di versi 1.35.0 dan memiliki dua worker node pool: wpool01 dan wpool02. Selain itu, misalkan Anda ingin mengupgrade bidang kontrol dan wpool01 ke 1.36.200-gke.118, tetapi Anda ingin wpool02 tetap di versi 1.35.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.36.200-gke.118
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.36.200-gke.118
  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.35.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 node pool dari upgrade cluster, Anda dapat menjalankan upgrade cluster yang akan mengupgradenya ke versi cluster target. Worker node pool yang telah dikecualikan dari upgrade cluster memiliki kolom anthosBareMetalVersion dalam spesifikasi NodePool yang ditetapkan ke versi cluster sebelumnya (pra-upgrade).

Untuk mengupgrade worker node pool ke versi cluster yang diupgrade saat ini:

1. Edit spesifikasi NodePool dalam file konfigurasi cluster untuk node pool worker yang ingin Anda tingkatkan ke versi cluster saat ini. Tetapkan anthosBareMetalVersion ke versi cluster saat ini (setelah upgrade).

   Jika beberapa worker node pool dipilih untuk diupgrade, nilai spec.nodePoolUpgradeStrategy.concurrentNodePools dalam spesifikasi cluster menentukan jumlah node pool yang diupgrade secara paralel, jika ada. Jika Anda tidak ingin mengupgrade node pool worker secara serentak, pilih satu node pool dalam satu waktu untuk diupgrade.

2. Lanjutkan upgrade Anda seperti yang dijelaskan dalam Memulai upgrade cluster.

   Operasi upgrade cluster hanya mengupgrade node pool worker yang sebelumnya dikecualikan dan telah Anda tetapkan anthosBareMetalVersion ke versi cluster yang diupgrade saat ini.

Misalnya, Anda mengupgrade cluster ke versi 1.36.200-gke.118, tetapi node pool wpool02 masih menggunakan versi cluster lama sebelum upgrade, yaitu 1.35.0. Workload berjalan dengan baik di node pool yang diupgrade, wpool01, jadi sekarang Anda juga ingin mengupgrade 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.36.200-gke.118
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.36.200-gke.118
  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 mengalami masalah setelah mengupgrade worker node pool, Anda dapat me-roll back node pool ke versi sebelumnya.

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

1.30 dan yang lebih baru

Untuk cluster versi 1.30 (cluster dengan node bidang kontrol di versi 1.30), kemampuan rollback node pool berstatus GA dan diaktifkan secara default.

1,29

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum di Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Kemampuan rollback node pool tersedia untuk Pratinjau untuk cluster versi 1.29 (cluster dengan node bidang kontrol pada versi 1.29). Meskipun fitur ini dalam 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 node pool tidak tersedia untuk cluster pada versi minor 1.28 atau yang lebih lama.

Untuk melakukan roll back upgrade node pool, gunakan langkah-langkah berikut:

bmctl

Saat menggunakan bmctl untuk me-roll back upgrade node pool, Anda mengedit file konfigurasi cluster dan menerapkan perubahan dengan perintah bmctl update:

1. Edit spesifikasi NodePool dalam file konfigurasi cluster untuk node pool worker yang ingin Anda roll back ke versi sebelumnya. Tetapkan anthosBareMetalVersion ke versi cluster sebelumnya (sebelum upgrade).

   ...
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: NodePool
   metadata:
     name: wpool01
     namespace: cluster-user001
   spec:
     clusterName: user001
     anthosBareMetalVersion: 1.35.600-gke.141
     nodes:
     - address:  10.200.0.1
     - address:  10.200.0.2
     - address:  10.200.0.3
     ...
   

   Jika beberapa worker node pool dipilih untuk rollback, nilai spec.nodePoolUpgradeStrategy.concurrentNodePools dalam spesifikasi cluster menentukan jumlah node pool yang di-roll back secara paralel. Jika Anda tidak ingin melakukan rollback node pool worker secara serentak, pilih satu node pool satu per satu untuk rollback atau update setelan nodePoolUpgradeStrategy. Demikian pula, nilai spec.upgradeStrategy.parallelUpgrade.concurrentNodes dalam spesifikasi NodePool menentukan jumlah node yang di-roll back secara paralel.

2. 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 ingin Anda perbarui.

   • ADMIN_KUBECONFIG: jalur file kubeconfig cluster pengelolaan (admin, hybrid, atau mandiri).

   Rollback akan dimulai secara otomatis. Perintah bmctl update cluster segera keluar, tetapi rollback terus berlanjut. Jangan melakukan operasi lain pada cluster saat rollback sedang berlangsung.

3. Saat rollback berjalan, Google Distributed Cloud melakukan aktivitas berikut untuk setiap node:

   • Tempatkan node ke dalam mode pemeliharaan.
   • Jalankan tugas reset pada node untuk mengembalikannya ke status bersih.
   • Jalankan pemeriksaan preflight mesin pada node.
   • Jalankan tugas machine-init pada node untuk menginstal ulang node tersebut pada versi rollback target (pra-upgrade).
   • Hapus node dari mode pemeliharaan.

   Di akhir rollback yang berhasil, nilai nodePool.status.anthosBareMetalVersion di resource NodePool ditetapkan ke versi rollback target.

Jangan gunakan bmctl update dan kubectl apply -f secara bergantian saat mengedit file konfigurasi cluster. Jika perintah ini digunakan secara bergantian, konten yang diisi oleh header spesifikasi cluster mungkin akan dihapus secara tidak sengaja. Misalnya, Anda dapat menggunakan bmctl update untuk memperbarui file konfigurasi cluster guna mengonfigurasi mirror registry. Cluster kemudian akan mengisi spec.nodeConfig.registryMirrors setelah rekonsiliasi.

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

kubectl

Anda dapat me-roll back upgrade node pool menggunakan kubectl untuk mengedit resource NodePool secara langsung:

1. Untuk melakukan roll back worker node pool, buka resource NodePool untuk diedit:

   kubectl edit nodepool NODE_POOL_NAME \
       --namespace CLUSTER_NAMESPACE \
       --kubeconfig ADMIN_KUBECONFIG
   

   Ganti kode berikut:

   • NODE_POOL_NAME: nama node pool yang akan di-roll back.

   • CLUSTER_NAMESPACE: nama namespace tempat node pool di-deploy. Ini adalah namespace cluster.

   • ADMIN_KUBECONFIG: jalur file kubeconfig cluster pengelolaan (admin, hybrid, atau mandiri).

2. 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.35.600-gke.141
     nodes:
     - address:  10.200.0.1
     - address:  10.200.0.2
     - address:  10.200.0.3
     ...
   

3. Simpan dan tutup resource NodePool di editor Anda.

   Rollback akan dimulai secara otomatis. Jangan melakukan operasi lain pada cluster saat rollback sedang berlangsung.

4. Saat rollback berjalan, Google Distributed Cloud melakukan aktivitas berikut untuk setiap node:

   • Tempatkan node ke dalam mode pemeliharaan.
   • Jalankan tugas reset pada node untuk mengembalikannya ke status bersih.
   • Jalankan pemeriksaan preflight mesin pada node.
   • Jalankan tugas machine-init pada node untuk menginstal ulang node tersebut pada versi rollback target (pra-upgrade).
   • Hapus node dari mode pemeliharaan.

   Di akhir rollback yang berhasil, nilai nodePool.status.anthosBareMetalVersion di resource NodePool ditetapkan ke versi rollback target.

Upgrade paralel

Dalam upgrade cluster default yang umum, setiap node cluster diupgrade secara berurutan, satu per satu. Bagian ini menunjukkan cara mengonfigurasi cluster dan worker node pool agar beberapa node diupgrade secara paralel saat Anda mengupgrade cluster. Mengupgrade node secara paralel akan mempercepat upgrade cluster secara signifikan, terutama untuk cluster yang memiliki ratusan node.

Perhatian: Jika Anda menggunakan layanan data terkelola, seperti Portworx, untuk membantu mengelola workload stateful di cluster, sebaiknya jangan gunakan upgrade paralel.

Ada dua strategi upgrade paralel yang dapat Anda gunakan untuk mempercepat upgrade cluster:

• Upgrade node serentak: Anda dapat mengonfigurasi worker node pool agar beberapa node diupgrade secara paralel. Upgrade paralel node dikonfigurasi dalam spesifikasi NodePool (spec.upgradeStrategy.parallelUpgrade) dan hanya node dalam node pool worker yang dapat diupgrade secara paralel. Node di node pool bidang kontrol atau load balancer hanya dapat diupgrade satu per satu. Untuk mengetahui informasi selengkapnya, lihat Strategi upgrade node.

• Upgrade node pool serentak: Anda dapat mengonfigurasi cluster agar beberapa node pool diupgrade secara paralel. Hanya node pool worker yang dapat diupgrade secara paralel. Node pool bidang kontrol dan load balancer hanya dapat diupgrade satu per satu.

Strategi upgrade node

Anda dapat mengonfigurasi worker node pool 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. Untuk mengetahui informasi selengkapnya tentang kolom ini, lihat Referensi kolom konfigurasi cluster.

Penting: Upgrade paralel tidak mematuhi Anggaran Gangguan Pod (PDB). Jika workload Anda sensitif terhadap gangguan, sebaiknya gunakan kolom minimumAvailableNodes. Anda dapat menentukan jumlah minimum node yang harus tetap tersedia untuk menjalankan workload selama proses upgrade.

Strategi upgrade node hanya berlaku untuk node pool worker. Anda tidak dapat menentukan strategi upgrade node untuk node pool bidang kontrol atau load balancer. Selama upgrade cluster, node di node pool bidang kontrol dan load balancer diupgrade secara berurutan, satu per satu. Node pool bidang kontrol dan node pool load balancer ditentukan dalam spesifikasi Cluster (controlPlane.nodePoolSpec.nodes dan loadBalancer.nodePoolSpec.nodes).

Saat Anda mengonfigurasi upgrade paralel untuk node, perhatikan batasan berikut:

• Nilai concurrentNodes tidak boleh melebihi 50 persen dari jumlah node dalam node pool, atau angka tetap 15, mana saja yang lebih kecil. Misalnya, jika node pool Anda memiliki 20 node, Anda tidak dapat menentukan nilai yang lebih besar dari 10. Jika node pool Anda memiliki 100 node, 15 adalah nilai maksimum yang dapat Anda tentukan.

• Saat Anda menggunakan concurrentNodes bersama dengan minimumAvailableNodes, nilai gabungannya tidak boleh melebihi jumlah total node dalam node pool. Misalnya, jika node pool Anda memiliki 20 node dan minimumAvailableNodes ditetapkan ke 18, concurrentNodes tidak boleh melebihi 2. Demikian pula, jika concurrentNodes ditetapkan ke 10, minimumAvailableNodes tidak boleh melebihi 10.

Contoh berikut menunjukkan node pool worker np1 dengan 10 node. Dalam upgrade, node diupgrade 5 sekaligus dan setidaknya 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 node pool

Anda dapat mengonfigurasi cluster sehingga beberapa worker node pool diupgrade secara paralel. Kolom Boolean nodePoolUpgradeStrategy.concurrentNodePools dalam spesifikasi cluster menentukan apakah akan mengupgrade semua node pool worker untuk cluster secara serentak atau tidak. Secara default (1), node pool diupgrade secara berurutan, satu per satu. Jika Anda menetapkan concurrentNodePools ke 0, setiap worker node pool dalam cluster akan diupgrade secara paralel.

Node pool load balancing dan bidang kontrol tidak terpengaruh oleh setelan ini. Node pool ini selalu diupgrade secara berurutan, satu per satu. Node pool bidang kontrol dan node pool 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 node pool worker untuk upgrade paralel.

Untuk melakukan upgrade paralel pada worker node pool dan node dalam worker node pool, lakukan hal berikut:

1. 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 adalah 5, yang berarti 5 node diupgrade secara paralel. Kolom minimumAvailableNodes ditetapkan ke 10, yang berarti setidaknya 10 node harus tetap tersedia untuk workload selama upgrade.

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

2. Tambahkan bagian nodePoolUpgradeStrategy ke spesifikasi Cluster di 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.36.200-gke.118
     ...
     nodePoolUpgradeStrategy:
       concurrentNodePools: 0
     ...
   

   Dalam contoh ini, kolom concurrentNodePools ditetapkan ke 0, yang berarti semua node pool worker diupgrade secara serentak selama upgrade cluster. Strategi upgrade untuk node di node pool ditentukan dalam spesifikasi NodePool.

3. Upgrade cluster seperti yang dijelaskan di bagian Mengupgrade cluster admin, mandiri, hybrid, 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 ke nilai default kapan saja untuk menonaktifkan fitur sebelum upgrade berikutnya.

Tabel berikut mencantumkan kolom upgrade paralel dan nilai defaultnya:

Kolom	Nilai default	Arti
nodePoolUpgradeStrategy.concurrentNodePools (Spesifikasi cluster)	1	Upgrade node pool worker 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, maka minimumAvailableNodes secara default adalah 2/3 ukuran node pool. Jika Anda menentukan concurrentNodes, maka minimumAvailableNodes secara default adalah ukuran node pool dikurangi concurrentNodes.	Upgrade akan terhenti setelah minimumAvailableNodes tercapai dan hanya akan dilanjutkan setelah jumlah node yang tersedia lebih besar dari minimumAvailableNodes.

Memulai upgrade cluster

Bagian ini berisi petunjuk untuk mengupgrade cluster.

Catatan: Anda harus mengupgrade cluster admin sebelum mengupgrade cluster pengguna terkait. Namun, sebelum mengupgrade cluster admin ke 1.36.200-gke.118, pastikan cluster pengguna terkait berada di versi 1.35.0 atau yang lebih tinggi. bmctl akan menampilkan error jika menemukan cluster pengguna dengan versi yang lebih rendah dari 1.35.0.

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.

1. Tetapkan kredensial pengguna Anda sebagai Kredensial Default Aplikasi (ADC):

   gcloud auth application-default login
   

   Ikuti petunjuk untuk memilih Akun Google Anda untuk ADC. Untuk mengetahui informasi selengkapnya, lihat Menyiapkan Kredensial Default Aplikasi.

2. Download bmctl terbaru seperti yang dijelaskan dalam Download Google Distributed Cloud.

3. Perbarui anthosBareMetalVersion dalam file konfigurasi cluster ke versi target upgrade.

   Versi target upgrade harus cocok dengan versi file bmctl yang didownload. Cuplikan file konfigurasi cluster berikut menunjukkan kolom anthosBareMetalVersion 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.36.200-gke.118
   

4. 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.
   Catatan: Perintah bmctl upgrade hanya mengupdate nilai anthosBareMetalVersion dan anotasi pratinjau di resource kustom Cluster. Jika Anda ingin mengubah kolom lain dari spesifikasi cluster, gunakan perintah bmctl update. Untuk mengetahui informasi selengkapnya, lihat Mengupdate cluster.

   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 memverifikasi bahwa cluster dalam kondisi pengoperasian yang baik. Jika cluster tidak lulus semua health check, cluster akan terus berjalan hingga lulus. Jika semua health check lulus, upgrade akan berhasil diselesaikan.

   Untuk mengetahui informasi selengkapnya tentang urutan peristiwa untuk upgrade cluster, lihat Siklus proses dan tahap upgrade cluster.

kubectl

Untuk mengupgrade cluster dengan kubectl, lakukan langkah-langkah berikut:

1. Edit file konfigurasi cluster untuk menetapkan anthosBareMetalVersion ke versi target upgrade.

2. Untuk memulai upgrade, jalankan perintah berikut:

   kubectl apply -f CLUSTER_CONFIG_PATH
   

   Ganti CLUSTER_CONFIG_PATH dengan jalur file konfigurasi cluster yang telah diedit.

   Seperti 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 bmctl versi terbaru untuk mengupgrade cluster dengan kubectl, sebaiknya download bmctl terbaru. Anda memerlukan bmctl untuk melakukan tugas lain, seperti health check dan pencadangan, untuk memastikan cluster Anda tetap berfungsi dengan baik.

Menjeda dan melanjutkan upgrade

Fitur jeda dan lanjutkan upgrade memungkinkan Anda menjeda upgrade cluster sebelum selesai. Saat upgrade cluster dijeda, tidak ada upgrade worker node baru yang dipicu hingga upgrade dilanjutkan.

Fitur ini tersedia di (Pratinjau) untuk cluster dengan semua node bidang kontrol pada versi minor 1.28 atau yang lebih tinggi. Fitur ini tersedia secara umum untuk cluster dengan semua node bidang kontrol pada versi minor 1.29 atau yang lebih tinggi.

Anda mungkin ingin menjeda upgrade karena alasan berikut:

• Anda mendeteksi ada yang salah dengan workload cluster selama upgrade dan ingin menjeda upgrade untuk menyelidiki masalahnya

• Anda memiliki masa pemeliharaan yang singkat, sehingga Anda ingin menjeda upgrade di antara masa pemeliharaan

Saat upgrade cluster dijeda, operasi berikut didukung:

• Menambahkan atau menghapus node
• Menambahkan atau menghapus node pool
• Meningkatkan rentang jaringan layanan
• Memulihkan cluster dari cadangan

Saat node baru ditambahkan saat upgrade dijeda, tugas pemeriksaan mesin tidak akan berjalan di node tersebut hingga upgrade dilanjutkan dan selesai.

Saat upgrade cluster dijeda, operasi cluster berikut tidak didukung:

• Merotasi certificate authority
• Mencadangkan cluster

Anda tidak dapat memulai upgrade cluster baru saat upgrade cluster aktif dijeda.

Mengaktifkan jeda dan melanjutkan upgrade

Google Distributed Cloud 1.36

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

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum di Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Meskipun kemampuan jeda dan lanjutkan upgrade masih dalam Pratinjau, Anda dapat mengaktifkannya dengan anotasi di resource Cluster.

Untuk mengaktifkan jeda dan melanjutkan upgrade, gunakan langkah-langkah berikut:

1. 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: enable
   spec:
   ...
   

2. Untuk menerapkan perubahan, update cluster Anda:

   bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
   

   Ganti kode berikut:

   • CLUSTER_NAME: nama cluster yang ingin Anda update.
   • ADMIN_KUBECONFIG: untuk cluster admin, hybrid, atau mandiri, masukkan jalur ke file kubeconfig cluster. Untuk cluster pengguna, masukkan jalur ke file kubeconfig cluster admin.

   Kolom nodePoolUpgradeStrategy.pause dapat diubah. Anda dapat menambahkan dan memperbaruinya kapan saja.

Menjeda upgrade

Anda dapat menjeda upgrade cluster dengan menetapkan nodePoolUpgradeStrategy.pause ke true dalam spesifikasi Cluster.

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

1. 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 Anda menggunakan bmctl untuk memulai upgrade, Anda memerlukan jendela terminal baru untuk melakukan langkah berikutnya.

2. Untuk menerapkan perubahan, update cluster Anda:

   bmctl update CLUSTER_NAME
   

   Operasi upgrade dijeda. Tidak ada upgrade node baru yang dipicu.

3. Jika Anda menggunakan bmctl untuk memulai upgrade dan berencana menjeda dalam waktu lama, tekan Control+C untuk keluar dari bmctl. Jika tidak, biarkan bmctl tetap berjalan.

   bmctl CLI tidak mendeteksi perubahan pada status jeda upgrade, sehingga tidak akan keluar secara otomatis. Namun, saat Anda keluar dari bmctl, alat ini akan berhenti mencatat progres upgrade ke file log cluster-upgrade-TIMESTAMP di folder cluster di workstation admin Anda dan ke Cloud Logging. Oleh karena itu, untuk jeda singkat, Anda mungkin ingin tetap menjalankan bmctl. Jika Anda membiarkan bmctl berjalan dalam waktu lama saat upgrade dijeda, waktu tunggu 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 telah dijeda, gunakan langkah-langkah berikut:

1. Tetapkan 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 kolom ini ditetapkan secara default ke false.

2. Untuk menerapkan perubahan, update cluster Anda:

   bmctl update CLUSTER_NAME
   

   Operasi upgrade akan dilanjutkan dari bagian terakhir yang ditinggalkan.

3. Untuk memeriksa status upgrade, dapatkan terlebih dahulu daftar resource yang memiliki anthosBareMetalVersion di status-nya:

   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 file kubeconfig cluster admin.

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

4. Untuk memeriksa status.anthosBareMetalVersion (versi resource 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 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 menggunakan Google Distributed Cloud versi 1.16.2.