Aturan versi upgrade

Memahami pengaruh versi saat ini dan versi target terhadap upgrade cluster akan membantu Anda memverifikasi penyimpangan versi, urutan upgrade, dan persyaratan OS sebelum memulai.

Informasi upgrade khusus versi

Tabel berikut menjelaskan informasi upgrade khusus versi. Setelah tabel, Anda dapat menemukan detail tentang rilis tertentu. Versi diurutkan dari yang terbaru hingga terlama. Temukan versi yang Anda upgrade ke untuk mengetahui detail dan aturan spesifik yang berlaku untuk cluster Anda.

Versi Upgrade terlebih dahulu Versi bidang kontrol (CP) Versi worker node pool Status cluster lanjutan Fitur lama didukung? OS image default & yang diperlukan Perilaku upgrade node Kubeception cert-manager yang dipaketkan
1.36 Cluster admin 1.36, 1.35, 1.34 1.36, 1.35, 1.34 Wajib Tidak ada ubuntu_cgv2, cos_cgv2 Tidak didukung Paket
1.35 Cluster admin 1.35, 1.34, 1.33 1.35, 1.34, 1.33 Wajib Tidak ada ubuntu_cgv2, cos_cgv2 wajib (cgroup v1 dihapus) Tidak didukung Paket
1.34 Cluster admin 1.34, 1.33, 1.32 1.34, 1.33, 1.32 Wajib (tidak ada opsi tidak ikut; non-lanjutan dikonversi otomatis) Tidak ada ubuntu_cgv2 (default), cos_cgv2, ubuntu_containerd, cos Tidak didukung Paket
1.33 Cluster admin 1.33, 1.32, 1.31 1.33, 1.32, 1.31 Default (konversi otomatis) (hanya tidak ikut untuk 1.32 hingga 1.33) Tidak ada ubuntu_cgv2 (default), cos_cgv2, ubuntu_containerd, cos Tidak didukung Dipaketkan untuk cluster lanjutan
1.32 Cluster admin 1.32, 1.31, 1.30 1.32, 1.31, 1.30 GA (Upgrade didukung; upgrade node terpisah & lewati didukung) Tidak ada ubuntu_cgv2 (default), cos_cgv2, ubuntu_containerd, cos Tidak didukung (harus bermigrasi ke Controlplane V2) Dipaketkan untuk cluster lanjutan
1.31 Cluster admin 1.31, 1.30, 1.29 1.31, 1.30, 1.29 Pratinjau (tidak ada upgrade ke 1.32; tidak ada upgrade node terpisah atau lewati) Ya (Seesaw, F5, Kubeception, non-HA); migrasi ke fitur yang direkomendasikan sangat disarankan; Dataplane V2 wajib ubuntu_cgv2 (default), cos_cgv2, ubuntu_containerd, cos Node admin diupgrade dengan admin; node CP pengguna diupgrade dengan cluster pengguna Tidak dipaketkan
1.30 Cluster pengguna 1,30 1.30, 1.29, 1.28 Tidak tersedia Ya (Seesaw, F5, Kubeception, non-HA); migrasi ke fitur yang direkomendasikan sangat disarankan ubuntu_cgv2 (default), cos_cgv2, ubuntu_containerd, cos Node CP & admin diupgrade selama upgrade cluster admin Tidak dipaketkan
1.29 Cluster pengguna 1.29, 1.30 1.29, 1.28, 1.16 Tidak tersedia Ya (Seesaw, F5, Kubeception, non-HA) ubuntu_cgv2 (default), cos_cgv2, ubuntu_containerd, cos Node CP & admin diupgrade selama upgrade cluster admin Tidak dipaketkan
1.28 Cluster pengguna 1.28, 1.29, 1.30 1.28, 1.16, 1.15 Tidak tersedia Ya (Seesaw, F5, Kubeception, non-HA) ubuntu_containerd (default), cos, ubuntu_cgv2, cos_cgv2 Node CP & admin diupgrade selama upgrade cluster admin Tidak dipaketkan

Untuk semua versi, Anda harus mengupgrade versi node pool load balancer (node pool dengan enableLoadBalancer: true) secara bersamaan dan ke versi yang sama dengan bidang kontrol cluster pengguna.

Informasi upgrade berdasarkan versi rilis

Temukan bagian untuk versi yang Anda upgrade guna mendapatkan informasi spesifik yang Anda perlukan untuk mengupgrade ke versi tersebut.

Rilis 1.36

Upgrade terlebih dahulu: Cluster admin

Aturan perbedaan versi:

  • Cluster admin di versi 1.36 dapat mengelola cluster pengguna di versi 1.36, 1.35, dan 1.34.
  • Versi bidang kontrol cluster pengguna: 1.36, 1.35, atau 1.34.
  • Versi worker node pool: 1.36, 1.35, atau 1.34.

Status cluster lanjutan: Cluster lanjutan bersifat wajib.

Melewati upgrade node: Didukung.

Fitur lama yang didukung: Tidak. Memblokir upgrade.

OS image default dan yang diperlukan: ubuntu_cgv2, cos_cgv2. osImageType default untuk konfigurasi baru adalah ubuntu_cgv2.

Perilaku upgrade node Kubeception: Tidak didukung. Memblokir upgrade.

Alat upgrade:

  • gkectl: Diperlukan untuk cluster admin. Versi yang didukung adalah 1.36, 1.37, dan 1.38.
  • Terraform: Didukung jika Anda membuat cluster pengguna menggunakan Terraform.
  • Google Cloud console: Didukung untuk upgrade cluster pengguna.
  • Google Cloud CLI: Didukung untuk upgrade cluster pengguna.

Persyaratan tambahan:

  • Anda dapat menjalankan upgrade cluster admin secara asinkron dengan gkectl upgrade admin --async.

Rilis 1.35

Upgrade terlebih dahulu: Cluster admin

Aturan perbedaan versi:

  • Cluster admin di versi 1.35 dapat mengelola cluster pengguna di versi 1.35, 1.34, dan 1.33.
  • Versi bidang kontrol cluster pengguna: 1.35, 1.34, atau 1.33.
  • Versi worker node pool: 1.35, 1.34, atau 1.33.

Status cluster lanjutan: Cluster lanjutan bersifat wajib.

Melewati upgrade node: Didukung.

Fitur lama yang didukung: Tidak. Memblokir upgrade.

OS image default dan yang diperlukan: ubuntu_cgv2, cos_cgv2 wajib (cgroup v1 dihapus). osImageType default untuk konfigurasi baru adalah ubuntu_cgv2. Anda harus memigrasikan cluster ke cgroup v2 sebelum melakukan upgrade.

