Halaman ini diterjemahkan oleh Cloud Translation API.

Melewati versi saat mengupgrade node pool

Di versi 1.29 dan yang lebih tinggi, Google Distributed Cloud memungkinkan bidang kontrol cluster pengguna memiliki hingga dua versi minor yang lebih tinggi daripada node pool di cluster. Misalnya, jika panel kontrol cluster pengguna berada di 1.29, node pool di 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 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 melewati versi.

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

Halaman ini ditujukan untuk administrator dan Operator IT yang mengelola siklus proses infrastruktur teknologi yang mendasarinya. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten, lihat Peran dan tugas pengguna GKE umum. Google Cloud Halaman ini mengasumsikan bahwa Anda sudah cukup memahami perencanaan dan pelaksanaan upgrade Google Distributed Cloud seperti yang dijelaskan di bagian berikut:

Batasan

Upgrade melewati versi memiliki batasan berikut:

Upgrade melewati versi didukung untuk node pool Ubuntu dan COS, tetapi tidak untuk node pool Windows.
Versi 1.31: fitur ini tidak tersedia di cluster lanjutan.
Versi 1.32 dan yang lebih baru: fitur ini tersedia di cluster lanjutan.
Karena batasan Kubernetes, bidang kontrol cluster pengguna harus diupgrade satu versi minor dalam satu waktu. Namun, perhatikan bahwa mengupgrade bidang kontrol saja memerlukan waktu yang jauh lebih singkat dan lebih tidak berisiko daripada mengupgrade kumpulan node tempat workload Anda berjalan.

Manfaat upgrade melewati versi

Bagian ini menjelaskan beberapa manfaat menggunakan upgrade melewati versi.

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 selama satu tahun. Agar cluster Anda tetap berada dalam periode yang didukung, Anda harus melakukan upgrade versi minor kira-kira setiap empat bulan, seperti yang ditunjukkan 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 panjang 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 lewati versi, 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 agar 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 melewati versi, Anda tidak perlu memperbesar masa 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 dikuras dan dibuat ulang satu kali. Oleh karena itu, upgrade melewati versi menghemat waktu secara keseluruhan dan mengurangi gangguan workload.

Ringkasan

Singkatnya, upgrade melewati versi 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 melewati versi memerlukan waktu sekitar setengah dari waktu upgrade node pool dua kali. Demikian pula, dengan upgrade lewati versi, Anda hanya memiliki satu periode validasi, dibandingkan dengan dua periode validasi pada upgrade reguler.
Mengurangi gangguan: Rentang waktu yang lebih panjang antara upgrade dan waktu yang lebih singkat untuk melakukan upgrade dan validasi berarti workload Anda berjalan lebih lama dengan lebih sedikit gangguan.

Mengontrol versi bidang 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 tingkat teratas. Dengan mengubah nilai kolom nodePools[i].gkeOnPremVersion, Anda mengontrol kapan node pool diupgrade saat Anda menjalankan gkectl upgrade cluster. Jika Anda tidak menyertakan nodePools[i].gkeOnPremVersion dalam file konfigurasi, atau jika Anda menyetel kolom ke string kosong, node pool akan diupgrade ke versi target yang sama yang Anda tentukan di gkeOnPremVersion.

Aturan versi

Aturan untuk upgrade bergantung pada versi minor cluster.

Untuk versi 1.30 dan yang lebih rendah, versi minor cluster pengguna harus lebih besar daripada atau sama dengan versi minor cluster admin. Versi patch tidak penting. Misalnya, jika cluster pengguna berada di 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 berada di 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 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 yang dilewati

Urutan upgrade cluster admin dan pengguna bergantung pada versi cluster yang akan diupgrade, yang disebut sebagai versi target:

1.32 dan yang lebih tinggi

Gunakan urutan ini jika versi targetnya adalah 1.32 atau yang lebih tinggi. Misalkan bidang kontrol cluster pengguna dan semua node pool Anda berada di versi minor 1.N. Secara umum, mengupgrade cluster Anda dari 1.N ke 1.N+2 menggunakan upgrade lewati versi berfungsi sebagai berikut:

Upgrade cluster admin dari versi 1.N ke versi menengah, 1.N+1.
Upgrade cluster admin dari versi perantara, 1.N+1 ke versi target 1.N+2.
Upgrade hanya bidang kontrol cluster pengguna 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.
Upgrade panel kontrol dan node pool ke versi target, 1.N+2.

1.31

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

