Melewati versi saat mengupgrade node pool

Pada versi 1.29 dan yang lebih tinggi, Google Distributed Cloud memungkinkan panel kontrol cluster pengguna hingga dua versi minor lebih tinggi daripada node pool dalam cluster. Misalnya, jika panel kontrol cluster pengguna berada di versi 1.29, node pool dalam cluster dapat berada di versi 1.16, 1.28, atau 1.29. Selain itu, Google Distributed Cloud memungkinkan Anda melewati satu versi minor saat mengupgrade node pool. Dengan menggunakan contoh sebelumnya, Anda dapat mengupgrade node pool yang berada di versi 1.16 langsung ke versi 1.29 dan melewati upgrade ke 1.28. Melewati versi minor saat mengupgrade node pool disebut sebagai upgrade versi lewati.

Upgrade versi lewati didukung untuk node pool Ubuntu dan COS, tetapi tidak untuk node pool Windows. Selain itu, fitur ini tidak tersedia jika Anda telah mengaktifkan cluster lanjutan.

Karena batasan Kubernetes, bidang kontrol cluster pengguna harus diupgrade satu versi minor dalam satu waktu. Namun, perlu diperhatikan bahwa mengupgrade hanya bidang kontrol memerlukan waktu yang jauh lebih sedikit dan lebih aman daripada mengupgrade node pool tempat workload Anda berjalan.

Halaman ini menjelaskan beberapa manfaat upgrade versi lewati dan memberikan langkah-langkah tentang cara melakukan upgrade versi lewati dengan membuat perubahan file konfigurasi dan menjalankan gkectl upgrade cluster.

Halaman ini ditujukan untuk Operator dan administrator IT 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 Tugas dan peran pengguna GKE Enterprise umum. Halaman ini mengasumsikan bahwa Anda sudah cukup memahami cara merencanakan dan menjalankan upgrade Google Distributed Cloud seperti yang dijelaskan di bawah ini:

Manfaat upgrade versi lewati

Bagian ini menjelaskan beberapa manfaat penggunaan upgrade versi lewati.

Lebih mudah untuk mempertahankan cluster Anda dalam versi yang didukung

Versi minor Google Distributed Cloud baru dirilis setiap empat bulan, dan setiap versi minor memiliki periode dukungan satu tahun. Agar cluster Anda tetap berada dalam periode yang didukung, Anda harus melakukan upgrade versi minor sekitar setiap empat bulan, seperti yang ditunjukkan dalam hal berikut:

Des

Jan

Feb

Mar

Apr

Mei

Jun

Jul

Agu

Sep

Okt

Nov

Des

Jan

Feb

Mar

Apr

Mei

Jun

Jul

Agu

Sep

Okt

Nov

Des

Jan

Feb

Mar
1,14 Upgrade
1,15 Upgrade
1.16 Upgrade
1,28 Upgrade
1,29 Upgrade

Persyaratan ini menimbulkan tantangan saat Anda memerlukan periode validasi yang lama untuk memverifikasi versi minor baru dan periode pemeliharaan yang singkat untuk mengupgrade cluster ke versi minor baru. Untuk mengatasi tantangan ini, Anda dapat menggunakan upgrade versi lewati, yang memungkinkan cluster Anda tetap berada dalam periode yang didukung dengan mengupgrade cluster setiap delapan bulan, bukan setiap empat bulan. Tabel berikut menunjukkan bahwa jika Anda melewati upgrade untuk versi 1.15, Anda hanya akan melakukan upgrade setelah delapan bulan, bukan empat bulan.

Des

Jan

Feb

Mar

Apr

Mei

Jun

Jul

Agu

Sep

Okt

Nov

Des

Jan

Feb

Mar

Apr

Mei

Jun

Jul

Agu

Sep

Okt

Nov

Des

Jan

Feb

Mar
1,14 Upgrade
1,15
1.16 Upgrade
1,28
1,29

Melewati satu versi minor saat mengupgrade node pool akan mengurangi jumlah upgrade yang diperlukan untuk tetap menggunakan versi yang didukung. Selain itu, Anda tidak perlu memenuhi syarat versi minor yang dilewati karena hanya digunakan oleh bidang kontrol untuk sementara.

Masa pemeliharaan yang lebih singkat