Perilaku upgrade node Kubeception: Tidak didukung. Memblokir upgrade.

Alat upgrade:

  • gkectl: Diperlukan untuk cluster admin. Versi yang didukung adalah 1.35, 1.36, dan 1.37.
  • Terraform: Didukung jika Anda membuat cluster pengguna menggunakan Terraform.
  • konsol: Didukung untuk upgrade cluster pengguna.
  • gcloud CLI: Didukung untuk upgrade cluster pengguna.

Persyaratan tambahan:

  • Anda dapat menjalankan upgrade cluster admin secara asinkron dengan gkectl upgrade admin --async.

Rilis 1.34

Upgrade terlebih dahulu: Cluster admin

Aturan perbedaan versi:

  • Cluster admin di versi 1.34 dapat mengelola cluster pengguna di versi 1.34, 1.33, dan 1.32.
  • Versi bidang kontrol cluster pengguna: 1.34, 1.33, atau 1.32.

  • Versi worker node pool: 1.34, 1.33, atau 1.32.

Status cluster lanjutan: Cluster lanjutan bersifat wajib.

Melewati upgrade node: Didukung.

Fitur lama yang didukung: Tidak. Memblokir upgrade.

OS image default dan yang diperlukan: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. osImageType default adalah ubuntu_cgv2.

Perilaku upgrade node Kubeception: Tidak didukung. Memblokir upgrade.

Alat upgrade:

  • gkectl: Diperlukan untuk cluster admin. Diperlukan untuk mengonversi cluster non-lanjutan menjadi cluster lanjutan (wajib di 1.34; versi biner gkectl harus sama persis dengan versi rilis target). Versi yang didukung adalah 1.34, 1.35, dan 1.36.
  • Terraform: Didukung jika Anda membuat cluster pengguna menggunakan Terraform.
  • konsol: Didukung untuk upgrade cluster pengguna lanjutan.
  • gcloud CLI: Didukung untuk upgrade cluster pengguna lanjutan.

Persyaratan tambahan:

Persyaratan tambahan berikut berlaku untuk upgrade ke versi 1.34:

  • Cluster non-lanjutan akan otomatis dikonversi menjadi cluster lanjutan saat Anda mengupgrade ke 1.34. Untuk mengetahui informasi tentang aturan khusus untuk upgrade dari cluster non-lanjutan ke cluster lanjutan, lihat Mengupdate atau mengupgrade cluster ke cluster lanjutan.

  • cert-manager yang dipaketkan bersifat wajib dan diupdate ke versi 1.19, menggantikan penginstalan cert-manager kustom yang sudah ada. Untuk mengetahui informasi selengkapnya tentang upgrade ke cert-manager yang dipaketkan, lihat Menggunakan cert-manager yang dipaketkan.

  • Runtime container node diupgrade ke containerd 2.0. Hal ini dapat menimbulkan dampak berikut:

    • containerd 2.0 tidak mendukung image Docker Image Manifest v2 atau Schema 1 lama. Pastikan workload mengambil image container menggunakan Docker Schema 2 atau format yang sesuai dengan OCI sebelum Anda mengupgrade ke 1.34.
    • Konfigurasi mirror registry dimigrasikan ke format hosts.toml di containerd 2.0. Jika Anda mengelola konfigurasi mirror kustom atau endpoint registry air-gapped langsung di node, pastikan konfigurasi Anda sesuai dengan hosts.toml.
    • Jika Anda menggunakan DaemonSet atau skrip kustom yang melakukan patch pada /etc/containerd/config.toml, pastikan DaemonSet atau skrip tersebut tidak menggunakan opsi konfigurasi containerd v1 yang tidak digunakan lagi, yang dapat menyebabkan kegagalan startup containerd dengan containerd 2.0.

  • Nilai default kolom nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate berubah di versi 1.34.300. Jika Anda menginginkan upgrade node pool berurutan di versi 1.34.300+, tetapkan nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate: 1 di file konfigurasi cluster pengguna:

    • Untuk versi 1.34.0-1.34.200, nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate ditetapkan secara default ke 1, yang mengupdate satu node pool dalam satu waktu secara berurutan.
    • Untuk versi 1.34.300+, nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate ditetapkan secara default ke 0, yang mengupdate semua node pool secara serentak.

    Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi kebijakan update node pool.

  • Pemeriksaan preflight upgrade secara aktif memvalidasi semua konfigurasi PodDisruptionBudget (PDB) di seluruh cluster. Sebelum mengupgrade, pastikan workload Anda tidak memiliki PDB yang terlalu ketat (misalnya, maxUnavailable: 0 atau minAvailable yang cocok dengan total replika) yang memblokir pengosongan node atau pemeriksaan preflight dapat gagal.

  • Jika upgrade terganggu, upgrade langsung ke versi 1.34.300-gke.59 atau yang lebih tinggi. Versi ini mencegah penghapusan cluster bootstrap jika Anda perlu menjalankan ulang gkectl upgrade admin setelah terjadi kegagalan. Untuk mengetahui informasi selengkapnya, lihat Menjalankan ulang gkectl upgrade admin akan menghapus cluster bootstrap.

  • Anda dapat menjalankan upgrade cluster admin secara asinkron dengan gkectl upgrade admin --async untuk cluster lanjutan, kecuali saat Anda mengonversi dari cluster non-lanjutan ke cluster lanjutan.

Rilis 1.33

Upgrade terlebih dahulu: Cluster admin

Aturan perbedaan versi:

  • Cluster admin di versi 1.33 dapat mengelola cluster pengguna di versi 1.33, 1.32, dan 1.31.
  • Versi bidang kontrol cluster pengguna: 1.33, 1.32, atau 1.31.

  • Versi worker node pool: 1.33, 1.32, atau 1.31.

Status cluster lanjutan: Cluster lanjutan adalah jenis cluster default dan dikonversi secara otomatis. Penonaktifan diizinkan. Untuk mengetahui informasi selengkapnya, lihat Mengupgrade dan memelihara cluster non-lanjutan. Jika Anda menetapkan enableAdvancedCluster ke false, pembuatan cluster baru akan gagal.

Melewati upgrade node: Didukung.

Fitur lama yang didukung: Tidak. Memblokir upgrade.

OS image default dan yang diperlukan: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. osImageType default adalah ubuntu_cgv2.

Perilaku upgrade node Kubeception: Tidak didukung. Memblokir upgrade.

