Praktik Terbaik untuk Rollback Versi Cluster

Amazon EKS mengelola: Memutar kembali server API Kubernetes dan komponen bidang kontrol. Untuk cluster Mode Otomatis, Amazon EKS juga mengelola memutar kembali node pekerja.

Anda bertanggung jawab untuk: Mengembalikan Grup Node Terkelola, node yang dikelola sendiri, dan node hibrida. Anda juga harus memvalidasi kompatibilitas add-on dan memastikan aplikasi, pengontrol khusus, dan alat pihak ketiga berfungsi dengan benar dengan versi sebelumnya.

Pisahkan bidang kontrol dan peningkatan bidang data (cluster Mode non-otomatis). Untuk cluster yang menggunakan Grup Node Terkelola atau node yang dikelola sendiri, pertimbangkan untuk memutakhirkan bidang kontrol terlebih dahulu dan mengizinkan periode pemanggangan sebelum memutakhirkan node pekerja. Sementara node tetap aktif N-1, wawasan miring versi kubelet tetap dalam status PASSING. Ini membuat jalur rollback tetap jelas tanpa perlu memutar kembali node terlebih dahulu.

Tingkatkan add-on ke versi yang kompatibel silang. Sebelum memutakhirkan control plane, pastikan semua add-on (terkelola dan dikelola sendiri) kompatibel dengan versi Kubernetes saat ini dan target. Ini membuat wawasan kompatibilitas add-on tetap jelas untuk peningkatan dan pengembalian.

Hindari menggunakan API khusus versi selama periode pemanggangan. Jika Anda membuat sumber daya yang menggunakan API atau fitur yang hanya tersedia di versi baru selama jendela 7 hari, Anda harus menghapusnya sebelum memutar kembali. Batasi adopsi API khusus versi baru hingga Anda yakin pemutakhiran stabil.

Tingkatkan lebih cepat, bukan nanti. Dengan rollback yang tersedia, Anda dapat dengan percaya diri meningkatkan segera setelah rilis versi baru daripada menunggu hingga tenggat waktu dukungan yang diperpanjang. Memutakhirkan sebelumnya memberi Anda lebih banyak waktu untuk memvalidasi dan mengurangi biaya dukungan yang diperpanjang.

Waspadai pembatasan rollback dukungan yang diperpanjang. Jika klaster Anda ditingkatkan secara otomatis di akhir dukungan yang diperluas, Anda tidak dapat memutar kembali ke versi sebelumnya. Jika Anda ditingkatkan secara otomatis di akhir dukungan standar, Anda dapat memutar kembali, tetapi Anda harus terlebih dahulu mengubah kebijakan pemutakhiran menjadi. EXTENDED

Tinjau wawasan segera setelah peningkatan. Jangan menunggu sampai ada yang tidak beres. Setelah meningkatkan, periksa wawasan kesiapan rollback sehingga Anda tahu postur rollback Anda saat ini.

Mengatasi wawasan ERROR secara proaktif. Jika wawasan menunjukkan status ERROR sesaat setelah pemutakhiran, selesaikan lebih awal saat jendela 7 hari masih terbuka. Semakin lama Anda menunggu, semakin besar kemungkinan status cluster Anda menyimpang dan pemblokir baru muncul.

Pahami apa yang dilakukan dan tidak mencakup wawasan. Wawasan memeriksa versi add-on yang dikelola Amazon EKS, penggunaan API, kemiringan versi, dan kesehatan klaster. Mereka tidak memeriksa add-on yang dikelola sendiri, pengontrol khusus, atau kompatibilitas tingkat aplikasi. Pertahankan validasi kompatibilitas Anda sendiri untuk add-on yang dikelola sendiri (misalnya, cluster-autoscaler, pengontrol masuk, operator khusus, agen pemantauan).

Grup Node Terkelola. Anda harus memutar kembali grup node terkelola Anda ke versi sebelumnya sebelum memutar kembali bidang kontrol. Gunakan UpdateNodegroupVersion operasi dengan versi Kubernetes sebelumnya. Rollback menghormati pengaturan pembaruan Anda yang dikonfigurasi (maxUnavailable, strategi pembaruan).

Self-managed dan node hibrida. Perbarui AMI atau konfigurasi node Anda untuk menggunakan versi Kubernetes sebelumnya sebelum memutar kembali bidang kontrol.

Fargate. Versi rollback tidak didukung untuk node pekerja Fargate. Hapus pod Fargate yang menjalankan versi yang sama dengan control plane sebelum memulai rollback, atau gunakan --force untuk mem-bypass insight versi miring (yang mungkin mengakibatkan perilaku tak terduga hingga pod diganti).

Tinjau anggaran gangguan sebelum memulai rollback. Amazon EKS memberikan wawasan kesiapan rollback untuk anggaran gangguan. NodePool Anggaran yang disetel ke 0 memicu wawasan ERROR, yang memblokir rollback tanpa batas. Anggaran terbatas dan PodDisruptionBudgets (PDB) memicu wawasan PERINGATAN, yang dapat memperlambat kemunduran tetapi memungkinkan kemajuan ke depan. Alamat wawasan ERROR sebelum memulai rollback.

