Produk yang dijelaskan dalam dokumentasi ini, GKE di AWS, kini dalam mode pemeliharaan dan akan dihentikan pada 17 Maret 2027.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Tentang update lonjakan

Dokumen ini memberikan ringkasan singkat tentang update berkelanjutan standar, lalu membahas detail tentang update lonjakan, yang merupakan jenis update berkelanjutan khusus. Dibandingkan dengan update berkelanjutan standar, update lonjakan memungkinkan Anda mengonfigurasi kecepatan update. Update lonjakan juga memungkinkan Anda mengontrol seberapa mengganggu update terhadap workload Anda.

Untuk mengetahui informasi tentang cara mengaktifkan dan mengonfigurasi update lonjakan untuk GKE di AWS, lihat Mengonfigurasi update lonjakan node pool.

Cara kerja update berkelanjutan standar

Beberapa update ke node pool, seperti saat Anda mengubah anotasi node pool, tidak memerlukan node untuk dimulai ulang, sehingga tidak memicu update berkelanjutan. Jika GKE di AWS dapat menerapkan perubahan ke node pool tanpa harus memulai ulang atau membuat ulang resource, GKE di AWS akan melakukannya untuk mencegah gangguan.

Namun, sebagian besar update ke node pool di GKE di AWS biasanya melibatkan penghentian node yang ada, dan meluncurkan node baru dengan setelan yang diupdate. Proses penghentian node yang ada dapat mengganggu workload.

Secara default, GKE di AWS melakukan update berkelanjutan standar. Metode ini mengupdate node satu per satu, dan diganti menggunakan pendekatan "hentikan sebelum buat": node dihentikan terlebih dahulu, lalu node baru yang diupdate diluncurkan. Hal ini meminimalkan gangguan karena hanya satu node yang dihentikan dan diganti pada waktu tertentu.

Berikut adalah langkah-langkah yang dilakukan GKE di AWS selama update berkelanjutan standar:

Memilih node dari node pool dan menandai node sebagai tidak tersedia untuk memastikan tidak ada Pod baru yang dimulai di node tersebut—tindakan ini disebut cordoning.
Memindahkan Pod aktif dari node yang dikarantina ke node lain yang tersedia dalam cluster. Jika node lain memiliki kapasitas yang cukup, node tersebut akan mengakomodasi Pod yang dikeluarkan. Jika tidak, autoscaler cluster, yang tetap aktif selama update berkelanjutan standar, akan memulai peningkatan skala dan menyediakan node tambahan untuk memastikan ada kapasitas yang cukup untuk menjadwalkan Pod yang dikeluarkan. Untuk mengetahui informasi tentang langkah-langkah yang diambil untuk melindungi workload selama proses ini, lihat Perlindungan workload selama pengubahan ukuran.
Menghentikan node yang dikarantina.
Mengganti node yang dikarantina dengan node baru yang memiliki setelan yang diupdate.
Melakukan health check pada node yang baru beroperasi. Jika node pool gagal dalam health check, node pool akan ditandai dengan status DEGRADED. Status ini dapat dilihat dengan menjalankan perintah gcloud container aws node-pools describe. Jika node pool ditandai sebagai DEGRADED, Pod baru mungkin tidak dijadwalkan pada node dalam pool tersebut.
Melanjutkan update, node demi node, hingga semua node dalam pool telah diupdate.

Cara kerja update lonjakan

Di GKE di AWS, metode berkelanjutan standar mengupdate node satu per satu. Update lonjakan, yang merupakan bentuk update berkelanjutan, memungkinkan Anda mengupdate beberapa node secara bersamaan. Oleh karena itu, update lonjakan lebih cepat daripada update berkelanjutan standar. Namun, mengupdate beberapa node secara bersamaan dapat mengganggu workload. Untuk mengatasinya, update lonjakan menyediakan opsi untuk memodulasi tingkat gangguan pada workload Anda.

Cara lain update lonjakan dapat berbeda dari update berkelanjutan standar adalah cara node diganti. Update berkelanjutan standar mengganti node menggunakan strategi "hentikan sebelum buat". Bergantung pada setelan yang Anda pilih, update lonjakan dapat menggunakan strategi "buat sebelum hentikan", strategi "hentikan sebelum buat", atau bahkan kombinasi keduanya.

