Cluster Anthos di VMware kini menjadi Google Distributed Cloud (khusus software) untuk VMware. Untuk mengetahui informasi selengkapnya, lihat ringkasan produk.

Halaman ini diterjemahkan oleh Cloud Translation API.

Ringkasan upgrade

Halaman ini memberikan ringkasan tentang proses upgrade dan informasi penyimpangan versi yang akan membantu Anda merencanakan urutan upgrade cluster di lingkungan multi-cluster. Untuk informasi perencanaan yang lebih mendetail, termasuk checklist untuk membantu Anda merencanakan upgrade, lihat Praktik terbaik upgrade.

Urutan upgrade

Upgrade di tempat sejak versi 1.7 harus selalu mengikuti urutan upgrade tertentu:

Upgrade workstation admin. Sebaiknya lakukan hal ini meskipun Anda berencana menggunakan konsol Google Cloud, Google Cloud CLI, atau Terraform untuk mengupgrade cluster pengguna.
Upgrade cluster pengguna, satu per satu.
- Pada versi 1.14 dan yang lebih baru, Anda dapat mengupgrade panel kontrol cluster pengguna secara terpisah dari node pool di cluster pengguna.
- Pada versi 1.16 dan yang lebih baru, Anda dapat memilih untuk melewati versi minor saat mengupgrade node pool. Untuk informasi selengkapnya, lihat Lewati versi saat mengupgrade node pool.
Setelah semua node pool di cluster pengguna memiliki versi yang sama dengan bidang kontrol cluster pengguna, cluster pengguna akan diupgrade sepenuhnya.

Cluster admin tidak boleh menggunakan versi minor yang lebih baru daripada cluster pengguna yang dikelolanya. Jika salah satu cluster pengguna Anda memiliki versi minor yang sama dengan cluster admin, Anda tidak dapat mengupgrade cluster admin.
Jika semua cluster pengguna setidaknya satu versi minor lebih baru dari cluster admin, Anda dapat mengupgrade cluster admin secara opsional.

Skew versi dan aturan versi untuk upgrade telah berubah di versi 1.28 dan yang lebih baru. Untuk mengetahui informasi selengkapnya, lihat Ketidakselarasan versi.

Upgrade cluster pengguna

Saat mengupgrade cluster pengguna, Anda dapat memilih untuk mengupgrade cluster pengguna secara keseluruhan (artinya Anda dapat mengupgrade bidang kontrol dan semua node pool dalam cluster), atau Anda dapat mengupgrade bidang kontrol cluster pengguna dan membiarkan node pool pada versi saat ini. 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, di lingkungan pengembangan, Anda mungkin ingin menyederhanakan proses dan mengupgrade bidang kontrol cluster pengguna dan semua kumpulan node. Namun, di lingkungan produksi dengan periode pemeliharaan yang singkat, Anda mungkin ingin hanya mengupgrade bidang kontrol karena memerlukan lebih sedikit waktu dan dengan bidang kontrol ketersediaan tinggi (HA), upgrade bidang kontrol tidak akan mengganggu workload pengguna. Jika panel kontrol menggunakan versi 1.28 atau yang lebih baru, Anda dapat melewati versi minor saat mengupgrade node pool.

Mengupgrade node pool secara terpisah dari panel kontrol didukung untuk node pool Ubuntu dan COS, tetapi tidak untuk node pool Windows.

Mengupgrade node pool secara selektif

Dalam situasi tertentu, Anda mungkin ingin mengupgrade beberapa, tetapi tidak semua node pool di cluster pengguna. Misalnya, setelah mengupgrade control plane, Anda dapat mengupgrade node pool yang memiliki traffic ringan atau menjalankan workload yang paling tidak penting. Setelah yakin bahwa beban kerja Anda berjalan dengan benar di versi baru, Anda dapat mengupgrade node pool tambahan, hingga akhirnya semua node pool diupgrade. Untuk mengetahui informasi selengkapnya, lihat Mengupgrade node pool.

Melewati versi minor saat mengupgrade node pool

Jika cluster Anda menggunakan versi 1.16 atau yang lebih tinggi, Anda dapat melewati versi minor saat mengupgrade node pool. Melakukan upgrade versi lewati akan mengurangi waktu upgrade node pool dua versi secara berurutan menjadi setengah. Selain itu, upgrade versi lewati memungkinkan Anda meningkatkan waktu antara upgrade yang diperlukan untuk tetap menggunakan versi yang didukung. Mengurangi jumlah upgrade akan mengurangi gangguan workload dan waktu verifikasi. Untuk informasi selengkapnya, lihat Lewati versi saat mengupgrade node pool.

Memilih alat untuk mengupgrade cluster pengguna

Google Distributed Cloud menyediakan pilihan alat untuk mengupgrade cluster pengguna.