Alat upgrade:

  • gkectl: Diperlukan untuk mengonversi cluster non-lanjutan menjadi cluster lanjutan (versi biner gkectl harus sama persis dengan versi rilis target). Diperlukan untuk cluster admin. Versi yang didukung adalah 1.33, 1.34, dan 1.35.
  • Terraform: Didukung jika Anda membuat cluster pengguna menggunakan Terraform.
  • konsol: Didukung untuk upgrade cluster pengguna lanjutan.
  • gcloud CLI: Didukung untuk upgrade cluster pengguna lanjutan.

Persyaratan tambahan:

Persyaratan tambahan berikut berlaku untuk upgrade ke versi 1.33:

  • Upgrade dari 1.32 ke 1.33 secara otomatis mengonversi cluster non-lanjutan menjadi cluster lanjutan secara default. Anda dapat mempertahankan cluster non-lanjutan. Untuk mengetahui informasi selengkapnya tentang cara menjaga cluster tetap non-lanjutan, lihat Mengupgrade dan memelihara cluster non-lanjutan.

  • Cluster lanjutan otomatis menginstal dan memaketkan cert-manager v1.18, yang menggantikan penginstalan cert-manager kustom yang sudah ada. Untuk mengetahui informasi selengkapnya tentang upgrade ke cert-manager yang dipaketkan, lihat Menggunakan cert-manager yang dipaketkan.

  • Jika Anda mengupgrade ke cluster lanjutan dalam rilis ini, versi biner gkectl harus sama persis dengan versi rilis target saat Anda mengonversi dari cluster non-lanjutan ke cluster lanjutan. Persyaratan ini hanya berlaku selama upgrade ke cluster lanjutan. Untuk semua upgrade lainnya di cluster lanjutan, aturan perbedaan versi standar berlaku.

  • Jika upgrade terganggu, upgrade langsung ke versi 1.33.700-gke.71 atau yang lebih tinggi. Versi ini mencegah penghapusan cluster bootstrap jika Anda perlu menjalankan ulang gkectl upgrade admin setelah terjadi kegagalan.

  • Anda dapat menjalankan upgrade cluster admin secara asinkron dengan gkectl upgrade admin --async untuk cluster lanjutan dan cluster HA non-lanjutan jika semua cluster pengguna menjalankan Controlplane V2. Anda tidak dapat menggunakan flag --async saat mengonversi dari cluster non-lanjutan ke cluster lanjutan.

Rilis 1.32

Upgrade terlebih dahulu: Cluster admin

Aturan perbedaan versi:

  • Cluster admin di versi 1.32 dapat mengelola cluster pengguna di versi 1.32, 1.31, dan 1.30.
  • Versi bidang kontrol cluster pengguna: 1.32, 1.31, atau 1.30.

  • Versi worker node pool: 1.32, 1.31, atau 1.30.

Status cluster lanjutan: Didukung.

Melewati upgrade node: Didukung.

Fitur lama yang didukung: Tidak. Memblokir upgrade.

OS image default dan yang diperlukan: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. osImageType default adalah ubuntu_cgv2.

Perilaku upgrade node Kubeception: Tidak didukung. Memblokir upgrade. Harus bermigrasi ke Controlplane V2.

Alat upgrade:

  • gkectl: Diperlukan untuk mengonversi cluster non-lanjutan menjadi cluster lanjutan (versi biner gkectl harus sama persis dengan versi rilis target). Diperlukan untuk cluster admin. Versi yang didukung adalah 1.32, 1.33, dan 1.34.
  • Terraform: Didukung jika Anda membuat cluster pengguna menggunakan Terraform.
  • konsol: Didukung untuk upgrade cluster pengguna lanjutan.
  • gcloud CLI: Didukung untuk upgrade cluster pengguna lanjutan.

Persyaratan tambahan:

Persyaratan tambahan berikut berlaku untuk upgrade ke versi 1.32:

  • Ini adalah versi pertama yang memungkinkan upgrade opsional ke cluster lanjutan GA yang didukung sepenuhnya. Anda dapat memilih untuk:

    • Mengupgrade ke cluster non-lanjutan dan mempertahankan cluster non-lanjutan. Jika memilih opsi ini, Anda dapat melakukan hal berikut, mulai rilis ini:

      • Upgrade bidang kontrol cluster pengguna dan worker node pool secara terpisah. Kumpulan worker node dapat memiliki hingga 2 versi minor di belakang bidang kontrol.
      • Jalankan upgrade secara asinkron untuk cluster admin dan pengguna.

    • Upgrade ke cluster non-lanjutan, lalu konversi cluster non-lanjutan menjadi cluster lanjutan. Jika memilih opsi ini, Anda dapat melakukan hal berikut, mulai rilis ini:

      • Upgrade bidang kontrol cluster pengguna dan node pool worker secara terpisah saat Anda mengupgrade cluster non-lanjutan, tetapi tidak saat Anda mengonversi ke cluster lanjutan. worker node pool dapat memiliki hingga 2 versi minor lebih lama dari bidang kontrol.
      • Jalankan upgrade secara asinkron untuk cluster admin dan pengguna saat Anda mengupgrade cluster non-lanjutan.
      • Saat Anda mengonversi ke cluster lanjutan, upgrade ke versi rilis 1.32.1000-gke.57 atau yang lebih tinggi karena versi ini menyertakan perbaikan untuk masalah umum yang mencegah penghapusan cluster bootstrap.

    • Mengupgrade ke cluster lanjutan secara langsung. Jika Anda memilih opsi ini, hal berikut akan berlaku, mulai rilis ini:

      • Anda harus mengupgrade bidang kontrol dan semua node pool secara bersamaan.
      • Anda dapat menjalankan upgrade secara asinkron untuk cluster pengguna, tetapi tidak untuk cluster admin.
      • Upgrade ke versi rilis 1.32.1000-gke.57 atau yang lebih tinggi karena versi ini menyertakan perbaikan untuk masalah umum yang mencegah penghapusan cluster bootstrap.

  • Fitur lama berikut tidak didukung mulai versi ini. Untuk mengetahui informasi selengkapnya, lihat Fitur lama:

    • Dataplane V1 (Calico). Upgrade ke Dataplane V2 sebelum mengupgrade ke 1.32.
    • Seesaw. Upgrade ke load balancer alternatif sebelum mengupgrade ke 1.32.
    • F5 BIG-IP terintegrasi. Upgrade ke load balancer alternatif sebelum mengupgrade ke 1.32.
    • Kubeception. Upgrade ke cluster non-Kubeception sebelum mengupgrade ke 1.32.
    • Cluster admin non-HA. Upgrade ke cluster admin HA sebelum mengupgrade ke 1.32.

  • Versi biner gkectl harus sama persis dengan versi rilis target saat Anda mengonversi dari cluster non-lanjutan ke cluster lanjutan. Persyaratan ini hanya berlaku selama upgrade ke cluster lanjutan. Untuk semua upgrade lainnya di cluster lanjutan, aturan perbedaan versi standar berlaku.

  • Jika upgrade terganggu, upgrade langsung ke versi 1.32.1000-gke.57 atau yang lebih tinggi. Versi ini mencegah penghapusan cluster bootstrap jika Anda perlu menjalankan ulang gkectl upgrade admin setelah terjadi kegagalan.

  • Di versi 1.32 dan yang lebih baru, Anda dapat menjalankan upgrade cluster admin secara asinkron dengan gkectl upgrade admin --async untuk cluster lanjutan dan cluster HA non-lanjutan jika semua cluster pengguna menjalankan Controlplane V2. Anda tidak dapat menggunakan flag --async saat mengonversi dari cluster non-lanjutan ke cluster lanjutan.

