Fase penyiapan Fase peningkatan skala Fase upgrade Fase penurunan skala

Memahami setiap fase pembaruan node

Strategi peningkatan node pekerja terkelola Amazon EKS memiliki empat fase berbeda yang dijelaskan di bagian berikut.

Fase penyiapan

Fase penyiapan memiliki langkah-langkah ini:

Ini membuat versi template peluncuran Amazon EC2 baru untuk Grup Penskalaan Otomatis yang terkait dengan grup node Anda. Versi template peluncuran baru menggunakan AMI target atau versi template peluncuran khusus untuk pembaruan.
Ini memperbarui Grup Penskalaan Otomatis untuk menggunakan versi template peluncuran terbaru.
Ini menentukan jumlah maksimum node untuk ditingkatkan secara paralel menggunakan updateConfig properti untuk grup node. Maksimum yang tidak tersedia memiliki kuota 100 node. Nilai defaultnya adalah satu node. Untuk informasi selengkapnya, lihat properti updateConfig di Referensi API Amazon EKS.

Fase peningkatan skala

Saat memutakhirkan node dalam grup node terkelola, node yang ditingkatkan diluncurkan di Zona Ketersediaan yang sama dengan node yang sedang ditingkatkan. Untuk menjamin penempatan ini, kami menggunakan Rebalancing Zona Ketersediaan Amazon EC2. Untuk informasi selengkapnya, lihat Penyeimbangan Zona Keter sediaan di Panduan Pengguna Penskalaan Otomatis Amazon EC2. Untuk memenuhi persyaratan ini, kami mungkin meluncurkan hingga dua instans per Zona Ketersediaan di grup node terkelola Anda.

Fase peningkatan skala memiliki langkah-langkah ini:

Ini menambah ukuran maksimum Grup Penskalaan Otomatis dan ukuran yang diinginkan dengan yang lebih besar dari:
- Hingga dua kali jumlah Zona Ketersediaan tempat Grup Penskalaan Otomatis digunakan.
- Maksimum upgrade yang tidak tersedia.
  
  Misalnya, jika grup node Anda memiliki lima Zona Ketersediaan dan maxUnavailable sebagai satu, proses peningkatan dapat meluncurkan maksimal 10 node. Namun ketika maxUnavailable 20 (atau sesuatu yang lebih tinggi dari 10), prosesnya akan meluncurkan 20 node baru.
Setelah menskalakan Grup Penskalaan Otomatis, ia memeriksa apakah node menggunakan konfigurasi terbaru ada di grup node. Langkah ini hanya berhasil jika memenuhi kriteria ini:
- Setidaknya satu node baru diluncurkan di setiap Availability Zone di mana node ada.
- Setiap node baru harus dalam Ready keadaan.
- Node baru harus memiliki label yang diterapkan Amazon EKS.
  
  Ini adalah label yang diterapkan Amazon EKS pada node pekerja dalam grup node biasa:
  - eks.amazonaws.com/nodegroup-image=$amiName
  - eks.amazonaws.com/nodegroup=$nodeGroupName
  Ini adalah label yang diterapkan Amazon EKS pada node pekerja dalam template peluncuran khusus atau grup simpul AMI:
  - eks.amazonaws.com/nodegroup-image=$amiName
  - eks.amazonaws.com/nodegroup=$nodeGroupName
  - eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId
  - eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion
    
    catatan
    Ketika pembaruan atau peningkatan dimulai tanpa perubahan pada konfigurasi penskalaan, alur kerja menggunakan nilai grup Auto Scaling langsung sebagai titik awal, bukan konfigurasi penskalaan tersimpan grup node. Untuk informasi selengkapnya, lihat Konsep grup simpul terkelola.
Ini menandai node sebagai tidak dapat dijadwalkan untuk menghindari penjadwalan Pod baru. Ini juga memberi label node dengan node.kubernetes.io/exclude-from-external-load-balancers=true untuk menghapus node lama dari penyeimbang beban sebelum mengakhiri node.

Berikut ini adalah alasan yang diketahui yang menyebabkan NodeCreationFailure kesalahan dalam fase ini:

Kapasitas tidak mencukupi di Zona Ketersediaan: Ada kemungkinan bahwa Zona Ketersediaan mungkin tidak memiliki kapasitas jenis instans yang diminta. Disarankan untuk mengonfigurasi beberapa jenis instans saat membuat grup node terkelola.
Batas instans EC2 di akun Anda: Anda mungkin perlu menambah jumlah instans Amazon EC2 yang dapat dijalankan akun Anda secara bersamaan menggunakan Kuota Layanan. Untuk informasi selengkapnya, lihat Kuota Layanan EC2 di Panduan Pengguna Amazon Elastic Compute Cloud untuk Instans Linux.
Data pengguna kustom: Data pengguna khusus terkadang dapat merusak proses bootstrap. Skenario ini dapat menyebabkan kubelet tidak memulai pada node atau node tidak mendapatkan label Amazon EKS yang diharapkan pada mereka. Untuk informasi selengkapnya, lihat Menentukan AMI.
Setiap perubahan yang membuat node tidak sehat atau tidak siap: Tekanan disk node, tekanan memori, dan kondisi serupa dapat menyebabkan node tidak akan ber Ready status.
Setiap node harus melakukan bootstrap dalam waktu 15 menit: Jika ada node yang membutuhkan waktu lebih dari 15 menit untuk melakukan bootstrap dan bergabung dengan cluster, itu akan menyebabkan pemutakhiran habis waktu. Ini adalah total runtime untuk bootstrap node baru yang diukur dari saat node baru diperlukan hingga saat bergabung dengan cluster. Saat memutakhirkan grup node terkelola, penghitung waktu dimulai segera setelah ukuran Grup Penskalaan Otomatis meningkat.