Alat command line gkectl, yang Anda jalankan di workstation admin. Sebelum upgrade, Anda perlu mengubah file konfigurasi cluster pengguna untuk menetapkan versi target untuk bidang kontrol cluster dan secara opsional, untuk kumpulan node. Anda menentukan file ini di command line ke gkectl.
Konsol Google Cloud, Google Cloud CLI, atau Terraform, yang dapat Anda jalankan dari komputer apa pun yang memiliki konektivitas jaringan ke GKE On-Prem API. Alat standar ini adalah klien dari GKE On-Prem API, yang berjalan di infrastruktur Google Cloud.
- Anda dapat menggunakan Terraform untuk upgrade hanya jika membuat cluster pengguna menggunakan Terraform.
- Jika cluster pengguna Anda dibuat menggunakan gkectl, cluster tersebut harus terdaftar di GKE On-Prem API untuk menggunakan konsol atau gcloud CLI untuk upgrade. Di versi 1.16 dan yang lebih baru, cluster yang dibuat menggunakan gkectl terdaftar di GKE On-Prem API secara default. Untuk cluster yang dibuat di versi sebelumnya, Anda dapat mendaftarkan cluster setelah dibuat.
  
  Meskipun Anda memutuskan untuk menggunakan gkectl untuk upgrade, sebaiknya daftarkan cluster di GKE On-Prem API untuk mendapatkan informasi tentang cluster menggunakan konsol atau gcloud CLI.

Alat yang Anda gunakan bergantung pada cara Anda berencana mengupgrade cluster pengguna:

Mengupgrade cluster secara keseluruhan: Anda dapat menggunakan gkectl, Konsol Google Cloud, Google Cloud CLI, atau Terraform untuk mengupgrade cluster pengguna (panel kontrol beserta semua node pool).
Hanya mengupgrade panel kontrol: Anda dapat menggunakan gkectl, gcloud CLI, atau Terraform untuk mengupgrade panel kontrol cluster pengguna secara terpisah dari node pool. Konsol tidak mendukung upgrade hanya pada bidang kontrol.
Mengupgrade node pool secara selektif setelah panel kontrol diupgrade: Anda dapat menggunakan gkectl, gcloud CLI, atau Terraform untuk mengupgrade node pool tertentu setelah panel kontrol diupgrade.
Mengupgrade panel kontrol dan satu atau beberapa node pool secara bersamaan: Hanya gkectl yang mendukung kasus penggunaan ini.

Upgrade cluster admin

Jika bidang kontrol dan node pool di semua cluster pengguna setidaknya satu versi minor lebih baru dari cluster admin, Anda dapat mengupgrade cluster admin secara opsional. Hanya gkectl yang mendukung upgrade cluster admin. Klien GKE On-Prem API tidak mendukung upgrade cluster admin.

Skew versi

Skew versi adalah perbedaan versi minor antara cluster admin dan cluster pengguna terkelolanya. Di bagian berikut, versi cluster pengguna mengacu pada versi bidang kontrol dan kumpulan node secara bersamaan, secara keseluruhan.

Selain itu, skew versi adalah perbedaan versi minor antara panel kontrol cluster pengguna dan node pool di cluster pengguna.

Dalam lingkungan multi-cluster, memahami penyimpangan versi yang didukung dan aturan versi untuk upgrade dapat membantu Anda merencanakan urutan upgrade cluster.

Skew versi cluster admin dan pengguna

Cluster admin dapat mengelola cluster pengguna yang memiliki versi berbeda. Kemampuan ini memungkinkan Anda mengupgrade sejumlah cluster pengguna sesuai jadwal yang cocok untuk organisasi Anda.

1.29 dan yang lebih tinggi

Skew versi sama dengan di versi 1.28. Di versi 1.29, fitur ini ditransisikan ke tahap Ketersediaan Umum.

Pada versi 1.29 dan yang lebih baru, cluster pengguna dapat memiliki hingga 2 versi minor lebih tinggi daripada cluster adminnya. Misalnya, jika cluster admin berada di versi 1.28, cluster pengguna yang dikelola oleh cluster admin tersebut dapat berada di versi 1.28, 1.29, atau 1.30.

Secara umum, jika 1.n adalah versi minor cluster admin, cluster pengguna dapat berada di 1.n, 1.n+1, atau 1.n+2. Cluster pengguna di 1.n+2 tidak dapat diupgrade ke versi minor berikutnya hingga cluster admin diupgrade setidaknya satu versi minor.

1,28

Pada versi 1.28, cluster pengguna dapat memiliki hingga 2 versi minor yang 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, 1.16, atau 1.28. Cluster pengguna versi 1.28 tidak dapat diupgrade ke 1.29 hingga cluster admin diupgrade ke setidaknya 1.16.

1.16 dan yang lebih lama

Pada versi 1.16 dan yang lebih lama, 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.

Secara umum, jika 1.n adalah versi minor cluster admin, cluster pengguna dapat berada di 1.n atau 1.n+1. Cluster pengguna tidak dapat diupgrade ke versi minor berikutnya hingga cluster admin berada di versi minor yang sama dengan cluster pengguna.

Ketidaksesuaian versi node pool dan bidang kontrol cluster pengguna

1.29 dan yang lebih tinggi