Rilis 1.31

Upgrade terlebih dahulu: Cluster admin

Aturan perbedaan versi:

  • Cluster admin di versi 1.31 dapat mengelola cluster pengguna di versi 1.31, 1.30, dan 1.29.
  • Versi bidang kontrol cluster pengguna: 1.31, 1.30, atau 1.29.
  • Versi worker node pool: 1.31, 1.30, atau 1.29. (Tidak didukung di cluster lanjutan 1.31).
  • Untuk mengupgrade dari 1.29/1.30 ke 1.31, Anda harus mengupgrade semua cluster ke versi 1.30 sebelum mengupgrade cluster admin ke 1.31.

Status cluster lanjutan: Hanya pratinjau. Tidak dapat mengupgrade ke versi yang lebih tinggi.

Melewati upgrade node: Didukung.

Fitur lama yang didukung: Dataplane V2 wajib; Kubeception, Seesaw, dan F5 masih didukung.

OS image default dan yang diperlukan: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. osImageType default adalah ubuntu_cgv2.

Perilaku upgrade node Kubeception: Node admin diupgrade dengan cluster admin; node CP pengguna diupgrade dengan cluster pengguna.

Alat upgrade:

  • gkectl: Diperlukan untuk cluster admin, cluster non-lanjutan, dan cluster lanjutan (pratinjau, untuk rilis ini). Versi yang didukung adalah 1.31, 1.32, dan 1.33.
  • Terraform: Didukung untuk cluster pengguna yang terdaftar jika Anda membuat cluster pengguna menggunakan Terraform.
  • konsol: Didukung untuk upgrade cluster pengguna yang terdaftar.
  • gcloud CLI: Didukung untuk upgrade cluster pengguna yang terdaftar.

Persyaratan tambahan:

Persyaratan tambahan berikut berlaku untuk upgrade ke versi 1.31:

  • Rilis ini memperkenalkan cluster lanjutan dalam mode pratinjau. Anda tidak dapat memigrasikan cluster non-lanjutan ke cluster lanjutan dalam rilis ini. Anda dapat membuat cluster baru sebagai cluster lanjutan, tetapi Anda tidak dapat mengupgrade cluster lanjutan versi pratinjau ini ke versi yang lebih tinggi. Sebaiknya jangan membuat cluster lanjutan dalam rilis ini. Untuk mengetahui informasi selengkapnya tentang tahap peluncuran produk, seperti pratinjau, lihat Tahap peluncuran produk.

  • Di versi 1.31 dan yang lebih baru, arsitektur upgrade berubah menjadi model yang mengharuskan cluster admin lebih tinggi dari atau sama dengan cluster pengguna. Sebelumnya, cluster pengguna dapat memiliki hingga dua versi minor lebih tinggi daripada cluster admin.

  • Anda harus mengupgrade cluster admin sebelum mengupgrade cluster pengguna yang dikelola oleh cluster admin. Cluster admin dapat mengelola cluster pengguna dengan versi minor yang sama atau hingga 2 versi minor lebih rendah. Misalnya, cluster admin pada versi 1.31 dapat mengelola cluster pengguna pada versi 1.31, 1.30, dan 1.29.

  • Untuk mengupgrade dari 1.29 ke 1.31, Anda harus melakukan staging paket 1.30 sebagai langkah perantara. Anda harus mendownload paket 1.30 dan 1.31 di workstation admin untuk mengupgrade ke 1.31. Untuk melakukan upgrade lewati versi dari 1.29 ke 1.31, lakukan hal berikut:

    1. Upgrade hanya bidang kontrol cluster pengguna dari 1.29 ke 1.30 (membiarkan node pool worker di 1.29).
    2. Mengupgrade cluster admin dari 1.29 ke 1.30.
    3. Mengupgrade cluster admin dari 1.30 ke target 1.31.
    4. Upgrade bidang kontrol cluster pengguna dan worker node pool secara bersamaan ke 1.31.

  • Jika Anda menggunakan Kubeception, node cluster admin akan diupgrade selama upgrade cluster admin dan node bidang kontrol cluster pengguna akan diupgrade selama upgrade cluster pengguna.

  • Untuk mengupgrade ke 1.31, Anda harus mengaktifkan Dataplane V2. Untuk mencegah konflik kebijakan jaringan dan penurunan traffic selama migrasi CNI, Anda harus menyimpan dan menghapus semua objek NetworkPolicy secara manual, lalu memulihkannya setelah upgrade. Untuk beralih ke Dataplane V2, lakukan hal berikut:

    1. Ekspor dan simpan semua kebijakan jaringan kustom Anda:

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get networkpolicy -A -o wide \
    --field-selector metadata.namespace!=kube-system
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get networkpolicy POLICY_NAME \
    -n NAMESPACE -o yaml > policy.yaml

      Ganti kode berikut:

      • USER_CLUSTER_KUBECONFIG: jalur file kubeconfig untuk cluster pengguna
      • POLICY_NAME: nama objek NetworkPolicy
      • NAMESPACE: namespace objek NetworkPolicy

    2. Hapus kebijakan jaringan dari cluster:

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    delete networkpolicy POLICY_NAME \
    -n NAMESPACE

    3. Tetapkan enableDataplaneV2: true dalam file konfigurasi cluster pengguna dan lakukan upgrade ke 1.31.

    4. Terapkan kebijakan yang disimpan setelah upgrade 1.31 selesai agar Cilium mengompilasinya dengan rapi ke dalam extended Berkeley Packet Filter (eBPF):

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    apply -f policy.yaml

  • Jika Anda memiliki cluster admin HA, dan semua cluster pengguna menjalankan Controlplane V2, Anda dapat menjalankan upgrade secara asinkron dengan perintah gkectl upgrade admin --async.

  • Dataplane V2 diperlukan untuk semua cluster pengguna. Sebelum mengupgrade cluster pengguna ke versi 1.31, ikuti langkah-langkah di bagian Mengaktifkan Dataplane V2.

  • Fitur lama tidak didukung di 1.32 dan Anda dapat menggantinya di 1.30 dan 1.31 untuk mencegah masalah saat mengupgrade ke 1.32.

