Ringkasan upgrade

Halaman ini menyediakan ringkasan proses upgrade dan informasi distorsi versi yang akan membantu Anda merencanakan urutan upgrade cluster dalam lingkungan multi-cluster. Untuk mengetahui informasi perencanaan yang lebih mendetail, termasuk checklist untuk membantu Anda merencanakan upgrade, lihat Praktik terbaik upgrade.

Urutan upgrade

Upgrade yang diterapkan sejak versi 1.7 harus selalu mengikuti urutan upgrade tertentu:

  1. Upgrade workstation admin. Sebaiknya lakukan hal ini meskipun Anda berencana menggunakan Konsol Google Cloud, Google Cloud CLI, atau Terraform untuk mengupgrade cluster pengguna.

  2. Upgrade cluster pengguna, satu per satu. Pada versi 1.14 dan yang lebih baru, Anda juga dapat mengupgrade bidang kontrol cluster pengguna secara terpisah dari kumpulan node pada cluster pengguna. Untuk mengetahui informasi tentang alasan mengapa Anda perlu melakukannya, lihat Upgrade cluster pengguna.

    Setelah semua kumpulan node dalam 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.

  3. Jika semua cluster pengguna memiliki setidaknya satu versi minor yang lebih lambat dari cluster admin, Anda dapat memilih untuk mengupgrade cluster admin.

Kemiringan versi dan aturan versi untuk upgrade telah berubah di 1.28 dan yang lebih baru. Untuk informasi selengkapnya, lihat Kemiringan 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 kumpulan node dalam cluster), atau Anda dapat mengupgrade bidang kontrol cluster pengguna dan membiarkan kumpulan node tetap pada versi saat ini. Pendekatan yang Anda ambil bergantung pada beberapa faktor, seperti:

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

Misalnya, dalam lingkungan pengembangan, Anda mungkin ingin membuat prosesnya tetap sederhana dan mengupgrade bidang kontrol cluster pengguna dan semua node pool. Namun, dalam lingkungan produksi dengan masa pemeliharaan yang singkat, sebaiknya upgrade bidang kontrol saja karena prosesnya memerlukan waktu lebih sedikit dan dengan bidang kontrol ketersediaan tinggi (HA), upgrade bidang kontrol seharusnya tidak mengganggu beban kerja pengguna. Jika bidang kontrol berada pada versi 1.28 atau yang lebih tinggi, Anda dapat melewati versi minor saat mengupgrade kumpulan node.

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

Mengupgrade kumpulan node secara selektif

Dalam situasi tertentu, Anda mungkin ingin mengupgrade beberapa, tetapi tidak semua kumpulan node dalam cluster pengguna. Misalnya, setelah mengupgrade bidang kontrol, Anda dapat mengupgrade kumpulan node yang memiliki traffic ringan atau menjalankan beban kerja yang paling tidak penting. Setelah yakin bahwa beban kerja Anda berjalan dengan benar pada versi baru, Anda dapat mengupgrade kumpulan node tambahan hingga semua kumpulan node diupgrade.

Pilih 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, ubah file konfigurasi cluster pengguna guna menetapkan versi target untuk bidang kontrol cluster dan, secara opsional, untuk kumpulan node. Anda menentukan file ini pada command line untuk gkectl.

  • Konsol Google Cloud, Google Cloud CLI, atau Terraform, yang dapat Anda jalankan dari komputer mana pun yang memiliki konektivitas jaringan ke GKE On-Prem API. Alat standar ini adalah klien 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 didaftarkan di GKE On-Prem API agar dapat menggunakan konsol atau gcloud CLI untuk melakukan upgrade. Pada versi 1.16 dan yang lebih baru, cluster yang dibuat menggunakan gkectl akan didaftarkan di GKE On-Prem API secara default. Untuk cluster yang dibuat di versi sebelumnya, Anda dapat mendaftarkan cluster setelah dibuat.

      Meskipun memutuskan menggunakan gkectl untuk upgrade, Anda mungkin perlu mendaftarkan cluster di GKE On-Prem API untuk mendapatkan informasi tentang cluster tersebut menggunakan konsol atau gcloud CLI.

Alat yang digunakan bergantung pada rencana Anda untuk mengupgrade cluster pengguna:

  • Mengupgrade cluster secara keseluruhan: Anda dapat menggunakan gkectl, konsol Google Cloud, Google Cloud CLI, atau Terraform untuk mengupgrade cluster pengguna (bidang kontrol bersama dengan semua kumpulan node).

  • Hanya upgrade bidang kontrol: Anda dapat menggunakan gkectl, gcloud CLI, atau Terraform untuk mengupgrade bidang kontrol cluster pengguna secara terpisah dari node pool. Konsol tidak mendukung upgrade hanya bidang kontrol.

  • Mengupgrade kumpulan node secara selektif setelah bidang kontrol diupgrade: Anda dapat menggunakan gkectl, gcloud CLI, atau Terraform untuk mengupgrade kumpulan node tertentu setelah bidang kontrol diupgrade.

  • Upgrade bidang kontrol dan satu atau beberapa node pool secara bersamaan: Hanya gkectl yang mendukung kasus penggunaan ini.

Upgrade cluster admin

Jika bidang kontrol dan kumpulan node di semua cluster pengguna setidaknya memiliki satu versi minor lebih lambat dari cluster admin, Anda dapat memilih untuk mengupgrade cluster admin. Hanya gkectl yang mendukung upgrade cluster admin. Klien GKE On-Prem API tidak mendukung upgrade cluster admin.