Dengan upgrade versi lewati, Anda tidak perlu memperbesar periode pemeliharaan. Melewati versi minor saat mengupgrade node pool memerlukan waktu yang sama dengan mengupgrade node pool ke versi minor berikutnya karena setiap node dalam node pool akan dikosongkan dan dibuat ulang satu kali. Oleh karena itu, upgrade versi lewati menghemat waktu secara keseluruhan dan mengurangi gangguan beban kerja.

Ringkasan

Singkatnya, upgrade versi lewati memberikan manfaat berikut:

  • Mendapatkan cluster ke versi yang didukung: Google Distributed Cloud mendukung tiga versi minor terbaru. Jika cluster Anda menggunakan versi yang tidak didukung, bergantung pada versi cluster, melewati versi minor saat mengupgrade node pool dapat membuat cluster Anda menggunakan versi yang didukung dengan lebih sedikit upgrade.

  • Hemat waktu: Melewati versi minor saat mengupgrade node pool memerlukan waktu yang sama dengan mengupgrade node pool ke versi minor berikutnya. Oleh karena itu, upgrade versi lewati memerlukan waktu sekitar setengah dari waktu upgrade node pool dua kali. Demikian pula, dengan upgrade versi lewati, Anda hanya memiliki satu periode validasi, dibandingkan dengan dua periode dengan upgrade reguler.

  • Mengurangi gangguan: Rentang yang lebih lama antara upgrade dan lebih sedikit waktu yang dihabiskan untuk upgrade dan validasi berarti workload Anda berjalan lebih lama dengan lebih sedikit gangguan.

Mengontrol versi panel kontrol dan node pool selama upgrade

Dalam file konfigurasi cluster pengguna, kolom nodePools[i].gkeOnPremVersion memungkinkan node pool tertentu menggunakan versi yang berbeda dengan kolom gkeOnPremVersion level teratas. Dengan mengubah nilai kolom nodePools[i].gkeOnPremVersion, Anda mengontrol kapan node pool diupgrade saat menjalankan gkectl upgrade cluster. Jika Anda tidak menyertakan nodePools[i].gkeOnPremVersion dalam file konfigurasi, atau jika Anda menetapkan kolom ke string kosong, node pool akan diupgrade ke versi target yang sama dengan yang Anda tentukan di gkeOnPremVersion.

Aturan versi

Aturan untuk upgrade bergantung pada versi minor cluster.

  • Untuk versi 1.30 dan yang lebih lama, versi minor cluster pengguna harus lebih besar atau sama dengan versi minor cluster admin. Versi patch tidak penting. Misalnya, jika cluster pengguna menggunakan versi 1.30.1, cluster admin dapat diupgrade ke versi patch yang lebih tinggi, seperti 1.30.3.

  • Untuk versi 1.31 dan yang lebih baru, versi cluster admin, termasuk versi patch, harus lebih besar dari atau sama dengan versi cluster pengguna. Misalnya, jika cluster admin menggunakan versi 1.31.1, versi tertinggi yang dapat diupgrade oleh cluster pengguna adalah 1.31.1.

Jika ingin mengupgrade cluster ke versi 1.31, Anda harus mengupgrade semua cluster ke versi 1.30 terlebih dahulu. Setelah semua cluster berada di versi 1.30, Anda harus mengupgrade cluster admin ke versi 1.31. Setelah itu, Anda dapat mengupgrade cluster pengguna ke versi patch 1.31 yang sama dengan cluster admin.

Urutan upgrade versi lewati

Urutan upgrade cluster admin dan pengguna bergantung pada versi cluster yang menjadi tujuan upgrade Anda, yang disebut sebagai versi target:

1,31

Gunakan urutan khusus ini jika cluster pengguna menggunakan versi 1.29, yang berarti versi targetnya adalah 1.31. Jika cluster pengguna menggunakan versi 1.29, cluster admin yang mengelola cluster pengguna dapat menggunakan versi 1.27, 1.28, atau 1.29.

  1. Jika cluster admin Anda menggunakan versi 1.27, upgrade ke versi 1.28.
  2. Jika cluster admin Anda menggunakan versi 1.28, upgrade ke versi 1.29.
  3. Hanya upgrade panel kontrol cluster pengguna dari versi sumber, 1.29, ke versi perantara, 1.30. Biarkan node pool pada versi sumber. Versi perantara 1.30 diperlukan karena bidang kontrol harus diupgrade satu versi minor dalam satu waktu.
  4. Upgrade cluster admin dari versi 1.29 ke versi perantara, 1.30.
  5. Upgrade cluster admin ke versi target, 1.31.
  6. Upgrade panel kontrol cluster pengguna dan node pool ke versi target, 1.31.