Rilis 1.30

Upgrade terlebih dahulu: Cluster pengguna

Aturan perbedaan versi:

  • Cluster pengguna di versi 1.30 dapat dikelola oleh cluster admin di versi 1.30, 1.29, atau 1.28.
  • Cluster admin di versi 1.30 hanya dapat mengelola cluster pengguna di versi 1.30. Semua cluster pengguna dan cluster admin harus mencapai 1.30 sebelum Anda dapat mengupgrade cluster admin ke 1.31, dan Anda harus mengupgrade cluster admin ke 1.31 sebelum cluster pengguna dapat diupgrade ke 1.31.
  • Versi bidang kontrol cluster pengguna: 1.30.
  • Versi worker node pool: 1.30, 1.29, atau 1.28.

Status cluster lanjutan: Tidak tersedia.

Melewati upgrade node: Didukung.

Fitur lama yang didukung: Didukung. Migrasi ke fitur yang direkomendasikan sangat disarankan.

OS image default dan yang diperlukan: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. osImageType default adalah ubuntu_cgv2.

  • Perilaku upgrade node Kubeception:** Bidang kontrol & node admin diupgrade selama upgrade cluster admin

Alat upgrade:

  • gkectl: Diperlukan untuk cluster admin. Versi yang didukung adalah 1.30, 1.31, dan 1.32.
  • Terraform: Didukung untuk cluster pengguna yang terdaftar jika Anda membuat cluster pengguna menggunakan Terraform.
  • konsol: Didukung untuk upgrade cluster pengguna yang terdaftar.
  • gcloud CLI: Didukung untuk upgrade cluster pengguna yang terdaftar.

Persyaratan tambahan:

Persyaratan tambahan berikut berlaku untuk upgrade ke versi 1.30:

  • Untuk versi ini dan semua versi sebelumnya, Anda harus memigrasikan semua cluster pengguna sebelum mengupgrade cluster admin pengelola. Cluster admin harus berada di versi minor yang sama atau lebih rendah daripada cluster pengguna terkelola mana pun.

  • Jika Anda menggunakan Kubeception, berikut yang terjadi selama upgrade:

    1. Upgrade cluster pengguna. Karena bidang kontrol pengguna berada di dalam cluster admin, menjalankan gkectl upgrade cluster hanya akan mengupgrade node pool worker.
    2. Upgrade cluster admin. Upgrade cluster admin akan mengupgrade node admin dan otomatis mengupgrade semua bidang kontrol cluster pengguna secara bersamaan.

  • Jika Anda memiliki Controlplane V2, berikut hal yang terjadi selama upgrade:

    1. Upgrade cluster pengguna. Tindakan ini akan mengupgrade bidang kontrol dan worker node pool.
    2. Upgrade cluster admin. Tindakan ini akan mengupgrade node admin.

  • Saat membuat cluster pengguna baru, Anda harus menetapkan kolom enableControlplaneV2 ke true, yang merupakan default, mulai rilis ini. Jika Anda menetapkan kolom enableControlplaneV2 ke false, gkectl akan menolak file dan tidak akan membuat cluster.

  • Jika Anda memiliki cluster admin HA, dan semua cluster pengguna menjalankan Controlplane V2, Anda dapat menjalankan upgrade secara asinkron dengan perintah gkectl upgrade admin --async.

  • Fitur lama tidak didukung di 1.32 dan Anda dapat menggantinya di 1.30 dan 1.31 untuk mencegah masalah saat mengupgrade ke 1.32.

Rilis 1.29

Upgrade terlebih dahulu: Cluster pengguna

Aturan perbedaan versi:

  • Cluster pengguna di versi 1.29 dapat dikelola oleh cluster admin di versi 1.29, 1.28, atau 1.16.
  • Cluster admin di versi 1.29 dapat mengelola cluster pengguna di versi 1.29 dan 1.30. Cluster admin di versi 1.29 tidak dapat mengelola cluster pengguna di versi 1.31 karena semua cluster harus mencapai versi 1.30 terlebih dahulu dan cluster admin harus diupgrade ke versi 1.31 sebelum cluster pengguna dapat diupgrade ke versi 1.31.
  • Versi bidang kontrol cluster pengguna: 1.29 atau 1.30, yang lebih tinggi hingga 1 versi minor.
  • Versi worker node pool: 1.29, 1.28, atau 1.16.

Status cluster lanjutan: Tidak tersedia.

Melewati upgrade node: Didukung.

Fitur lama yang didukung: Didukung.

OS image default dan yang diperlukan: ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. osImageType default adalah ubuntu_cgv2.

Perilaku upgrade node Kubeception: Bidang kontrol & node admin diupgrade selama upgrade cluster admin

Alat upgrade:

  • gkectl: Diperlukan untuk cluster admin. Versi yang didukung adalah 1.29, 1.30, dan 1.31.
  • Terraform: Didukung untuk cluster pengguna yang terdaftar jika Anda membuat cluster pengguna menggunakan Terraform.
  • konsol: Didukung untuk upgrade cluster pengguna yang terdaftar.
  • gcloud CLI: Didukung untuk upgrade cluster pengguna yang terdaftar.

Persyaratan tambahan:

Persyaratan tambahan berikut berlaku untuk upgrade ke versi 1.29:

  • Worker node dapat memiliki hingga 2 versi minor lebih lama dari bidang kontrol (n+2).
  • Anda dapat melewati versi minor saat mengupgrade worker node pool. Misalnya, Anda dapat mengupgrade worker node pool dari 1.28 ke 1.30.
  • Pemeriksaan preflight berjalan sebagai pod di dalam cluster admin atau cluster kind bootstrap sementara, bukan di workstation admin.
  • Mulai versi ini, Anda dapat menjalankan pemeriksaan preflight tanpa mengupgrade cluster menggunakan gkectl upgrade cluster --dry-run.
  • Jika Anda memiliki cluster admin HA, dan semua cluster pengguna menjalankan Controlplane V2, Anda dapat menjalankan upgrade secara asinkron dengan perintah gkectl upgrade admin --async.

