Ringkasan upgrade

Halaman ini menyediakan ringkasan tentang proses upgrade dan informasi distorsi versi yang akan membantu Anda merencanakan urutan upgrade cluster di 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 langkah 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 dapat memilih untuk mengupgrade bidang kontrol cluster pengguna secara terpisah dari kumpulan node pada cluster pengguna. Untuk mengetahui informasi tentang alasan 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 dapat menggunakan versi minor yang lebih baru daripada cluster pengguna yang dikelolanya. Jika salah satu cluster pengguna Anda menggunakan versi minor yang sama dengan cluster admin, Anda tidak dapat mengupgrade cluster admin.

  3. Jika semua cluster pengguna setidaknya satu versi minor lebih lambat dari cluster admin, Anda dapat mengupgrade cluster admin secara opsional.

Kecondongan 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 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 agar prosesnya tetap sederhana dan mengupgrade bidang kontrol cluster pengguna dan semua kumpulan node. Namun, dalam lingkungan produksi dengan masa pemeliharaan yang singkat, sebaiknya hanya upgrade bidang kontrol saja karena prosesnya akan memakan waktu lebih sedikit dan dengan bidang kontrol ketersediaan tinggi (HA), upgrade bidang kontrol seharusnya tidak mengganggu beban kerja pengguna. Jika bidang kontrol berada di 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 kumpulan node dalam cluster pengguna, tetapi tidak semuanya. 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.

Memilih alat untuk mengupgrade cluster pengguna

GKE di VMware menyediakan pilihan alat untuk mengupgrade cluster pengguna.

  • Alat command line gkectl, yang Anda jalankan di workstation admin. Sebelum mengupgrade, 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 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 dibuat menggunakan gkectl, cluster tersebut harus didaftarkan di GKE On-Prem API agar dapat menggunakan konsol atau gcloud CLI untuk upgrade. Pada versi 1.16 dan yang lebih baru, cluster yang dibuat menggunakan gkectl didaftarkan di GKE On-Prem API secara default. Untuk cluster yang dibuat di versi sebelumnya, Anda dapat mendaftarkan cluster setelah cluster dibuat.

      Meskipun memutuskan menggunakan gkectl untuk upgrade, Anda mungkin perlu mendaftarkan cluster di GKE On-Prem API untuk mendapatkan informasi mengenai cluster 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 kumpulan node secara bersamaan: Hanya gkectl yang mendukung kasus penggunaan ini.

Upgrade cluster admin

Jika bidang kontrol dan kumpulan node di semua cluster pengguna setidaknya satu versi minor lebih lama daripada 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.

Versi condong

Kecondongan versi adalah perbedaan dalam 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 kecondongan versi dan aturan versi yang didukung untuk upgrade dapat membantu Anda merencanakan urutan upgrade cluster.

Kecondongan versi admin dan cluster pengguna

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

1.16 dan versi sebelumnya

Pada versi 1.16 dan yang lebih lama, cluster pengguna hanya dapat memiliki 1 versi minor yang lebih baru dari cluster adminnya. Misalnya, jika cluster admin menggunakan versi 1.15, cluster pengguna yang dikelola oleh cluster admin tersebut dapat menggunakan 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 pada versi minor yang sama dengan cluster pengguna.

1.28 dan yang lebih baru

Pada versi 1.28 dan yang lebih baru, cluster pengguna dapat memiliki hingga 2 versi minor yang lebih baru dari cluster admin mereka. Misalnya, jika cluster admin menggunakan 1.15, cluster pengguna yang dikelola oleh cluster admin tersebut dapat menggunakan versi 1.15, 1.16, atau 1.28 (versi 1.28 adalah versi yang mengikuti versi 1.16 dalam penyelarasan versi dengan GKE). 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.

Kemiringan versi kumpulan node dan bidang kontrol cluster pengguna

1.16 dan versi sebelumnya

Pada versi 1.16 dan yang lebih lama, bidang kontrol cluster pengguna hanya dapat memiliki 1 versi minor yang lebih baru dari kumpulan node dalam cluster. Misalnya, jika bidang kontrol cluster pengguna adalah 1,16, kumpulan node dalam cluster dapat berada di versi 1,15 atau 1,16. Secara umum, jika 1.n adalah versi minor bidang kontrol cluster pengguna, kumpulan node dalam cluster dapat berupa 1.n atau 1.n-1.

Cluster pengguna tidak dapat diupgrade ke versi minor berikutnya hingga semua kumpulan node berada di versi minor yang sama dengan bidang kontrol.

1.28 dan yang lebih baru

Pada versi 1.28 dan yang lebih baru, bidang kontrol cluster pengguna dapat memiliki hingga 2 versi minor yang lebih baru dari kumpulan node dalam cluster. Misalnya, jika bidang kontrol cluster pengguna berada di 1,28, kumpulan node dalam cluster tersebut dapat berada di 1,15, 1,16, atau 1,28. Secara umum, jika 1.n adalah versi minor 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.

Aturan versi untuk cluster admin dan upgrade bidang kontrol 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.28.0 ke 1.28.1, atau dari 1.16.1 ke 1.28.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.15.x ke versi 1.28.x, Anda tidak dapat mengupgrade secara langsung. Anda harus mengupgrade dari 1.15.x ke 1.16.x terlebih dahulu, lalu mengupgrade ke 1.28.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 di cluster pengguna. Misalnya, jika bidang kontrol cluster pengguna berada di 1,28 dan kumpulan node berada di 1,15, Anda dapat melewati 1,16 dan mengupgrade kumpulan node langsung ke versi 1,28. 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. Melewatkan satu versi minor saat mengupgrade kumpulan node 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 mungkin 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.28.X ke versi 1.28.Y selama Y lebih besar dari X. Misalnya, Anda dapat melakukan upgrade dari 1.16.0 ke 1.16.1 dan dapat mengupgrade dari 1.16.1 ke 1.16.3.

Langkah selanjutnya

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