Ringkasan upgrade

Halaman ini memberikan ringkasan proses upgrade dan variasi versi informasi yang akan membantu Anda merencanakan urutan upgrade cluster di lingkungan multi-cluster. Untuk informasi perencanaan yang lebih rinci, menyertakan checklist untuk membantu Anda merencanakan upgrade. Lihat Praktik terbaik upgrade.

Urutan upgrade

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

  1. Mengupgrade workstation admin. Sebaiknya Anda melakukan ini walaupun Anda berencana untuk 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 jika perlu, mengupgrade bidang kontrol cluster pengguna secara terpisah dari node pada cluster pengguna. Untuk informasi tentang mengapa Anda mungkin ingin melakukan ini, lihat Upgrade cluster pengguna.

    Setelah semua kumpulan node dalam cluster pengguna memiliki versi yang sama dengan versi pengguna bidang kontrol cluster, cluster pengguna diupgrade sepenuhnya.

    Cluster admin tidak boleh menggunakan versi minor yang lebih baru dari pengguna mana pun cluster yang dikelolanya. Jika ada cluster pengguna yang sama sebagai cluster admin, maka Anda tidak dapat mengupgrade admin .

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

Kecondongan versi dan aturan versi untuk upgrade telah berubah pada 1.28 dan yang lebih baru. Untuk mengetahui informasi selengkapnya, lihat Kemiringan versi.

Upgrade cluster pengguna

Saat mengupgrade cluster pengguna, Anda dapat memilih untuk mengupgrade cluster pengguna sebagai keseluruhan (artinya Anda dapat mengupgrade bidang kontrol dan semua kumpulan node dalam cluster), atau Anda dapat mengupgrade bidang kontrol cluster pengguna dan membiarkan pada versi saat ini. Pendekatan yang Anda ambil bergantung pada beberapa seperti:

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

Misalnya, dalam lingkungan pengembangan, Anda mungkin ingin menyimpan proses sederhana dan mengupgrade bidang kontrol cluster pengguna dan semua kumpulan node. Tetapi dalam lingkungan produksi dengan masa pemeliharaan yang singkat, Anda mungkin ingin untuk meningkatkan hanya bidang kontrol saja karena hal itu membutuhkan lebih sedikit waktu dan pada bidang kontrol ketersediaan (HA), upgrade bidang kontrol tidak akan mengganggu yang dioptimalkan untuk workload pengguna. Bila bidang kontrol berada di versi 1.28 atau yang lebih tinggi, Anda dapat lewati versi minor saat mengupgrade kumpulan node.

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

Mengupgrade node pool secara selektif

Pada situasi tertentu, Anda mungkin ingin mengupgrade sebagian node, tetapi tidak semua gabungan dalam cluster pengguna. Misalnya, setelah meningkatkan bidang kontrol, Anda dapat mengupgrade kumpulan node yang memiliki traffic ringan atau menjalankan konfigurasi yang paling tidak penting sebagian besar workload standar dan berbasis cloud. Setelah Anda yakin bahwa beban kerja Anda berjalan dengan benar pada versi baru, Anda dapat mengupgrade kumpulan node tambahan, hingga akhirnya semua kumpulan node diupgrade.

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 cluster pengguna file konfigurasi guna menetapkan versi target untuk bidang kontrol cluster dan secara opsional, untuk dari kumpulan node. Anda menetapkan file ini pada command line untuk 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-alat standar ini adalah klien dari API On-Prem GKE, yang berjalan di infrastruktur Google Cloud.

    • Anda dapat menggunakan Terraform untuk upgrade hanya jika Anda yang membuat pengguna cluster 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. Pada versi 1.16 dan yang lebih baru, klaster yang dibuat menggunakan gkectl akan didaftarkan di GKE On-Prem API secara default. Sebagai cluster yang dibuat dalam versi sebelumnya, Anda dapat daftarkan cluster setelah dibuat.

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

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

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

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

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

  • Upgrade bidang kontrol dan satu atau beberapa kumpulan node sekaligus: Hanya gkectl yang mendukung kasus penggunaan ini.

Upgrade cluster admin

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

Kemiringan versi

Kemiringan versi adalah perbedaan versi minor di antara cluster admin dan cluster pengguna terkelola miliknya. Di bagian berikut, pengguna versi cluster mengacu pada versi bidang kontrol dan kumpulan node secara keseluruhan.

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

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

Kemiringan versi cluster admin dan pengguna

Cluster admin dapat mengelola cluster pengguna dengan versi yang berbeda-beda. Ini memungkinkan Anda mengupgrade fleet cluster pengguna sesuai jadwal yang berfungsi untuk organisasi Anda.

1.29 dan yang lebih tinggi

Kemiringan versi sama seperti pada 1.28. Pada 1.29, fitur ini ditransisikan pada tahap Ketersediaan Umum.

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

Secara umum, jika 1.n adalah versi minor cluster admin, maka pengguna cluster 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 pada setidaknya satu versi minor.

1,28

Pada versi 1.28, cluster pengguna dapat mencapai 2 versi minor yang lebih tinggi dari cluster adminnya. Misalnya, jika cluster admin memiliki resolusi 1,15, pengguna yang dikelola oleh cluster admin tersebut bisa di 1,15, 1,16, atau 1,28. Pengguna cluster di 1,28 tidak dapat ditingkatkan ke 1,29 sampai cluster admin diupgrade ke versi minimal 1.16.

1.16 dan yang lebih lama

Pada versi 1.16 dan yang lebih lama, cluster pengguna hanya boleh berupa 1 versi minor lebih tinggi daripada cluster adminnya. Misalnya, jika cluster admin berada di Pada tanggal 1.15, cluster pengguna yang dikelola oleh cluster admin tersebut dapat berada di 1,15 atau 1,16.

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

Kemiringan versi kumpulan node dan bidang kontrol cluster pengguna

1.29 dan yang lebih tinggi

Kemiringan versi sama seperti pada 1.28. Pada 1.29, fitur ini ditransisikan pada tahap Ketersediaan Umum.

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

Secara umum, jika 1.n adalah versi minor dari kontrol cluster pengguna bidang, 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 cluster pengguna pada 1,28, kumpulan node dalam cluster dapat berada di 1,15, 1,16, atau 1,28. Bidang kontrol cluster pengguna tidak dapat diupgrade ke versi 1.29 hingga semua versi kumpulan node berada di 1.28 atau 1.16.

1.16 dan yang lebih lama

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

Secara umum, jika 1.n adalah versi minor dari kontrol cluster pengguna bidang, kumpulan node dalam cluster dapat berada di 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 bidang kontrol cluster admin dan cluster pengguna

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

Jika Anda meningkatkan ke versi yang bukan bagian dari rilis kecil berikutnya, Anda harus melakukan upgrade ke satu versi dari setiap rilis minor antara versi dan versi target. Melewatkan versi minor tidak didukung. Sebagai misalnya, jika Anda ingin mengupgrade dari versi 1.28.x ke versi 1.30.x, Anda tidak dapat mengupgrade secara langsung. Anda harus terlebih dulu meningkatkan dari 1.28.x ke 1.29.x, dan kemudian tingkatkan ke 1,30.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 node dalam cluster pengguna. Misalnya, jika bidang kontrol cluster pengguna berada pada pada 1,30 dan kumpulan node berada pada 1,28, Anda dapat melewati 1.29 dan mengupgrade kumpulan node langsung ke 1.30. 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 secara langsung ke 1.n. Melewati satu anak di bawah umur saat mengupgrade kumpulan node dapat mengurangi jumlah waktu dua upgrade 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.

Upgrade versi patch

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

Langkah selanjutnya

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