Rilis 1.28

Upgrade terlebih dahulu: Cluster pengguna

Aturan perbedaan versi:

  • Cluster pengguna di versi 1.28 dapat dikelola oleh cluster admin di versi 1.28, 1.16, atau 1.15.
  • Cluster admin di versi 1.28 dapat mengelola cluster pengguna di versi 1.28, 1.29, dan 1.30.
  • Versi bidang kontrol cluster pengguna: 1.28, 1.29, atau 1.30, yang lebih tinggi hingga 2 versi minor.
  • Versi worker node pool: 1.28, 1.16, atau 1.15, yang lebih rendah hingga 2 versi minor.

Status cluster lanjutan: Tidak tersedia.

Melewati upgrade node: Didukung.

Fitur lama yang didukung: Didukung.

Image OS default dan yang diperlukan: ubuntu_containerd, cos, ubuntu_cgv2, cos_cgv2. osImageType default adalah ubuntu_containerd.

Perilaku upgrade node Kubeception: Bidang kontrol & node admin diupgrade selama upgrade cluster admin

Alat upgrade:

  • gkectl: Diperlukan untuk cluster admin. Versi yang didukung adalah 1.28, 1.29, dan 1.30.
  • Terraform: Didukung untuk cluster pengguna yang terdaftar jika Anda membuat cluster pengguna menggunakan Terraform.
  • konsol: Didukung untuk upgrade cluster pengguna yang terdaftar.
  • gcloud CLI: Didukung untuk upgrade cluster pengguna yang terdaftar.

Persyaratan tambahan:

Persyaratan tambahan berikut berlaku untuk upgrade ke versi 1.28:

  • Anda harus mengaktifkan kubernetesmetadata.googleapis.com dan memberikan roles/kubernetesmetadata.publisher ke akun layanan logging-monitoring. Jika tidak, pemeriksaan preflight dapat gagal atau Anda mungkin melihat error 403 PERMISSION_DENIED. Aktifkan API dan berikan peran ke akun layanan logging-monitoring yang ada:

    gcloud services enable kubernetesmetadata.googleapis.com
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:LOGGING_SA" \
    --role="roles/kubernetesmetadata.publisher"

    Ganti kode berikut:

    • PROJECT_ID: ID project host fleet tempat cluster pengguna menjadi anggota.
    • LOGGING_SA: alamat email akun layanan logging-monitoring Anda.

  • Meskipun secara teknis memungkinkan untuk melewati versi selama upgrade node pool, fitur ini diperkenalkan sebagai fitur pratinjau dan tidak direkomendasikan untuk versi ini. Untuk mengetahui informasi selengkapnya tentang tahap peluncuran produk, seperti pratinjau, lihat Tahap peluncuran produk.

  • Node pool dengan load balancer yang dipaketkan harus sama persis dengan versi cluster.

  • Anda dapat mengupgrade beberapa node secara bersamaan dengan menetapkan kolom nodePools[i].updateStrategy.rollingUpdate.maxSurge. Cluster vSphere Anda harus memiliki CPU, RAM, dan alamat IP yang tersedia yang cukup untuk mengakomodasi VM lonjakan tambahan selama upgrade:

    • Tetapkan maxSurge: 1 (default) untuk mengupgrade satu node dalam satu waktu (mengosongkan, mengganti, memverifikasi, lalu mengulangi).
    • Tetapkan maxSurge: N (dengan N > 1) untuk menyediakan dan mengosongkan hingga N worker node secara bersamaan (misalnya, maxSurge: 3 mengupgrade 3 worker node secara serentak).

  • Anda harus memiliki setidaknya 100 GB kapasitas disk kosong di workstation admin untuk mengupgrade workstation admin.

  • Versi gkectl yang Anda gunakan untuk mengupgrade dapat lebih tinggi hingga dua versi minor daripada cluster saat ini. Anda tidak dapat menggunakan versi minor yang lebih rendah.

Rilis sebelum 1.28

Persyaratan tambahan berikut berlaku untuk upgrade ke rilis yang lebih lama dari versi 1.28. Tidak ada versi rilis antara 1.16 dan 1.28:

Rilis 1.16:

  • Perbedaan versi antara cluster admin dan pengguna serta antara bidang kontrol dan node pool hanya boleh berbeda 1 versi minor. Misalnya, cluster admin di 1.15 hanya dapat mengelola cluster pengguna dengan versi 1.15 atau 1.16. Bidang kontrol cluster pengguna yang diupgrade ke 1.16 dapat mengelola worker node pool yang menjalankan versi 1.15 atau 1.16. Pool pada versi 1.14 harus diupgrade ke 1.15 sebelum bidang kontrol dapat berpindah ke versi 1.16. Untuk mengetahui informasi selengkapnya tentang perbedaan versi, lihat Aturan perbedaan versi.
  • Cluster otomatis didaftarkan di GKE On-Prem API saat dibuat atau diupgrade ke versi 1.16. Dengan perubahan ini, Anda dapat melihat, memantau, dan mengupgrade cluster pengguna menggunakan konsol, gcloud CLI, dan Terraform, bukan hanya shell workstation admin.

Rilis 1.14:

  • Anda dapat mengupgrade bidang kontrol cluster pengguna terlebih dahulu, sehingga Anda tidak perlu mengosongkan dan mengupgrade setiap node pool worker secara bersamaan.
  • Selama upgrade, sistem akan otomatis memeriksa dan memperbarui file kubeconfig cluster admin dan pengguna yang ada di workstation, sehingga memperpanjang kredensial secara otomatis.

Rilis 1.13:

  • Sebelum versi ini, Anda dapat memiliki cluster admin offline. Rilis ini mengharuskan Anda mendaftarkan cluster admin ke Google Cloud. Untuk mengetahui informasi tentang cara mendaftarkan cluster, lihat Mendaftarkan cluster yang ada.
  • Untuk mengupgrade cluster ke Google Distributed Cloud khusus software untuk VMware versi 1.13 atau yang lebih baru, Anda harus mengupdate terlebih dahulu node pool cluster pengguna yang masih menggunakan Docker Engine ke containerd.

Gunakan cert-manager yang dipaketkan