Jika cluster admin Anda menggunakan versi 1.27, upgrade ke 1.28.
Jika cluster admin Anda berada di versi 1.28, upgrade ke 1.29.
Upgrade hanya bidang kontrol cluster pengguna dari versi sumber, 1.29, ke versi perantara, 1.30. Biarkan node pool di versi sumber. Versi 1.30 perantara diperlukan karena bidang kontrol harus diupgrade satu versi minor dalam satu waktu.
Upgrade cluster admin dari versi 1.29 ke versi menengah, 1.30.
Upgrade cluster admin ke versi target, 1.31.
Upgrade bidang kontrol cluster pengguna dan node pool ke versi target, 1.31.

1.30 dan yang lebih rendah

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

Misalkan bidang kontrol cluster pengguna dan semua node pool Anda berada di versi sekunder 1.N. Secara umum, mengupgrade cluster Anda dari 1.N ke 1.N+2 menggunakan upgrade lewati versi berfungsi sebagai berikut:

Upgrade hanya bidang 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.
Upgrade bidang kontrol dan node pool ke versi target 1.N+2.

Melakukan upgrade melewati versi

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

Sebelum memulai

Pastikan versi saat ini (versi sumber) cluster adalah versi 1.16 atau yang lebih tinggi. Pastikan untuk memeriksa versi bidang kontrol (gkeOnPremVersion) dan semua node pool (nodePools[i].gkeOnPremVersion).
Di versi 1.29 dan yang lebih baru, pemeriksaan pra-penerbangan sisi server diaktifkan secara default. Pastikan untuk meninjau aturan firewall Anda untuk melakukan perubahan yang diperlukan.
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 logging-monitoring. Untuk mengetahui detailnya, lihat Persyaratan IAM dan Google API.

Lakukan upgrade

1.31

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

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

Jika cluster admin Anda berada di versi 1.27, ikuti langkah-langkah untuk mengupgrade workstation admin dan mengupgrade cluster admin ke versi 1.28.
Jika cluster admin Anda berada di versi 1.28, ikuti langkah-langkah untuk mengupgrade workstation admin dan mengupgrade cluster admin ke versi 1.29.
Untuk menghemat ruang di workstation admin, hapus paket yang didownload:
```
rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz
```

Saat cluster admin dan semua cluster pengguna berada di versi 1.29, Anda dapat memulai upgrade versi yang dilewati.

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`

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

Instal paket yang sesuai:

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

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

Instal paket yang sesuai:

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

Upgrade hanya 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 node pool di nodePools[i].gkeOnPremVersion ke versi sumber, SOURCE_VERSION.
  Setelah mengupdate file konfigurasi, file tersebut 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.
Tetapkan kolom bundlePath di file konfigurasi cluster admin ke versi paket 1.30 menengah:
```
bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"
```

Upgrade cluster admin ke versi 1.30 menengah:

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

Tetapkan kolom bundlePath di file konfigurasi cluster admin ke versi paket 1.31 target:
```
bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"
```

Upgrade the admin cluster to the target 1.31 version:

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

Upgrade bidang 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 mengupdate file konfigurasi, file tersebut akan terlihat seperti berikut:
```
gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...
```
2. Upgrade bidang kontrol dan node pool:
```
gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
```

1.30 dan yang lebih rendah

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

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
Dapatkan versi cluster saat ini. Ini adalah versi sumber (`1.N`).	`SOURCE_VERSION`
Pilih versi menengah (`1.N+1`).	`INTERMEDIATE_VERSION`
Pilih versi target (`1.N+2`). Pilih patch yang direkomendasikan dari versi minor target.	`TARGET_VERSION`

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

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.

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

Instal paket yang sesuai:

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

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 node pool di nodePools[i].gkeOnPremVersion ke versi sumber, SOURCE_VERSION.
  Setelah mengupdate file konfigurasi, file tersebut 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.
Upgrade bidang 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 mengupdate file konfigurasi, file tersebut akan terlihat seperti berikut:
```
gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...
```
2. Upgrade bidang 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 Anda untuk menghemat ruang:

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

Melewati versi saat mengupgrade node pool Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Batasan

Manfaat upgrade melewati versi

Lebih mudah untuk mempertahankan cluster Anda dalam versi yang didukung

Masa pemeliharaan yang lebih singkat

Ringkasan

Mengontrol versi bidang kontrol dan node pool selama upgrade

Aturan versi

Urutan upgrade versi yang dilewati

1.32 dan yang lebih tinggi

1.31

1.30 dan yang lebih rendah

Melakukan upgrade melewati versi

Sebelum memulai

Lakukan upgrade

1.31

1.30 dan yang lebih rendah

Langkah berikutnya

Melewati versi saat mengupgrade node pool