Autoscaler cluster memainkan peran yang lebih penting dalam update lonjakan daripada dalam update berkelanjutan standar. Itulah sebabnya autoscaler cluster menonjol dalam daftar tindakan berikut yang dilakukan GKE di AWS selama update lonjakan:

Pembuatan grup autoscaling baru: GKE di AWS menyediakan node baru dengan modifikasi yang ditentukan oleh perintah update, dan menetapkan node baru ini ke grup autoscaling (ASG) AWS baru.
Perilaku autoscaler cluster: Saat update lonjakan dimulai, autoscaler cluster diaktifkan untuk grup autoscaling baru. Autoscaler cluster untuk grup autoscaling asli dinonaktifkan. Hal ini memastikan bahwa setiap operasi penskalaan hanya menargetkan grup baru.
Penggantian node: Bergantung pada parameter update lonjakan, strategi penggantian node yang berbeda digunakan:
- "buat sebelum hentikan": strategi ini diaktifkan saat parameter max-surge-update ditetapkan ke nilai yang lebih besar dari nol. Strategi ini membuat node baru di ASG baru sebelum menghentikan node lama di ASG asli, yang bertujuan untuk meminimalkan gangguan layanan.
- "hentikan sebelum buat": metode ini dipicu saat parameter max-surge-update ditetapkan ke nol dan parameter max-unavailable-update memiliki nilai yang lebih besar dari nol. Node dari ASG asli dihentikan terlebih dahulu, diikuti dengan pembuatan node baru di ASG baru.
Penyesuaian ukuran node pool: Selama update, ukuran node pool (yaitu, jumlah node di ASG lama dan baru) mungkin berfluktuasi di atas atau di bawah jumlah node asli yang ada di node pool sebelum update dimulai. Secara khusus, GKE di AWS bertujuan untuk mempertahankan jumlah node total dalam rentang (original_count - max-unavailable-update) hingga (original_count + max-surge-update). Pada akhirnya, node di ASG lama (original_count) diganti dengan node yang diupdate di ASG baru. Autoscaler cluster mungkin meluncurkan lebih banyak node di ASG baru jika mendeteksi bahwa Pod tidak dapat dijadwalkan, tetapi tetap berada dalam batas yang ditentukan oleh min-nodes dan max-nodes.

Contoh untuk mengilustrasikan proses

Untuk lebih memahami cara kerja update lonjakan, perhatikan contoh berikut. Misalkan Anda memiliki node pool dengan 5 node, dan Anda menjalankan perintah berikut:

  gcloud container aws node-pools update production-node-pool
      --cluster my-cluster \
      --location us-west1 \
      --max-surge-update 2 \
      --max-unavailable-update 1 \
      --node-version 1.27.6-gke.700

Dalam contoh ini, max-surge-update ditetapkan ke 2, max-unavailable-update ditetapkan ke 1, dan Anda memberikan versi node pool baru (yaitu, Anda mengubah versi GKE yang berjalan di node dalam node pool).

Menjalankan perintah ini akan memicu update lonjakan dan GKE di AWS akan melakukan tindakan berikut:

Membuat 2 node tambahan karena nilai max-surge-update sama dengan 2.
Menetapkan 2 node tambahan ini ke grup autoscaling AWS baru.
Menghapus node dari grup autoscaling asli setelah node baru ini beroperasi. GKE di AWS menurunkan hingga 3 node (nilai gabungan max-surge-update dan max-unavailable-update), tetapi memastikan bahwa paling banyak hanya satu node yang tidak tersedia kapan saja (karena nilai max-unavailable-update adalah 1).
Ulangi langkah-langkah ini hingga semua node di node pool telah diupdate ke versi GKE baru.

Selama update ini, node pool berisi antara 4 hingga 7 node operasional.

Hal yang perlu dipertimbangkan sebelum menjalankan update lonjakan

Sebelum menjalankan update lonjakan, perhatikan hal berikut:

Instance tambahan yang dibuat sebagai bagian dari langkah lonjakan ini berpotensi melebihi batas kuota instance AWS Anda. Jika Anda tidak memiliki kuota yang cukup dan instance tambahan ini tidak dapat disediakan, update mungkin akan gagal.
Jika max-unavailable-update ditetapkan ke 0, gangguan pada workload masih dapat terjadi saat Pod dikeluarkan dan dijadwalkan ulang ke node yang lebih baru.
Jumlah maksimum node yang dapat diupdate secara bersamaan sama dengan jumlah max-surge-update dan max-unavailable-update, dan dibatasi hingga 20.