Anda harus menggunakan cert-manager yang dipaketkan, yang otomatis diinstal pada cluster lanjutan. Saat Anda bermigrasi dari cluster non-lanjutan ke cluster lanjutan, cert-manager terintegrasi akan otomatis mengganti versi cert-manager yang diinstal pelanggan. Pastikan Anda tidak menerapkan konfigurasi atau fitur kustom penting ke cert-manager yang ada sebelum mengupdate atau mengupgrade ke cluster lanjutan.

Untuk melihat apakah Anda menerapkan konfigurasi atau fitur kustom penting ke cert-manager, lakukan hal berikut:

  • Menangguhkan alat continuous deployment. Jika Anda mengelola cert-manager menggunakan alat GitOps (seperti Config Sync, ArgoCD, atau Flux), tangguhkan sinkronisasi atau hapus manifes cert-manager dari repositori sebelum melakukan upgrade. Jika pengontrol GitOps mencoba merekonsiliasi cert-manager kembali ke versi lama atau manifes kustom saat upgrade cluster berjalan, pengontrol tersebut akan membuat loop rekonsiliasi yang dapat menghentikan upgrade cluster.
  • Jangan meng-uninstal atau menghapus pod, namespace, atau CRD cert-manager secara manual sebelum Anda mengupgrade. gkectl mengelola upgrade ini di tempat.
  • Jika Anda mengubah flag deployment cert-manager, pemilih node, atau batas resource pod, kembalikan perubahan tersebut. Cluster lanjutan tidak mendukung argumen biner kustom atau penggantian tingkat deployment di cert-manager.
  • Jika Anda menggunakan penerbit eksternal khusus, plugin webhook DNS-01 ACME pribadi, atau webhook kustom, pastikan plugin pihak ketiga Anda kompatibel dengan versi cert-manager yang dipaketkan untuk rilis yang Anda upgrade.

Untuk mengetahui informasi selengkapnya, lihat Mengupgrade ke cert-manager yang dipaketkan dengan cluster lanjutan.

Tabel berikut mencantumkan versi rilis yang memerlukan cert-manager yang dipaketkan:

Versi Status untuk cluster baru Status untuk upgrade cluster yang ada Perlu cert-manager yang dipaketkan?
1.34+ Wajib Konversi wajib (dipaketkan dengan v1.19) Wajib untuk semua pelanggan. Cluster non-lanjutan tidak dapat ada lagi.
1,33 Standard / Default untuk semua cluster baru Dikonversi otomatis ke cluster lanjutan secara default (dipaketkan dengan v1.18) Diperlukan untuk hampir semua cluster, kecuali jika secara eksplisit memilih tidak ikut dengan enableAdvancedCluster: false (khusus 1.32 → 1.33).
1.32 (GA) Diaktifkan secara default Konversi opsional ke cluster lanjutan Wajib jika cluster lanjutan diaktifkan.
1.31 (Pratinjau) Opsional (enableAdvancedCluster: true) Tidak didukung Wajib jika cluster lanjutan diaktifkan.

Untuk melihat versi cert-manager yang dipaketkan dengan setiap rilis yang didukung, lihat Versi cert-manager yang dipaketkan.

Controlplane V2

Jika Controlplane V2 diaktifkan, bidang kontrol untuk cluster pengguna akan berjalan di cluster pengguna itu sendiri. Untuk Controlplane V2, node bidang kontrol cluster pengguna diupgrade selama upgrade cluster pengguna, dan node bidang kontrol cluster admin diupgrade selama upgrade cluster admin.

Fitur lama

Tabel berikut mencantumkan fitur lama yang diblokir di versi 1.32 dan yang lebih baru. Jika menggunakan fitur ini, Anda harus bermigrasi ke alternatif yang direkomendasikan sebelum dapat mengupgrade ke versi 1.32 atau yang lebih baru.

| Fitur lama (diblokir di 1.32) | Ganti dengan (direkomendasikan) | Link ke petunjuk migrasi | | --- | --- | --- | | Dataplane V1 (Calico) | Dataplane V2 (Cilium / eBPF) | Migrasi ke Dataplane V2| | Kubeception | Controlplane V2 | Migrasi ke Controlplane V2 | | Cluster admin non-HA (1 replika) | Cluster admin HA (3 replika) | Migrasi ke cluster admin HA | | Load balancer Seesaw | MetalLB atau ManualLB | Migrasi ke MetalLB atau Migrasi jenis load balancer| | F5 BIG-IP terintegrasi (loadBalancer.kind: "F5BigIP") | ManualLB (dipasangkan dengan F5 Big-IP Controller atau CCGI) | Migrasi ke ManualLB |

Untuk mengetahui detail tentang cara bermigrasi dari fitur lama ke fitur yang direkomendasikan, lihat Merencanakan migrasi cluster ke fitur yang direkomendasikan.

Perilaku versi dan migrasi Kubeception

Kubeception adalah fitur lama yang harus dimigrasikan ke Controlplane V2 sebelum Anda dapat mengupgrade ke versi 1.32 atau yang lebih baru.

Upgrade berperilaku berbeda untuk cluster dengan Kubeception, bergantung pada versi Anda:

  • Untuk 1.28: Upgrade node admin & bidang kontrol selama upgrade cluster admin
  • Untuk 1.29: Upgrade node admin & bidang kontrol selama upgrade cluster admin

  • Untuk 1.30: Upgrade node admin & bidang kontrol selama upgrade cluster admin. Jika Anda menggunakan Kubeception, berikut yang terjadi selama upgrade:

    1. Upgrade cluster pengguna. Karena bidang kontrol pengguna berada di dalam cluster admin, menjalankan gkectl upgrade cluster hanya akan mengupgrade node pool worker.
    2. Upgrade cluster admin. Upgrade cluster admin akan mengupgrade node admin dan otomatis mengupgrade semua bidang kontrol cluster pengguna secara bersamaan.

  • Untuk 1.31: Node admin diupgrade dengan cluster admin; node bidang kontrol pengguna diupgrade dengan cluster pengguna.

  • Untuk versi 1.32 dan yang lebih baru: Kubeception tidak didukung. Anda harus bermigrasi ke Controlplane V2 sebelum dapat mengupgrade ke 1.32 atau yang lebih baru.

    Untuk mengetahui detail tentang cara memigrasikan Kubeception ke Controlplane V2, lihat Merencanakan migrasi cluster ke fitur yang direkomendasikan.

Perbedaan versi versus melewati versi selama upgrade

Penyimpangan versi adalah perbedaan yang diizinkan dalam versi minor antara cluster admin dan cluster pengguna terkelolanya, atau perbedaan dalam versi minor antara bidang kontrol cluster pengguna dan node pool di cluster pengguna.