Fase upgrade

Fase peningkatan berperilaku dalam dua cara berbeda, tergantung pada strategi pembaruan. Ada dua strategi pembaruan: default dan minimal.

Kami merekomendasikan strategi default di sebagian besar skenario. Ini menciptakan node baru sebelum menghentikan yang lama, sehingga kapasitas yang tersedia dipertahankan selama fase upgrade. Strategi minimal berguna dalam skenario di mana Anda dibatasi pada sumber daya atau biaya, misalnya dengan akselerator perangkat keras seperti GPU. Ini mengakhiri node lama sebelum membuat yang baru, sehingga kapasitas total tidak pernah meningkat melebihi kuantitas yang Anda konfigurasi.

Strategi pembaruan default memiliki langkah-langkah ini:

Ini meningkatkan jumlah node (jumlah yang diinginkan) di Grup Penskalaan Otomatis, menyebabkan grup node membuat node tambahan.
Ini secara acak memilih node yang perlu ditingkatkan, hingga maksimum yang tidak tersedia dikonfigurasi untuk grup node.
Ini menutup node lama segera setelah node baru mencapai status Si ap, mencegah pengontrol layanan mengirim permintaan baru ke node itu.
Ini menguras Pod dari simpul. Jika Pod tidak meninggalkan node dalam waktu 15 menit dan tidak ada tanda paksa, fase peningkatan gagal dengan PodEvictionFailure kesalahan. Untuk skenario ini, Anda dapat menerapkan tanda paksa dengan update-nodegroup-version permintaan untuk menghapus Pod.
Itu menunggu 60 detik setelah mengusir setiap Pod. Kemudian mengirimkan permintaan penghentian ke Grup Penskalaan Otomatis dan menghapus node dari daftar node aktif.
Ini mengulangi langkah-langkah peningkatan sebelumnya sampai tidak ada node dalam grup node yang digunakan dengan versi sebelumnya dari template peluncuran.

Strategi pembaruan minimal memiliki langkah-langkah ini:

Ini mengunci semua node grup node di awal, sehingga pengontrol layanan tidak mengirim permintaan baru ke node ini.
Ini secara acak memilih node yang perlu ditingkatkan, hingga maksimum yang tidak tersedia dikonfigurasi untuk grup node.
Ini menguras Pod dari node yang dipilih. Jika Pod tidak meninggalkan node dalam waktu 15 menit dan tidak ada tanda paksa, fase peningkatan gagal dengan PodEvictionFailure kesalahan. Untuk skenario ini, Anda dapat menerapkan tanda paksa dengan update-nodegroup-version permintaan untuk menghapus Pod.
Setelah setiap Pod diusir dan menunggu selama 60 detik, Pod akan mengirimkan permintaan penghentian ke Grup Penskalaan Otomatis untuk node yang dipilih. Grup Penskalaan Otomatis membuat node baru (sama dengan jumlah node yang dipilih) untuk menggantikan kapasitas yang hilang.
Ini mengulangi langkah-langkah peningkatan sebelumnya sampai tidak ada node dalam grup node yang digunakan dengan versi sebelumnya dari template peluncuran.

`PodEvictionFailure`kesalahan selama fase upgrade

Berikut ini adalah alasan yang diketahui yang menyebabkan PodEvictionFailure kesalahan dalam fase ini:

PDB agresif: PDB agresif didefinisikan pada Pod atau ada beberapa PDB yang menunjuk ke Pod yang sama.
Penerapan menoleransi semua noda: Setelah setiap Pod diusir, diharapkan node kosong karena node tercemar pada langkah sebelumnya. Namun, jika penerapan mentolerir setiap noda, maka simpul lebih cenderung tidak kosong, yang menyebabkan kegagalan penggusuran Pod.

Fase penurunan skala

Fase penurunan skala mengurangi ukuran maksimum grup Penskalaan Otomatis dan ukuran yang diinginkan satu untuk kembali ke nilai sebelum pembaruan dimulai.

Jika alur kerja Upgrade menentukan bahwa Cluster Autoscaler menskalakan grup node selama fase penurunan skala alur kerja, alur kerja tersebut akan segera keluar tanpa mengembalikan grup node ke ukuran aslinya.

catatan


If your node group has a warm pool enabled, warm pool instances are drained before the scale-up operation begins. This is because warm pool instances have not been updated to the new launch template configuration — during the scale-up phase, they would be pulled into the Auto Scaling Group instead of launching new instances with the updated configuration, which would break the upgrade process. Draining the warm pool ensures that only new instances with the updated configuration are launched. Once the scale-down operation completes, the warm pool is restored, and the new instances in the warm pool are launched with the updated launch template configuration.

Untuk informasi lebih lanjut tentang kolam hangat, lihatKurangi latensi untuk aplikasi dengan waktu boot yang lama menggunakan kolam hangat dengan grup node terkelola.