Upgrade cluster autopilot

Halaman ini membahas cara kerja upgrade otomatis pada cluster Google Kubernetes Engine (GKE) Autopilot, termasuk link ke informasi lebih lanjut tentang tugas dan setelan terkait. Anda dapat menggunakan informasi ini untuk terus mengupdate cluster Anda demi stabilitas dan keamanan dengan gangguan minimal pada workload.

Untuk ringkasan umum upgrade cluster, lihat Tentang upgrade cluster GKE. Untuk mengetahui informasi tentang cara kerja upgrade cluster khusus untuk Standard, lihat Upgrade cluster Standard.

Upgrade node dan bidang kontrol otomatis

Upgrade otomatis diaktifkan di semua cluster Autopilot. GKE memulai upgrade otomatis saat versi GKE dipilih untuk upgrade otomatis, mengamati upgrade otomatis di semua cluster, dan melakukan intervensi jika terjadi masalah seperti node tidak responsif. Anda tidak dapat menonaktifkan upgrade otomatis, tetapi Anda dapat mengontrol pengaturan waktunya dengan masa dan pengecualian pemeliharaan.

Untuk mengupgrade cluster, GKE mengupdate versi yang dijalankan panel kontrol dan node. Cluster diupgrade ke versi minor yang lebih baru (misalnya 1.24 ke 1.25) atau versi patch yang lebih baru (misalnya 1.24.2-gke.100 ke 1.24.5-gke.200). Untuk informasi selengkapnya, silakan melihat Pembuatan versi dan dukungan GKE.

Semua cluster Autopilot terdaftar di saluran rilis, sehingga GKE otomatis mengupgrade bidang kontrol dan node untuk menjalankan versi GKE yang sama.

GKE mengupgrade bidang kontrol cluster sebelum mengupgrade node.

Upgrade bidang kontrol otomatis

Semua cluster Autopilot merupakan cluster regional. Cluster regional memiliki beberapa replika bidang kontrol, dan hanya satu replika yang diupgrade pada satu waktu, dalam urutan yang tidak ditentukan. Hal ini memastikan bahwa cluster tetap sangat tersedia selama upgrade otomatis. Setiap replika bidang kontrol hanya tidak tersedia saat upgrade sedang berlangsung.

Jika Anda mengonfigurasi masa atau pengecualian pemeliharaan, GKE akan mengikuti konfigurasi tersebut jika memungkinkan.

GKE tidak dapat membuat node baru saat upgrade bidang kontrol sedang berlangsung. Jika men-deploy Pod yang memerlukan jenis node baru saat upgrade bidang kontrol sedang berlangsung, Anda mungkin mengalami penundaan hingga upgrade bidang kontrol selesai.

Upgrade node otomatis

Setelah GKE mengupgrade bidang kontrol cluster Autopilot Anda, GKE mengupgrade node tersebut ke versi GKE yang sama.

Dalam mode Autopilot, GKE mengelompokkan node yang memiliki karakteristik serupa. GKE menggunakan upgrade lonjakan untuk node Autopilot, yang mengupgrade hingga 20 node dalam satu grup secara bersamaan. Jumlah persis node yang diupgrade secara bersamaan bervariasi guna memastikan dipertahankannya ketersediaan tinggi untuk node dan workload.

Upgrade node mungkin memerlukan waktu beberapa jam, bergantung pada jumlah node dan konfigurasi workload yang berjalan di node. Misalnya, konfigurasi berikut dapat memperlama proses upgrade:

Jika Anda mengonfigurasi masa atau pengecualian pemeliharaan, GKE akan mengikuti konfigurasi tersebut jika memungkinkan.

Saat GKE mengupgrade node, langkah-langkah berikut akan terjadi:

  1. GKE membuat node lonjakan baru dengan versi GKE baru dan menunggu hingga node lonjakan terdaftar ke bidang kontrol.
  2. GKE memilih node yang ada, yaitu node target, untuk diupgrade.
  3. GKE menutup akses ke node target, sehingga Pod baru tidak akan ditempatkan di node target.
  4. GKE mengosongkan node target, sehingga Pod yang ada akan dikeluarkan dari node target.

  5. GKE menjadwalkan ulang Pod yang dikelola oleh pengontrol workload ke node lain yang tersedia. Pod yang tidak dapat dijadwalkan ulang akan tetap berstatus PENDING hingga GKE dapat menjadwalkan ulang Pod tersebut.

  6. GKE menghapus node target.