Penyimpangan versi berbeda dengan melewati versi minor saat Anda mengupgrade.

Anda hanya dapat melewati versi minor saat mengupgrade worker node pool, setelah mengupgrade bidang kontrol. Hal ini berlaku untuk cluster lanjutan dan non-lanjutan, kecuali cluster lanjutan yang menjalankan versi 1.31 dan versi sebelum 1.28. Misalnya, jika worker node pool berada di versi 1.29, update bidang kontrol cluster pengguna ke 1.30, lalu 1.31. Setelah bidang kontrol berada di versi 1.31, upgrade worker node pool dari versi 1.29 ke 1.31 secara langsung, tanpa mengupgrade ke versi 1.30. Untuk mengetahui informasi selengkapnya, lihat Melewati versi saat mengupgrade node pool.

Untuk mengupgrade ke rilis minor yang lebih tinggi daripada rilis minor berurutan berikutnya, upgrade ke rilis minor berikutnya terlebih dahulu, lalu upgrade ke rilis minor yang lebih tinggi. Anda tidak dapat melewati versi minor saat mengupgrade bidang kontrol cluster admin dan pengguna. Misalnya, jika Anda ingin mengupgrade dari versi 1.34.x ke versi 1.36.x, Anda tidak dapat mengupgrade secara langsung. Anda harus mengupgrade dari 1.34.x ke 1.35.x terlebih dahulu, lalu mengupgrade ke 1.36.x.

Bidang kontrol cluster pengguna dapat memiliki hingga 2 versi minor lebih tinggi daripada node pool worker di cluster. Misalnya, jika bidang kontrol cluster pengguna berada di versi 1.36, worker node pool dalam cluster dapat berada di versi 1.34, 1.35, atau 1.36.

Apa saja perbedaan versi yang diizinkan?

Cluster admin dapat mengelola cluster pengguna hingga 2 versi minor lebih rendah. Misalnya, jika cluster admin berada di versi 1.31, cluster pengguna yang dikelola oleh cluster admin tersebut dapat berada di versi 1.29, 1.30, atau 1.31.

Sebelum versi 1.31, aturan perbedaan versi berikut berlaku:

  • Untuk versi 1.28 hingga 1.30, cluster pengguna dapat memiliki hingga 2 versi minor lebih tinggi daripada cluster adminnya. Misalnya, jika cluster admin berada di 1.15, cluster pengguna yang dikelola oleh cluster admin tersebut dapat berada di 1.15, 1.16, atau 1.28. Anda tidak dapat mengupgrade cluster pengguna 1.28 ke 1.29 hingga cluster admin diupgrade setidaknya ke versi 1.16. Karena versi 1.31 mengubah urutan upgrade untuk mewajibkan upgrade cluster admin terlebih dahulu, cluster admin di versi 1.29 atau 1.30 tidak dapat mengelola cluster pengguna di versi 1.31 atau 1.32. Semua cluster pengguna dan cluster admin harus mencapai 1.30 sebelum Anda dapat mengupgrade cluster admin ke 1.31.
  • Untuk versi 1.16 dan yang lebih rendah, cluster pengguna hanya boleh 1 versi minor lebih tinggi daripada cluster adminnya. Misalnya, jika cluster admin berada di versi 1.15, cluster pengguna yang dikelola oleh cluster admin tersebut dapat berada di versi 1.15 atau 1.16.

Apakah saya harus mengupgrade cluster pengguna sekaligus?

Saat mengupgrade cluster pengguna, Anda dapat memilih salah satu opsi berikut:

  • Upgrade seluruh cluster pengguna dengan bidang kontrol dan semua node pool di cluster secara bersamaan.
  • Upgrade bidang kontrol cluster pengguna dan biarkan node pool pada versi saat ini.
  • Mengupgrade bidang kontrol cluster pengguna dan mengupgrade node pool secara selektif.

Pendekatan yang Anda ambil bergantung pada beberapa faktor, seperti:

  • Lingkungan (produksi atau non-produksi) tempat cluster berada.
  • Durasi masa pemeliharaan Anda.
  • Versi cluster pengguna.

Misalnya, Anda mungkin ingin mengupgrade bidang kontrol cluster pengguna dan semua node pool di lingkungan pengembangan. Namun, di lingkungan produksi dengan masa pemeliharaan yang singkat, Anda mungkin hanya ingin mengupgrade bidang kontrol karena memerlukan waktu lebih singkat dan upgrade bidang kontrol tidak akan mengganggu workload pengguna.

Node pool load balancer (node pool dengan enableLoadBalancer: true) harus memiliki versi yang sama dengan cluster untuk setiap versi.

Aturan versi untuk gkectl

Versi gkectl yang dapat Anda gunakan untuk upgrade bergantung pada versi cluster target (yaitu, versi cluster yang akan diupgrade). Biasanya, Anda menggunakan versi gkectl yang sama dengan versi target cluster. Aturan berikut diterapkan selama upgrade:

  • Versi gkectl harus sama dengan atau lebih tinggi dari versi cluster minor target. Misalnya, jika Anda mengupgrade cluster 1.29 ke 1.30, Anda harus menggunakan gkectl 1.30 atau yang lebih tinggi. Versi patch tidak penting.

  • Versi gkectl dapat lebih tinggi hingga dua versi minor dari versi cluster saat ini. Misalnya, untuk mengupgrade cluster 1.28 ke 1.29, gunakan gkectl versi 1.29 atau 1.30, tetapi bukan versi 1.31 karena versi tersebut tiga versi minor lebih tinggi daripada versi cluster.

Versi biner gkectl harus sama persis dengan versi rilis target saat Anda mengonversi dari cluster non-advanced ke cluster advanced. Persyaratan versi yang ketat ini hanya berlaku selama upgrade ke cluster lanjutan. Untuk semua upgrade cluster lanjutan lainnya, aturan perbedaan versi standar berlaku.

Aturan upgrade versi patch

Upgrade ke versi patch terbaru jika memungkinkan untuk memastikan cluster Anda memiliki perbaikan keamanan terbaru. Versi patch tidak memengaruhi aturan penyimpangan dan upgrade versi. Untuk versi minor tertentu, Anda dapat mengupgrade ke versi patch yang lebih tinggi. Misalnya, Anda dapat mengupgrade dari 1.35.0 ke 1.35.1 dan Anda dapat mengupgrade dari 1.35.1 ke 1.35.3.

Langkah berikutnya