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

Halaman ini diterjemahkan oleh Cloud Translation API.

Tentang update lonjakan

Dokumen ini memberikan ringkasan singkat tentang update bertahap standar, lalu membahas secara mendetail update lonjakan, yang merupakan jenis update bertahap khusus. Dibandingkan dengan update berkelanjutan standar, update lonjakan memungkinkan Anda mengonfigurasi kecepatan update. Update lonjakan juga memungkinkan Anda melakukan beberapa kontrol atas seberapa mengganggu update pada workload Anda.

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

Cara kerja update berkelanjutan standar

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

Namun, sebagian besar update pada 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 on AWS melakukan update berkelanjutan standar. Metode ini memperbarui node satu per satu, dan diganti menggunakan pendekatan "akhiri sebelum buat": node dihentikan terlebih dahulu, lalu node baru yang diperbarui diluncurkan. Hal ini meminimalkan gangguan karena hanya satu node yang dihentikan dan diganti pada waktu tertentu.

Berikut adalah langkah-langkah yang dilakukan GKE on 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 mengisolasi.
Memindahkan Pod aktif dari node yang dikarantina ke node lain yang tersedia dalam cluster. Jika node lain memiliki kapasitas yang cukup, node tersebut akan menampung Pod yang dikeluarkan. Jika tidak, penskalaan otomatis cluster, yang tetap aktif selama update bertahap standar, akan memulai penskalaan dan menyediakan node tambahan untuk memastikan ada kapasitas yang cukup untuk menjadwalkan Pod yang dikeluarkan. Untuk mengetahui informasi tentang tindakan yang diambil untuk melindungi workload selama proses ini, lihat Perlindungan workload selama pengubahan ukuran.
Menghentikan node yang ditandai sebagai tidak dapat dijadwalkan.
Mengganti node yang dikarantina dengan node baru yang memiliki setelan yang diperbarui.
Melakukan health check pada node yang baru beroperasi. Jika kumpulan node gagal dalam health check, kumpulan node tersebut 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 di node dalam pool tersebut.
Terus mengupdate, node demi node, hingga semua node dalam pool telah diupdate.

Cara kerja update lonjakan

Di GKE on AWS, metode upgrade 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 bertahap standar. Namun, mengupdate beberapa node secara bersamaan dapat mengganggu workload. Untuk memitigasi hal ini, upgrade lonjakan memberikan opsi untuk memodulasi tingkat gangguan pada workload Anda.

Cara lain pembaruan lonjakan dapat berbeda dari pembaruan berkelanjutan standar adalah cara node diganti. Update bertahap standar mengganti node menggunakan strategi "akhiri 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 bertahap standar, itulah sebabnya autoscaler cluster ditampilkan secara mencolok dalam daftar tindakan berikut yang dilakukan GKE di AWS selama update lonjakan:

Pembuatan grup penskalaan otomatis baru: GKE di AWS menyediakan node baru dengan modifikasi yang ditentukan oleh perintah update, dan menetapkan node baru ini ke grup penskalaan otomatis (ASG) AWS baru.
Perilaku autoscaler cluster: Saat update lonjakan dimulai, autoscaler cluster diaktifkan untuk grup penskalaan otomatis baru. Cluster autoscaler untuk grup penskalaan otomatis asli dinonaktifkan. Hal ini memastikan bahwa setiap operasi penskalaan hanya menargetkan grup baru.
Penggantian node: Bergantung pada parameter update lonjakan, berbagai strategi untuk penggantian node digunakan:
- "create before terminate": strategi ini diaktifkan saat parameter max-surge-update ditetapkan ke nilai yang lebih besar dari nol. Proses ini akan membuat node baru di ASG baru sebelum menghentikan node lama di ASG asli, dengan tujuan untuk meminimalkan gangguan layanan.
- "terminate before create": 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 dalam ASG lama dan baru) dapat 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 total node 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 diperbarui di ASG baru. Autoscaler cluster dapat 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 menggambarkan prosesnya

Untuk lebih memahami cara kerja pembaruan lonjakan, perhatikan contoh berikut. Misalnya, 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 disetel ke 2, max-unavailable-update disetel 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 penskalaan otomatis AWS baru.
Menghapus node dari grup penskalaan otomatis 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 dalam satu waktu (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-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 gagal.
Jika max-unavailable-update disetel 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.

Pilih setelan lonjakan yang tepat untuk kebutuhan Anda

Meskipun update berkelanjutan standar sering kali menggunakan pendekatan "akhiri sebelum buat", update lonjakan memperkenalkan lebih banyak fleksibilitas. Bergantung pada konfigurasinya, update lonjakan dapat mengikuti strategi "buat sebelum menghentikan", strategi "hentikan sebelum membuat", 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 tidak terlalu 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, sebagian besar resource lonjakan 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 dalam satu waktu, mengikuti pendekatan "buat sebelum hentikan". Dibandingkan dengan update bertahap non-lonjakan standar, yang setara dengan (max-surge-update=0, max-unavailable-update=1), metode ini lebih tidak mengganggu, mempercepat mulai ulang Pod selama update, dan lebih konservatif dalam progresnya.

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

Update cepat tanpa resource tambahan

Untuk workload yang dapat mentoleransi 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 "akhiri sebelum buat". Karena tidak ada node lonjakan tambahan yang diperkenalkan selama proses, metode ini juga paling hemat biaya, sehingga menghindari biaya 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 dengan cara "buat sebelum hentikan".

Namun, kecepatan keseluruhan update 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, sehingga membatasi paralelisme seluruh update.

Ingatlah bahwa memulai beberapa node lonjakan di 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