Skew versi sama dengan di versi 1.28. Di versi 1.29, fitur ini ditransisikan ke tahap Ketersediaan Umum.

Pada versi 1.29 dan yang lebih baru, panel kontrol cluster pengguna dapat berisi hingga 2 versi minor yang lebih tinggi daripada node pool di cluster. Misalnya, jika panel kontrol cluster pengguna berada di versi 1.30, node pool di cluster dapat berada di versi 1.28, 1.29, atau 1.30.

Secara umum, jika 1.n adalah versi minor dari panel kontrol cluster pengguna, kumpulan node dalam cluster dapat berada di 1.n, 1.n-1, atau 1.n-2. Bidang kontrol cluster pengguna tidak dapat diupgrade ke versi minor berikutnya hingga semua node pool berada di 1.n atau 1.n-1.

1,28

Pada versi 1.28, panel kontrol cluster pengguna dapat berisi hingga 2 versi minor lebih tinggi daripada node pool dalam cluster. Misalnya, jika panel kontrol cluster pengguna berada di versi 1.28, node pool dalam cluster dapat berada di versi 1.15, 1.16, atau 1.28. Bidang kontrol cluster pengguna tidak dapat diupgrade ke 1.29 hingga semua node pool berada di 1.28 atau 1.16.

1.16 dan yang lebih lama

Pada versi 1.16 dan yang lebih lama, panel kontrol cluster pengguna hanya boleh 1 versi minor lebih tinggi daripada node pool di cluster. Misalnya, jika panel kontrol cluster pengguna berada di versi 1.16, node pool dalam cluster dapat berada di versi 1.15 atau 1.16.

Secara umum, jika 1.n adalah versi minor dari panel kontrol cluster pengguna, kumpulan node dalam cluster dapat berada di 1.n atau 1.n-1. Cluster pengguna tidak dapat diupgrade ke versi minor berikutnya hingga semua node pool berada di versi minor yang sama dengan bidang kontrol.

Aturan versi untuk upgrade bidang kontrol cluster admin dan cluster pengguna

Aturan versi untuk cluster admin dan upgrade bidang kontrol cluster pengguna sama. Anda dapat mengupgrade langsung ke versi apa pun yang berada dalam rilis minor yang sama atau rilis minor berikutnya. Misalnya, Anda dapat mengupgrade dari 1.30.0 ke 1.30.1, atau dari 1.29.1 ke 1.30.0. Versi patch tidak memengaruhi aturan versi upgrade.

Jika mengupgrade ke versi yang bukan bagian dari rilis minor berikutnya, Anda harus mengupgrade melalui satu versi dari setiap rilis minor antara versi saat ini dan versi target. Melewati versi minor tidak didukung. Misalnya, jika ingin mengupgrade dari versi 1.28.x ke versi 1.30.x, Anda tidak dapat mengupgrade secara langsung. Anda harus mengupgrade terlebih dahulu dari 1.28.x ke 1.29.x, lalu mengupgrade ke 1.30.x.

Secara umum, hanya upgrade dari 1.n ke 1.n+1 yang didukung untuk upgrade cluster admin dan upgrade panel kontrol cluster pengguna.

Aturan versi untuk upgrade node pool

Pada versi 1.28 dan yang lebih baru, Anda dapat melewati satu versi minor saat mengupgrade kumpulan node di cluster pengguna. Misalnya, jika panel kontrol cluster pengguna berada di versi 1.30 dan node pool berada di versi 1.28, Anda dapat melewati versi 1.29 dan mengupgrade node pool langsung ke versi 1.30. Versi patch tidak memengaruhi aturan versi upgrade.

Secara umum, jika control plane cluster pengguna berada di 1.n, Anda dapat mengupgrade kumpulan node yang berada di 1.n-2 langsung ke 1.n. Melewati satu versi minor saat mengupgrade node pool dapat mengurangi jumlah waktu daripada melakukan dua upgrade node pool (untuk mengupgrade dari 1.n-2 ke 1.n-1, lalu ke 1.n). Hal ini adalah alasan lain mengapa Anda mungkin lebih memilih untuk mengupgrade panel kontrol cluster pengguna secara terpisah dari node pool yang berjalan di cluster pengguna.

Upgrade versi patch

Sebaiknya upgrade ke versi patch terbaru jika memungkinkan untuk memastikan cluster Anda memiliki perbaikan keamanan terbaru. Versi patch tidak memengaruhi penyimpangan versi dan aturan upgrade. Untuk versi minor tertentu, Anda dapat mengupgrade ke versi patch yang lebih tinggi. Artinya, Anda dapat mengupgrade cluster versi 1.30.X ke versi 1.30.Y selama Y lebih besar dari X. Misalnya, Anda dapat mengupgrade dari 1.29.0 ke 1.29.1 dan Anda dapat mengupgrade dari 1.29.1 ke 1.29.3.

Langkah selanjutnya

Tinjau Praktik terbaik upgrade dan buat rencana untuk mengupgrade cluster Anda.