Jika sejumlah besar upgrade otomatis ke versi GKE tertentu menimbulkan node yang tidak responsif di seluruh fleet GKE, GKE akan menghentikan upgrade ke versi tersebut selagi kami menyelidiki masalahnya.

Pemilihan versi yang akan diupgrade otomatis

GKE merilis versi minor baru secara teratur, tetapi versi yang dirilis tidak langsung dipilih untuk upgrade otomatis. Agar memenuhi syarat sebagai target upgrade otomatis, versi GKE harus mengakumulasi cukup penggunaan untuk membuktikan stabilitasnya dari waktu ke waktu.

Google Cloud kemudian memilih versi tersebut sebagai target upgrade otomatis untuk cluster yang menjalankan subset tertentu dari versi GKE lama. Misalnya, segera setelah versi minor baru tersedia, versi minor terlama yang tersedia biasanya menjadi tidak didukung. GKE mengupgrade cluster yang menjalankan versi minor yang tidak didukung ke versi target upgrade otomatis.

GKE mengumumkan versi target upgrade otomatis baru dalam catatan rilis. Terkadang, sebuah versi dipilih untuk upgrade otomatis bidang kontrol dan upgrade otomatis node dalam minggu yang berbeda. GKE otomatis melakukan upgrade ke rilis patch baru dalam versi minor (seperti v1.21.x). Untuk mendapatkan target upgrade otomatis untuk cluster tertentu, lihat Mendapatkan informasi tentang upgrade cluster (Pratinjau).

Untuk informasi tentang siklus proses versi dan skema pembuatan versi, lihat Pembuatan versi dan dukungan GKE.

Faktor yang memengaruhi waktu peluncuran versi

Untuk memastikan stabilitas dan keandalan cluster pada versi baru, GKE mengikuti praktik tertentu selama peluncuran versi.

Praktik ini mencakup, tetapi tidak terbatas pada:

  • GKE secara bertahap meluncurkan perubahan di seluruh region dan zona Google Cloud.
  • GKE secara bertahap meluncurkan versi patch di seluruh saluran rilis. Patch diberi waktu berdiam di saluran rilis Cepat, lalu saluran rilis Reguler, sebelum dipromosikan ke saluran rilis Stabil setelah patch tersebut mengakumulasi penggunaan dan terus menunjukkan stabilitas. Jika ditemukan masalah pada versi patch selama waktu berdiam di sebuah saluran rilis, versi tersebut tidak akan dipromosikan ke saluran berikutnya dan masalah akan diperbaiki pada versi patch yang lebih baru.
  • GKE meluncurkan versi minor secara bertahap, dengan mengikuti proses berdiam yang mirip dengan versi patch. Versi minor memiliki periode berdiam lebih lama karena versi ini menyebabkan perubahan yang lebih signifikan.
  • GKE dapat menunda upgrade otomatis jika versi baru memengaruhi sekelompok cluster. Misalnya, GKE akan menjeda upgrade otomatis untuk cluster yang terekspos ke API yang tidak digunakan lagi dan fitur yang akan dihapus dalam versi minor berikutnya.
  • GKE mungkin menunda peluncuran versi baru selama waktu puncak (misalnya hari libur besar) untuk memastikan kelangsungan bisnis.

Mengonfigurasi kapan upgrade otomatis dapat terjadi

Secara default, upgrade otomatis dapat terjadi kapan saja. Upgrade otomatis tidak terlalu mengganggu, terutama untuk cluster Autopilot. Namun, beberapa workload mungkin memerlukan kontrol yang lebih terperinci. Anda dapat mengonfigurasi masa dan pengecualian pemeliharaan untuk mengelola kapan upgrade otomatis dapat dan tidak dapat terjadi.

Jika Anda mengonfigurasi masa dan pengecualian pemeliharaan, upgrade tidak akan terjadi sebelum waktu saat ini berada dalam masa pemeliharaan. Jika masa pemeliharaan berakhir sebelum upgrade selesai, GKE akan mencoba menjeda upgrade. GKE akan melanjutkan upgrade pada masa pemeliharaan berikutnya yang tersedia.