Kemiringan versi

Kecenderungan 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 keseluruhan.

Selain itu, kemiringan versi adalah perbedaan dalam versi minor antara bidang kontrol cluster pengguna dan kumpulan node pada cluster pengguna.

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

Kecenderungan versi cluster admin dan pengguna

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

1,29 dan yang lebih tinggi

Kecenderungan versi sama dengan di 1.28. Pada versi 1.29, fitur ini ditransisikan ke tahap Ketersediaan Umum.

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

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 minimal satu versi minor.

1,28

Pada versi 1.28, cluster pengguna dapat memiliki hingga 2 versi minor yang lebih tinggi daripada cluster admin mereka. Misalnya, jika cluster admin adalah 1,15, cluster pengguna yang dikelola oleh cluster admin tersebut dapat berukuran 1,15, 1,16, atau 1,28. Cluster pengguna di 1.28 tidak dapat diupgrade ke 1.29 hingga cluster admin diupgrade ke versi minimal 1.16.

1.16 dan yang lebih rendah

Pada versi 1.16 dan yang lebih lama, cluster pengguna hanya boleh memiliki 1 versi minor yang lebih tinggi daripada cluster admin mereka. Misalnya, jika cluster admin adalah 1,15, cluster pengguna yang dikelola oleh cluster admin tersebut dapat memiliki 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 sampai cluster admin memiliki versi minor yang sama dengan cluster pengguna.

Bidang kontrol cluster pengguna dan kemiringan versi kumpulan node

1,29 dan yang lebih tinggi

Kecenderungan versi sama dengan di 1.28. Pada versi 1.29, fitur ini ditransisikan ke tahap Ketersediaan Umum.

Pada versi 1.29 dan yang lebih tinggi, bidang kontrol cluster pengguna dapat memiliki hingga 2 versi minor yang lebih tinggi daripada kumpulan node dalam cluster. Misalnya, jika bidang kontrol cluster pengguna adalah 1,29, kumpulan node dalam cluster dapat berukuran 1,16, 1,28, atau 1,29.

Secara umum, jika 1.n adalah versi minor dari bidang 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 kumpulan node berada di 1.n atau 1.n-1.

1,28

Pada versi 1.28, bidang kontrol cluster pengguna dapat memiliki hingga 2 versi minor lebih tinggi daripada kumpulan node dalam cluster. Misalnya, jika bidang kontrol cluster pengguna adalah 1,28, kumpulan node dalam cluster dapat berukuran 1,15, 1,16, atau 1,28. Bidang kontrol cluster pengguna tidak dapat diupgrade ke 1.29 sampai semua kumpulan node berada di 1.28 atau 1.16.

1.16 dan yang lebih rendah

Pada versi 1.16 dan yang lebih lama, bidang kontrol cluster pengguna hanya boleh memiliki 1 versi minor yang lebih tinggi daripada kumpulan node dalam cluster. Misalnya, jika bidang kontrol cluster pengguna adalah 1,16, kumpulan node dalam cluster dapat di 1,15 atau 1,16.

Secara umum, jika 1.n adalah versi minor dari bidang 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 sampai semua kumpulan node memiliki 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 langsung mengupgrade ke versi apa pun yang ada dalam rilis minor yang sama atau rilis minor berikutnya. Misalnya, Anda dapat mengupgrade dari 1.29.0 ke 1.29.1, atau dari 1.28.1 ke 1.29.0. Versi patch tidak memengaruhi aturan versi upgrade.

Jika melakukan upgrade 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.16.x ke versi 1.29.x, Anda tidak dapat mengupgrade secara langsung. Anda harus mengupgrade dari 1.16.x ke 1.28.x terlebih dahulu, lalu mengupgrade ke 1.29.x.

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

Aturan versi untuk upgrade kumpulan node

Pada versi 1.28 dan yang lebih baru, Anda dapat melewati satu versi minor saat mengupgrade kumpulan node dalam cluster pengguna. Misalnya, jika bidang kontrol cluster pengguna berada di 1,29 dan kumpulan node berada di 1,16, Anda dapat melewati 1,28 dan mengupgrade kumpulan node langsung ke 1,29. Versi patch tidak memengaruhi aturan versi upgrade.

Secara umum, jika bidang kontrol 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 upgrade dua kumpulan node (untuk mengupgrade dari 1.n-2 ke 1.n-1, lalu ke 1.n). Ini adalah alasan lain mengapa Anda lebih memilih untuk mengupgrade bidang kontrol cluster pengguna secara terpisah dari kumpulan node yang berjalan di cluster pengguna.

Melakukan patch upgrade versi

Sebaiknya upgrade ke versi patch terbaru jika memungkinkan untuk memastikan cluster Anda memiliki perbaikan keamanan terbaru. Versi patch tidak memengaruhi aturan upgrade dan kemiringan versi. Untuk versi minor tertentu, Anda dapat mengupgrade ke versi patch yang lebih tinggi. Artinya, Anda dapat mengupgrade cluster versi 1.29.X ke versi 1.29.Y selama Y lebih besar dari X. Misalnya, Anda dapat mengupgrade dari 1.28.0 ke 1.28.1 dan dapat mengupgrade dari 1.28.1 ke 1.28.3.

Langkah selanjutnya

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