Bersiaplah untuk menyesuaikan anggaran selama rollback. Jika rollback memakan waktu lebih lama dari yang diharapkan, Anda dapat menyesuaikan anggaran NodePool gangguan dan PDB kubectl saat rollback sedang berlangsung. Meningkatkan anggaran memungkinkan penggantian node lebih bersamaan.

Hapus anotasi do-not-disrupt dari memblokir node. karpenter.sh/do-not-disruptAnotasi pada node memblokir rollback tanpa batas waktu. Hapus dari node yang harus diganti.

Lacak kemajuan rollback node. Gunakan kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wide untuk memantau node mana yang telah diganti dengan AMI versi sebelumnya.

Gunakan CancelUpdate jika diperlukan. Jika rollback terlalu lama atau menyebabkan lebih banyak masalah daripada yang dipecahkan, batalkan rollback. Setelah pembatalan, node bertemu kembali ke versi saat ini dan Anda dapat mengambil pendekatan yang berbeda.

Tetapkan batas waktu yang sesuai. Gunakan timeoutMinutes parameter rollbackConfig untuk menyelaraskan dengan harapan operasional Anda. Defaultnya adalah 720 menit (12 jam). Untuk cluster dengan anggaran konservatif, pertimbangkan untuk meningkatkannya. Untuk IaC-managed cluster, sejajarkan dengan batas waktu alat Anda.

DescribeUpdate operasi. Gunakan describe-update untuk memeriksa status operasi rollback saat ini (InProgress,, SuccessfulFailed,Cancelled). Untuk melacak kemajuan pembatalan, periksa cancellation objek dalam respons.

Wawasan cluster. Amazon EKS memeriksa ulang wawasan sebelum melanjutkan dengan rollback bidang kontrol (setelah rollback node selesai untuk Mode Otomatis). Pantau wawasan ERROR baru yang mungkin muncul.

Status klaster. Untuk cluster Mode Otomatis, status cluster tetap ACTIVE selama rollback node dan berubah UPDATING hanya selama rollback bidang kontrol. Jangan hanya mengandalkan status cluster untuk mengetahui rollback sedang berlangsung — gunakan. DescribeUpdate

Versi simpul. Untuk Mode Otomatis, periksa versi Kubernetes node untuk melacak kemajuan penggantian node. Untuk Grup Node Terkelola, pantau status pembaruan grup node.

AWS CloudFormation mendukung hingga 36 jam per sumber daya. Jika rollback melebihi ini, CloudFormation perlakukan sebagai no-op, yang dapat meninggalkan cluster dalam keadaan hanyut di mana template tidak mencerminkan versi cluster yang sebenarnya. Batas waktu rollback default adalah 720 menit (12 jam).

Terraform Enterprise/Cloud memiliki batas waktu sekitar 24 jam, meskipun batas waktu sisi klien bervariasi.

Sejajarkan timeoutMinutes dengan batas waktu alat IAC Anda untuk mencegah alat IAc dari kehabisan waktu sebelum Amazon EKS menyelesaikan rollback.

Pertimbangkan CLI/API untuk memulai rollback melalui kluster Mode Otomatis dengan anggaran terbatas, bukan melalui IAc. Gunakan CancelUpdate langsung jika lapisan IAc habis waktu.

AWS CloudFormation stack rollback tidak memicu rollback versi. Jika pembaruan CloudFormation tumpukan AWS gagal, pengembalian tumpukan otomatis ke versi template sebelumnya tidak akan memulai rollback versi cluster. Anda harus secara eksplisit memulai rollback versi.

Rollback melengkapi pengujian, itu tidak menggantikannya. Lanjutkan menggunakan wawasan cluster, pengujian pra-peningkatan di lingkungan non-produksi, dan peluncuran bertahap. Rollback menangani kasus yang tidak dapat ditangkap oleh pengujian — masalah yang hanya muncul dalam produksi.

Rollback mengurangi kebutuhan akan prosedur pencadangan dan snapshot manual sebagai mekanisme keselamatan utama Anda. Dengan rollback asli yang tersedia, Anda tidak perlu lagi hanya mengandalkan snapshot etcd atau skrip rollback khusus untuk pemulihan bencana selama peningkatan.

Wawasan adalah upaya terbaik dan point-in-time. Amazon EKS mengevaluasi mereka ketika Anda memicu rollback. Perubahan yang dilakukan setelah pemeriksaan itu (misalnya, membuat sumber daya dengan API baru) tidak ditangkap dan dapat menyebabkan masalah setelah rollback selesai.

Rollback tidak menjamin pemulihan aplikasi. Amazon EKS mengembalikan bidang kontrol dengan aman, tetapi aplikasi, konfigurasi, dan dependensi Anda bertanggung jawab untuk memvalidasi terhadap versi sebelumnya.

Rollback cluster ke versi Kubernetes sebelumnya

Kembalikan kluster Mode Otomatis Amazon EKS

Praktik Terbaik untuk Upgrade Cluster

Wawasan cluster

Siklus hidup versi Kubernetes di EKS