Memahami setiap fase pembaruan node - Amazon EKS
Fase pengaturanTingkatkan faseFase upgradeSkala turun fase

Bantu tingkatkan halaman ini

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

Untuk berkontribusi pada panduan pengguna ini, pilih Edit halaman ini pada GitHub tautan yang terletak di panel kanan setiap halaman.

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

Memahami setiap fase pembaruan node

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 EC2 peluncuran Amazon 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 defaultnya adalah satu node. Untuk informasi selengkapnya, lihat properti updateConfig 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 Availability EC2 Zone Rebalancing Amazon. Untuk informasi selengkapnya, lihat Penyeimbangan Kembali Zona Ketersediaan di Panduan Pengguna Auto EC2 Scaling Amazon. 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 dari keduanya:

    • Hingga dua kali jumlah Availability Zone yang digunakan oleh Grup Auto Scaling.

    • 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 simpul 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 Pod baru. 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.

EC2 batas instans di akun Anda

Anda mungkin perlu menambah jumlah EC2 instans Amazon yang dapat dijalankan akun Anda secara bersamaan menggunakan Service Quotas. Untuk informasi selengkapnya, lihat EC2 Service Quotas 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.

Setiap node paling bootstrap dalam waktu 15 menit

Jika ada node yang membutuhkan waktu lebih dari 15 menit untuk bootstrap dan bergabung dengan cluster, itu akan menyebabkan pemutakhiran menjadi time out. 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 Auto Scaling meningkat.

Fase upgrade

Fase pemutakhiran 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 mengakhiri yang lama, sehingga kapasitas yang tersedia dipertahankan selama fase upgrade. Strategi minimal berguna dalam skenario di mana Anda dibatasi untuk sumber daya atau biaya, misalnya dengan akselerator perangkat keras seperti. GPUs 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 berikut:

  1. Ini meningkatkan jumlah node (jumlah yang diinginkan) di Auto Scaling Group, menyebabkan grup node untuk membuat node tambahan.

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

  3. Ini menguras Pod dari node. Jika Pod tidak meninggalkan node dalam waktu 15 menit dan tidak ada force flag, fase upgrade gagal dengan PodEvictionFailure error. Untuk skenario ini, Anda dapat menerapkan flag force dengan update-nodegroup-version permintaan untuk menghapus Pod.

  4. Ini menutup node 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.

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

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

Strategi pembaruan minimal 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 Pod dari node. Jika Pod tidak meninggalkan node dalam waktu 15 menit dan tidak ada force flag, fase upgrade gagal dengan PodEvictionFailure error. Untuk skenario ini, Anda dapat menerapkan flag force dengan update-nodegroup-version permintaan untuk menghapus Pod.

  3. Ini menutup node 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. Grup Auto Scaling membuat node baru untuk menggantikan kapasitas yang hilang.

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

PodEvictionFailurekesalahan 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 yang PDBs menunjuk ke Pod yang sama.

Penerapan yang menoleransi semua noda

Setelah setiap Pod diusir, node diharapkan kosong karena node tercemar pada langkah-langkah sebelumnya. Namun, jika deployment mentolerir setiap taint, 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.