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.

Rollback cluster ke versi Kubernetes sebelumnya

Dengan rollback versi Amazon EKS, Anda dapat mengembalikan control plane Kubernetes cluster Anda ke versi minor sebelumnya setelah melakukan upgrade di tempat. Jika Anda mengalami masalah setelah memutakhirkan, seperti ketidakcocokan aplikasi, penggunaan API yang tidak digunakan lagi, atau perilaku yang tidak terduga, Anda dapat memutar kembali untuk memulihkan klaster Anda ke status baik yang diketahui.

Selama rollback, Amazon EKS mengembalikan server API Kubernetes dan komponen bidang kontrol ke versi sebelumnya sambil mempertahankan semua data etcd, beban kerja pelanggan, dan volume persisten.

Apa yang akan digulung kembali

Apa yang TIDAK digulung kembali

Prasyarat

Sebelum Anda dapat memutar kembali cluster, semua kondisi berikut harus dipenuhi:

Selain persyaratan sebelumnya, kondisi tertentu membuat rollback tidak mungkin bahkan dengan bendera. --force Ini termasuk: cluster dibuat pada versi saat ini, lebih dari 7 hari telah berlalu sejak pemutakhiran, cluster telah ditingkatkan lagi ke versi yang lebih baru, atau fitur EKS yang tidak kompatibel ke belakang diaktifkan pada batas versi saat ini.

Ringkasan

Ringkasan tingkat tinggi dari proses rollback cluster Amazon EKS adalah sebagai berikut:

Langkah 1: Tinjau wawasan kesiapan rollback

Amazon EKS secara otomatis mengevaluasi klaster Anda terhadap serangkaian pemeriksaan kesiapan rollback point-in-time dan memunculkan masalah apa pun melalui wawasan klaster di bawah kategori tersebut. ROLLBACK_READINESS Wawasan ini muncul setelah Anda melakukan peningkatan dan tetap tersedia selama jendela kelayakan rollback 7 hari.

Melihat wawasan kesiapan rollback

AWS Konsol:

AWS CLI:

aws eks list-insights \
  --cluster-name my-cluster \
  --region us-west-2 \
  --filter '{"categories": ["ROLLBACK_READINESS"]}'

Untuk mendapatkan detail tentang wawasan tertentu:

aws eks describe-insight \
  --cluster-name my-cluster \
  --region us-west-2 \
  --id <insight-id>

Wawasan yang menyegarkan

EKS menyegarkan wawasan setiap 24 jam. Anda dapat memicu penyegaran secara manual setelah menyelesaikan masalah menggunakan tombol Refresh di konsol Amazon EKS, atau dengan menggunakan CLI:

aws eks start-insights-refresh \
  --cluster-name my-cluster \
  --region us-west-2

Perilaku status wawasan

Wawasan dengan ERROR atau status UNKNOWN memblokir rollback. Wawasan dengan status PASSING atau WARNING tidak menghalangi Anda untuk mundur.

Pemeriksaan kesiapan rollback

Amazon EKS melakukan serangkaian pemeriksaan sebagai bagian dari wawasan kesiapan rollback. Pemeriksaan ini mengevaluasi kompatibilitas penggunaan API (termasuk deteksi perubahan tingkat lapangan), kesehatan cluster, kubelet version skew, kube-proxy version skew, dan kompatibilitas versi add-on. Untuk klaster yang menjalankan Mode Otomatis EKS, pemeriksaan tambahan mengevaluasi anggaran NodePool gangguan, anotasi jangan ganggu, dan konfigurasi. PodDisruptionBudget

Menggunakan flag --force

Jika wawasan kesiapan rollback menunjukkan status ERROR dan Anda ingin melanjutkan tanpa menyelesaikan masalah, Anda dapat menggunakan --force tanda untuk melewati semua pemeriksaan wawasan:

aws eks update-cluster-version \
  --name my-cluster \
  --kubernetes-version 1.30 \
  --force \
  --region us-west-2

--forceBendera hanya melewati pemeriksaan wawasan. Itu tidak melewati validasi prasyarat seperti jendela 7 hari, pemeriksaan versi pembuatan, atau pemeriksaan rollback berurutan. Untuk kluster Mode Otomatis, --force tidak mengesampingkan kontrol gangguan. NodePool anggaran gangguan, PDB, dan anotasi jangan ganggu masih dihormati.

Langkah 2: Siapkan node pekerja

Sebelum memutar kembali bidang kontrol, pastikan node pekerja Anda kompatibel dengan versi target. Kebijakan miring versi Kubernetes mengharuskan node pekerja tidak dapat menjalankan versi yang lebih baru dari bidang kontrol.

Mode Otomatis EKS

Tidak ada tindakan diperlukan. Saat Anda memulai rollback, EKS secara otomatis memutar kembali node Mode Otomatis sebelum bidang kontrol. Untuk informasi selengkapnya, lihat Rollback Kluster Mode Otomatis EKS.

Grup Node Terkelola (MNG)

Anda harus memutar kembali grup node terkelola Anda ke versi sebelumnya sebelum memutar kembali bidang kontrol. Gunakan UpdateNodegroupVersion API:

aws eks update-nodegroup-version \
  --cluster-name my-cluster \
  --nodegroup-name my-nodegroup \
  --kubernetes-version 1.30 \
  --region us-west-2

Pembaruan grup node menghormati pengaturan pembaruan yang dikonfigurasi (maxUnavailableataumaxUnavailablePercentage) dan strategi pembaruan (Rolling atau Force).

