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 hanya didukung untuk kumpulan node Ubuntu dan COS. 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 Peran dan tugas 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 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 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.

Urutan upgrade versi lewati

Misalkan panel kontrol cluster Anda dan semua node pool berada pada versi minor 1.N. Pada tingkat tinggi, mengupgrade cluster dari 1.N ke 1.N+2 menggunakan upgrade versi lewati 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 guna 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. 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

Langkah selanjutnya