1.30 dan yang lebih lama

Gunakan urutan ini jika versi target adalah 1.30 atau yang lebih rendah.

Misalkan panel kontrol cluster pengguna dan semua kumpulan node Anda berada pada versi minor 1.N. Pada tingkat tinggi, mengupgrade cluster dari 1.N ke 1.N+2 menggunakan upgrade versi lewat berfungsi sebagai berikut:

  1. Hanya upgrade panel kontrol dari versi sumber, 1.N, ke versi perantara 1.N+1. Biarkan node pool pada versi sumber. Versi perantara diperlukan karena bidang kontrol harus diupgrade satu versi minor dalam satu waktu.
  2. Upgrade panel kontrol dan node pool ke versi target 1.N+2.

Melakukan upgrade versi lewati

Bagian ini memberikan langkah-langkah untuk melakukan upgrade versi lewati.

Sebelum memulai

  1. Pastikan versi cluster saat ini (versi sumber) adalah versi 1.16 atau yang lebih tinggi. Pastikan untuk memeriksa versi panel kontrol (gkeOnPremVersion) dan semua node pool (nodePools[i].gkeOnPremVersion).

  2. Di versi 1.29 dan yang lebih baru, pemeriksaan pra-penerbangan sisi server diaktifkan secara default. Pastikan untuk meninjau aturan firewall untuk melakukan perubahan yang diperlukan.

  3. Untuk mengupgrade ke versi 1.28 dan yang lebih baru, Anda harus mengaktifkan kubernetesmetadata.googleapis.com dan memberikan peran IAM kubernetesmetadata.publisher ke akun layanan pemantauan logging. Untuk mengetahui detailnya, lihat persyaratan Google API dan IAM.

Melakukan upgrade

1,31

Gunakan urutan khusus ini jika cluster pengguna menggunakan versi 1.29, yang berarti versi targetnya adalah 1.31. Urutan ini diperlukan karena aturan versi berubah pada versi 1.31.

Jika cluster pengguna menggunakan versi 1.29, cluster admin yang mengelola cluster pengguna dapat menggunakan versi 1.27, 1.28, atau 1.29.

  1. Jika cluster admin Anda menggunakan versi 1.27, ikuti langkah-langkah untuk mengupgrade workstation admin dan mengupgrade cluster admin ke versi 1.28.

  2. Jika cluster admin Anda menggunakan versi 1.28, ikuti langkah-langkah untuk mengupgrade workstation admin dan mengupgrade cluster admin ke versi 1.29.

  3. Untuk menghemat ruang di workstation admin, hapus paket yang didownload:

    rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz

Jika cluster admin dan semua cluster pengguna berada di versi 1.29, Anda dapat memulai upgrade versi lewati.

  1. Tentukan versi sumber (1.29), versi perantara (1.30), dan versi target (1.31) dalam variabel placeholder berikut. Semua versi harus berupa nomor versi lengkap dalam bentuk x.y.z-gke.N seperti 1.29.700-gke.110.

    Versi
    Dapatkan versi 1.29 cluster pengguna saat ini. Ini adalah versi sumber. SOURCE_VERSION
    Pilih versi 1.30 menengah. INTERMEDIATE_VERSION
    Pilih versi target 1.31. Pilih patch yang direkomendasikan dari versi minor 1.31. TARGET_VERSION

  2. Upgrade workstation admin Anda ke versi menengah 1.30, INTERMEDIATE_VERSION. Tunggu pesan yang menunjukkan bahwa upgrade berhasil.

  3. Instal paket yang sesuai:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  4. Upgrade workstation admin Anda lagi, tetapi kali ini ke versi target 1.31, TARGET_VERSION. Tunggu pesan yang menunjukkan bahwa upgrade berhasil.

  5. Instal paket yang sesuai:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  6. Hanya upgrade bidang kontrol cluster pengguna ke versi perantara sebagai berikut:

    1. Buat perubahan berikut dalam file konfigurasi cluster pengguna:

      • Tetapkan kolom gkeOnPremVersion ke versi perantara, INTERMEDIATE_VERSION.

      • Tetapkan semua versi kumpulan node di nodePools[i].gkeOnPremVersion ke versi sumber, SOURCE_VERSION.

      Setelah diupdate, file konfigurasi Anda akan terlihat seperti berikut:

      gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...

    2. Upgrade bidang kontrol:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

      Ganti USER_CLUSTER_CONFIG dengan jalur file konfigurasi cluster pengguna Anda.

  7. Tetapkan kolom bundlePath dalam file konfigurasi cluster admin ke paket versi menengah 1.30:

    bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"

  8. Upgrade cluster admin ke versi perantara 1.30:

    gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

  9. Tetapkan kolom bundlePath dalam file konfigurasi cluster admin ke target paket versi 1.31:

    bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"

  10. Upgrade the admin cluster to the target 1.31 version:

    gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

  11. Upgrade panel kontrol dan node pool ke versi target sebagai berikut:

    1. Buat perubahan berikut dalam file konfigurasi cluster pengguna:

      • Tetapkan kolom gkeOnPremVersion ke versi target, TARGET_VERSION.

      • Tetapkan semua nodePools[i].gkeOnPremVersion ke string kosong.

      Setelah diupdate, file konfigurasi Anda akan terlihat seperti berikut:

      gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...

    2. Upgrade panel kontrol dan node pool:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

1.30 dan yang lebih lama

Gunakan urutan ini jika versi target adalah 1.30 atau yang lebih rendah.

  1. Tentukan versi sumber (1.N), versi perantara (1.N+1), dan versi target (1.N+2) dalam variabel placeholder berikut. Semua versi harus berupa nomor versi lengkap dalam bentuk x.y.z-gke.N seperti 1.16.11-gke.25.

    Versi
    Mendapatkan versi cluster saat ini. Ini adalah versi sumber (1.N). SOURCE_VERSION
    Pilih versi perantara (1.N+1). INTERMEDIATE_VERSION
    Pilih versi target (1.N+2). Pilih patch yang direkomendasikan dari versi minor target. TARGET_VERSION

  2. Upgrade workstation admin Anda ke versi menengah, INTERMEDIATE_VERSION. Tunggu pesan yang menunjukkan bahwa upgrade berhasil.

  3. Instal paket yang sesuai:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Ganti ADMIN_CLUSTER_KUBECONFIG dengan jalur file kubeconfig cluster admin Anda.

  4. Upgrade workstation admin Anda lagi, tetapi kali ini ke versi target, TARGET_VERSION. Tunggu pesan yang menunjukkan bahwa upgrade berhasil.

  5. Instal paket yang sesuai:

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  6. Upgrade hanya bidang kontrol ke versi perantara sebagai berikut:

    1. Buat perubahan berikut dalam file konfigurasi cluster pengguna:

      • Tetapkan kolom gkeOnPremVersion ke versi perantara, INTERMEDIATE_VERSION.

      • Tetapkan semua versi kumpulan node di nodePools[i].gkeOnPremVersion ke versi sumber, SOURCE_VERSION.

      Setelah diupdate, file konfigurasi Anda akan terlihat seperti berikut:

      gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...

    2. Upgrade bidang kontrol:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

      Ganti USER_CLUSTER_CONFIG dengan jalur file konfigurasi cluster pengguna Anda.

  7. Upgrade panel kontrol dan node pool ke versi target sebagai berikut:

    1. Buat perubahan berikut dalam file konfigurasi cluster pengguna:

      • Tetapkan kolom gkeOnPremVersion ke versi target, TARGET_VERSION.

      • Tetapkan semua nodePools[i].gkeOnPremVersion ke string kosong.

      Setelah diupdate, file konfigurasi Anda akan terlihat seperti berikut:

      gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...

    2. Upgrade panel kontrol dan node pool:

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

Jika Anda tidak memiliki cluster pengguna lain untuk diupgrade, hapus paket dari workstation admin untuk menghemat ruang:

rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz

Langkah berikutnya