Self-managed node dan node hibrida

Anda bertanggung jawab untuk memutar kembali node yang dikelola sendiri 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. Anda dapat memutar kembali bidang kontrol klaster yang menggunakan Fargate, tetapi pod Fargate yang menjalankan versi Kubernetes yang sama dengan bidang kontrol memicu wawasan miring versi kubelet dengan status ERROR.

EKS tidak dapat secara otomatis mengembalikan pod Fargate ke versi kubelet yang lebih lama.

Solusi: Jika Anda memiliki pod Fargate yang menjalankan versi Kubernetes yang sama dengan bidang kontrol, hapus pod tersebut sebelum memulai rollback. Kemudian putar kembali pesawat kontrol Anda. Pod yang tersisa diluncurkan dengan versi rolled-back saat Anda menerapkannya kembali.

Atau, gunakan --force untuk melewati pemeriksaan wawasan. Namun, melanjutkan dengan pelanggaran kemiringan versi kubelet dapat mengakibatkan perilaku yang tidak terduga untuk beban kerja Fargate Anda hingga pod tersebut diganti.

Langkah 3: Kembalikan bidang kontrol cluster

Anda dapat memulai rollback menggunakan Console AWS , AWS CLI, atau EKS API.

Rollback cluster menggunakan AWS Konsol

Rollback membutuhkan waktu beberapa menit untuk menyelesaikannya. Untuk cluster Mode Otomatis, fase rollback node mungkin memakan waktu lebih lama. Untuk informasi selengkapnya, lihat Rollback Kluster Mode Otomatis EKS.

Rollback cluster menggunakan AWS CLI

Gunakan update-cluster-version perintah yang ada dengan versi Kubernetes sebelumnya (N-1):

aws eks update-cluster-version \
  --name my-cluster \
  --kubernetes-version 1.30 \
  --region us-west-2

Contoh respons:

{
    "update": {
        "id": "e4091a28-ea14-48fd-a8c7-975aeb469e8a",
        "status": "InProgress",
        "type": "VersionRollback",
        "params": [
            {
                "type": "Version",
                "value": "1.30"
            },
            {
                "type": "PlatformVersion",
                "value": "eks.16"
            }
        ],
        "createdAt": "2026-05-12T16:56:01.082000-04:00",
        "errors": []
    }
}

Langkah 4: Pantau kemajuan rollback

Anda dapat memantau status rollback cluster Anda menggunakan konsol Amazon EKS atau CLI AWS .

AWS CLI:

aws eks describe-update \
  --name my-cluster \
  --region us-west-2 \
  --update-id e4091a28-ea14-48fd-a8c7-975aeb469e8a

AWS Konsol:

Transisi status

Untuk cluster standar (tanpa Mode Otomatis):

InProgress → Successful
InProgress → Failed

Untuk kluster Mode Otomatis, status cluster tetap ada ACTIVE saat node berputar kembali dan berubah UPDATING hanya ketika rollback bidang kontrol dimulai. Gunakan describe-update untuk melacak kemajuan rollback keseluruhan. Untuk informasi selengkapnya, lihat Rollback Kluster Mode Otomatis EKS.

Ketika Successful status ditampilkan, rollback selesai.

Pertimbangan dan peringatan

Wawasan adalah upaya terbaik dan point-in-time

Wawasan cluster dievaluasi pada saat rollback dipicu. Jika Anda membuat perubahan pada klaster setelah wawasan diperiksa tetapi sebelum rollback selesai (misalnya, membuat resource menggunakan API baru), perubahan tersebut tidak ditangkap oleh pemeriksaan wawasan awal dan dapat menyebabkan masalah setelah rollback selesai.

pelestarian data etcd

EKS menyimpan data etcd selama rollback. Sumber daya yang tidak kompatibel yang dilewati menggunakan --force bendera tetap bertahan dan bukan sampah yang dikumpulkan.

Biaya dukungan yang diperpanjang

Jika Anda memutar kembali dari versi di bawah dukungan standar ke versi di bawah dukungan yang diperluas, klaster Anda mulai menimbulkan biaya dukungan yang diperpanjang. Misalnya, jika Anda meningkatkan dari 1,30 (dukungan diperpanjang) ke 1,31 (dukungan standar) dan kemudian kembali ke 1,30, biaya dukungan yang diperpanjang dilanjutkan.

Model tanggung jawab bersama untuk rollback

EKS memutar kembali bidang kontrol Kubernetes ke versi yang diinginkan. Sebagai bagian dari model tanggung jawab bersama, Anda bertanggung jawab untuk memverifikasi kompatibilitas aplikasi dengan versi sebelumnya:

CloudFormation perilaku stack rollback

Jika pembaruan CloudFormation tumpukan gagal dan memicu rollback stack, pengembalian ke versi template sebelumnya yang menentukan versi Kubernetes yang lebih rendah tidak akan memicu rollback versi cluster. Versi rollback harus secara eksplisit dimulai melalui API UpdateClusterVersion , CLI, atau konsol.

Rollback dan add-on

EKS tidak secara otomatis mengembalikan versi add-on selama rollback versi cluster. Anda harus mengelola versi add-on secara terpisah.

Sebelum memutar kembali bidang kontrol:

aws eks update-addon \
  --cluster-name my-cluster \
  --addon-name vpc-cni \
  --addon-version v1.12.0-eksbuild.2 \
  --region us-west-2

+. Setelah rollback bidang kontrol selesai, verifikasi semua add-on berfungsi dengan benar.

Sumber daya terkait