Perilaku pembaruan simpul terkelola - Amazon EKS
Fase pengaturanTingkatkan faseFase upgradeSkala turun fase

Bantu tingkatkan halaman ini

Ingin berkontribusi pada panduan pengguna ini? Gulir ke bagian bawah halaman ini dan pilih Edit halaman ini GitHub. Kontribusi Anda akan membantu membuat panduan pengguna kami lebih baik untuk semua orang.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Perilaku pembaruan simpul terkelola

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

Fase pengaturan

Fase pengaturan memiliki langkah-langkah berikut:

  1. Ini membuat versi template peluncuran Amazon EC2 baru untuk grup Auto Scaling yang terkait dengan grup node Anda. Versi template peluncuran baru menggunakan AMI target atau versi template peluncuran khusus untuk pembaruan.

  2. Ini memperbarui grup Auto Scaling untuk menggunakan versi template peluncuran terbaru.

  3. Ini menentukan jumlah maksimum node untuk meng-upgrade secara paralel menggunakan updateConfig properti untuk kelompok node. Maksimum yang tidak tersedia memiliki kuota 100 node. Nilai default adalah satu node. Untuk informasi selengkapnya, lihat updateConfigproperti di Referensi API Amazon EKS.

Tingkatkan fase

Saat memutakhirkan node dalam grup node terkelola, node yang ditingkatkan diluncurkan di Availability Zone yang sama dengan yang sedang ditingkatkan. Untuk menjamin penempatan ini, kami menggunakan Penyeimbangan Zona Ketersediaan Amazon EC2. Untuk informasi selengkapnya, lihat Penyeimbangan Kembali Zona Ketersediaan di Panduan Pengguna Auto Scaling Amazon EC2. Untuk memenuhi persyaratan ini, ada kemungkinan bahwa kami akan meluncurkan hingga dua instance per Availability Zone di grup node terkelola Anda.

Fase peningkatan skala memiliki langkah-langkah berikut:

  1. Ini meningkatkan ukuran maksimum Grup Auto Scaling dan ukuran yang diinginkan dengan ukuran yang lebih besar:

    • Hingga dua kali jumlah Availability Zone tempat grup Auto Scaling digunakan.

    • Upgrade maksimum yang tidak tersedia.

      Misalnya, jika grup node Anda memiliki lima Availability Zones dan maxUnavailable sebagai satu, proses upgrade dapat meluncurkan maksimal 10 node. Namun ketika maxUnavailable 20 (atau apa pun yang lebih tinggi dari 10), proses akan meluncurkan 20 node baru.

  2. Setelah menskalakan grup Auto Scaling, ia memeriksa apakah node yang 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 node AMI:

      • eks.amazonaws.com/nodegroup-image=$amiName

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      • eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId

      • eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion

  3. Ini menandai node sebagai tidak dapat dijadwalkan untuk menghindari penjadwalan baru. Pods Ini juga memberi label node node.kubernetes.io/exclude-from-external-load-balancers=true untuk menghapus node dari penyeimbang beban sebelum mengakhiri node.

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

Kapasitas tidak mencukupi di Availability Zone

Ada kemungkinan bahwa Availability Zone mungkin tidak memiliki kapasitas tipe instans yang diminta. Disarankan untuk mengonfigurasi beberapa jenis instance 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 Service Quotas. Untuk informasi selengkapnya, lihat Service Quotas 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 dimulai 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 Ready berstatus.

Fase upgrade

Fase upgrade memiliki langkah-langkah berikut:

  1. Ini secara acak memilih node yang perlu ditingkatkan, hingga maksimum yang tidak tersedia yang dikonfigurasi untuk grup node.

  2. Ini menguras Pods dari simpul. Jika Pods tidak meninggalkan node dalam waktu 15 menit dan tidak ada tanda gaya, fase pemutakhiran gagal dengan PodEvictionFailure kesalahan. Untuk skenario ini, Anda dapat menerapkan bendera gaya dengan update-nodegroup-version permintaan untuk menghapusPods.

  3. Ini mengikat simpul setelah setiap Pod diusir dan menunggu selama 60 detik. Hal ini dilakukan agar pengontrol layanan tidak mengirim permintaan baru ke node ini dan menghapus node ini dari daftar node aktifnya.

  4. Ini mengirimkan permintaan penghentian ke Grup Auto Scaling untuk node yang diapit.

  5. Ini mengulangi langkah-langkah upgrade sebelumnya sampai tidak ada node dalam grup node yang digunakan dengan versi sebelumnya dari template peluncuran.

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 yang sama. Pod

Penerapan yang menoleransi semua noda

Setelah setiap Pod diusir, diharapkan node kosong karena node tercemar pada langkah-langkah sebelumnya. Namun, jika penerapan mentolerir setiap noda, maka node lebih cenderung tidak kosong, yang menyebabkan kegagalan penggusuran. Pod

Skala turun fase

Fase penurunan skala mengurangi ukuran maksimum grup Auto Scaling dan ukuran yang diinginkan satu per satu untuk kembali ke nilai sebelum pembaruan dimulai.

Jika alur kerja Upgrade menentukan bahwa Cluster Autoscaler meningkatkan grup node selama fase penurunan skala alur kerja, ia segera keluar tanpa membawa grup node kembali ke ukuran aslinya.