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 memiliki satu versi minor lebih lama daripada cluster admin, Anda dapat mengupgrade cluster admin secara opsional.

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.

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 kumpulan node. 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 satu versi minor lebih lambat 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.

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.

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.

Kemiringan versi kumpulan node dan bidang kontrol cluster pengguna

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.

Aturan versi untuk upgrade cluster admin dan cluster pengguna

Aturan versi untuk mengupgrade cluster admin, bidang kontrol cluster pengguna, dan kumpulan node 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.16.0 ke 1.16.1, atau dari 1.15.1 ke 1.16.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.14.x ke versi 1.16.x, Anda tidak dapat mengupgrade secara langsung. Anda harus mengupgrade dari 1.14.x ke 1.15.x terlebih dahulu, lalu mengupgrade ke 1.16.x.

Secara umum, hanya upgrade dari 1.n ke 1.n+1 yang didukung untuk upgrade cluster admin dan upgrade 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.16.X ke versi 1.16.Y selama Y lebih besar dari X. Misalnya, Anda dapat melakukan upgrade dari 1.15.0 ke 1.15.1 dan dapat mengupgrade dari 1.15.1 ke 1.15.3.

Langkah selanjutnya

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