Mengupgrade cluster Autopilot secara manual

Anda dapat mengupgrade versi GKE bidang kontrol cluster Autopilot secara manual. GKE otomatis mengupgrade node Anda agar sesuai dengan versi bidang kontrol sesegera mungkin, bergantung pada ketersediaan pemeliharaan. Untuk mendapatkan petunjuk, lihat Mengupgrade bidang kontrol secara manual. Anda tidak dapat mengelola versi node untuk cluster Autopilot secara manual.

Anda dapat mengupgrade versi bidang kontrol ke versi minor atau patch yang didukung di saluran rilis yang sama, atau ke versi patch dari versi minor yang sama dengan cluster Anda di saluran rilis berbeda.

Misalnya, pertimbangkan cluster Autopilot yang menjalankan GKE versi 1.22.8-gke.202 di saluran rilis Reguler. Perilaku berikut berlaku:

  • Anda dapat melakukan upgrade ke versi apa saja di saluran rilis Reguler.
  • Anda dapat melakukan upgrade ke patch versi 1.22 apa saja di saluran rilis Cepat.

Untuk informasi selengkapnya tentang cara melakukan upgrade di luar channel, baca Menjalankan versi patch dari channel yang lebih baru.

Upgrade lonjakan

Cluster autopilot menggunakan upgrade lonjakan untuk mengupgrade banyak node secara bersamaan. Upgrade lonjakan memungkinkan GKE mengurangi gangguan upgrade versi pada workload yang sedang berjalan dengan mempertahankan kapasitas komputasi yang cukup untuk workload yang sedang berjalan. Autopilot mengelola jumlah node lonjakan yang ditambahkan ke cluster selama upgrade. Jumlah ini bervariasi sesuai ukuran total cluster. GKE juga mengelola jumlah total node target yang dapat tidak tersedia secara bersamaan selama upgrade.

Jumlah node lonjakan baru dan node target yang tidak tersedia bervariasi untuk memastikan bahwa cluster Anda selalu memiliki kapasitas komputasi yang cukup untuk semua workload yang berjalan. Anda mungkin mengalami gangguan kecil saat GKE memigrasikan workload dari node target ke node lonjakan selama upgrade.

Untuk penjelasan tentang bagaimana upgrade lonjakan terjadi, baca Upgrade node otomatis.

Persyaratan kuota untuk upgrade lonjakan

Tidak seperti pembuatan ulang node, upgrade surge memerlukan resource Compute Engine tambahan. Alokasi resource bergantung pada kuota Compute Engine Anda yang tersedia. Bergantung pada konfigurasi Anda, kuota ini dapat membatasi jumlah upgrade paralel atau bahkan menyebabkan kegagalan upgrade. Sebagai praktik yang baik untuk menghindari masalah penskalaan, dan agar upgrade menjadi lebih mudah diprediksi, pastikan kuota instance Compute Engine Anda tidak melebihi 90%.

Untuk informasi selengkapnya tentang kuota, lihat Memastikan resource untuk upgrade node.

Menerima notifikasi upgrade

GKE memublikasikan notifikasi upgrade ke Pub/Sub, sehingga Anda memiliki saluran untuk menerima informasi yang relevan dari GKE tentang cluster Anda.

Untuk informasi selengkapnya, lihat Menerima notifikasi cluster.

Upgrade komponen

GKE menjalankan workload sistem di node pekerja untuk mendukung kemampuan tertentu untuk cluster. Misalnya, workload sistem gke-metadata-server mendukung Workload Identity Federation for GKE. GKE bertanggung jawab atas kondisi workload ini. Untuk mempelajari komponen ini lebih lanjut, lihat dokumentasi untuk kemampuan terkait.

Saat fitur atau perbaikan baru tersedia untuk komponen, GKE akan menunjukkan versi patch tempat fitur atau perbaikan tersebut disertakan. Untuk mendapatkan versi terbaru komponen, lihat dokumentasi terkait atau catatan rilis untuk mendapatkan petunjuk tentang cara mengupgrade panel kontrol atau node ke versi yang sesuai.

Langkah selanjutnya