Memilih setelan lonjakan yang tepat untuk kebutuhan Anda

Meskipun update berkelanjutan standar sering menggunakan pendekatan "hentikan sebelum buat", update lonjakan memberikan lebih banyak fleksibilitas. Bergantung pada konfigurasi, update lonjakan dapat mengikuti strategi "buat sebelum hentikan", strategi "hentikan sebelum buat", atau kombinasi keduanya. Bagian ini menjelaskan berbagai konfigurasi untuk membantu Anda memilih pendekatan terbaik untuk workload Anda.

Tabel berikut menunjukkan tiga contoh setelan, dan menyoroti dampaknya terhadap kecepatan update dan potensi gangguan pada workload Anda:

Nama	Deskripsi	Konfigurasi
Setelan seimbang (default)	Seimbang, lebih lambat tetapi paling tidak mengganggu.	maxSurge=1, maxUnavailable=0
Update cepat tanpa resource tambahan	Cepat, tanpa resource lonjakan, paling mengganggu.	maxSurge=0, maxUnavailable=20
Update cepat yang tidak terlalu mengganggu	Cepat, resource lonjakan terbanyak dan tidak terlalu mengganggu.	maxSurge=20, maxUnavailable=0

Setiap setelan dalam tabel dijelaskan di bagian berikut.

Setelan seimbang (default)

Cara paling mudah untuk menggunakan update lonjakan adalah dengan konfigurasi default max-surge-update=1 dan max-unavailable-update=0. Konfigurasi ini hanya menambahkan 1 node lonjakan ke node pool selama update, dan hanya 1 node yang diupdate pada satu waktu, mengikuti pendekatan "buat sebelum hentikan". Dibandingkan dengan update berkelanjutan non-lonjakan standar, yang setara dengan (max-surge-update=0, max-unavailable-update=1), metode ini tidak terlalu mengganggu, mempercepat mulai ulang Pod selama update, dan lebih konservatif dalam progresnya.

Perlu diperhatikan bahwa mengadopsi setelan seimbang dapat menyebabkan biaya tambahan karena node lonjakan sementara yang ditambahkan selama update. Node tambahan ini dikenai biaya saat aktif, sehingga sedikit meningkatkan pengeluaran keseluruhan dibandingkan dengan metode tanpa node lonjakan.

Update cepat tanpa resource tambahan

Untuk workload yang dapat mentolerir gangguan, pendekatan update yang lebih cepat mungkin cocok. Mengonfigurasi max-surge-update=0 dan max-unavailable-update=20 akan mencapai hal ini. Dengan konfigurasi ini, 20 node dapat diupdate secara bersamaan tanpa menambahkan node lonjakan. Metode update ini mengikuti pendekatan "hentikan sebelum buat". Karena tidak ada node lonjakan tambahan yang diperkenalkan selama proses, metode ini juga paling hemat biaya, sehingga menghindari pengeluaran tambahan yang terkait dengan node sementara.

Update cepat yang tidak terlalu mengganggu

Jika workload Anda sensitif terhadap gangguan, Anda dapat meningkatkan kecepatan update dengan setelan berikut: max-surge-update=20 dan max-unavailable-update=0. Konfigurasi ini mengupdate 20 node secara paralel dalam mode "buat sebelum hentikan".

Namun, kecepatan update secara keseluruhan dapat dibatasi jika Anda telah menyiapkan PodDisruptionBudgets (PDB) untuk workload Anda. Hal ini karena PDB membatasi jumlah Pod yang dapat dikosongkan pada waktu tertentu. Meskipun konfigurasi PDB dapat bervariasi, jika Anda membuat PDB dengan maxUnavailable sama dengan 1 untuk satu atau beberapa workload yang berjalan di node pool, hanya satu Pod dari workload tersebut yang dapat dikeluarkan pada satu waktu. Membatasi paralelisme dari seluruh update.

Ingatlah bahwa memulai beberapa node lonjakan pada awal proses update dapat menyebabkan peningkatan biaya sementara, terutama jika dibandingkan dengan konfigurasi yang tidak menambahkan node tambahan atau menambahkan lebih sedikit node selama update.

Langkah berikutnya