View a markdown version of this page

Rollback Kluster Mode Otomatis EKS - Amazon EKS
Cara kerja rollback Mode OtomatisStatus cluster selama rollbackKontrol gangguanMempercepat rollbackMembatalkan rollbackBatas waktu rollbackBendera --force dan Mode OtomatisKonflik batas waktu IAcPembaruan sistem selama rollback nodeSumber daya terkait

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 Kluster Mode Otomatis EKS

Saat Anda memulai rollback versi pada cluster yang menjalankan Mode Otomatis EKS, Amazon EKS secara otomatis mengelola rollback node pekerja Mode Otomatis sebelum mengembalikan bidang kontrol. Halaman ini menjelaskan cara kerja rollback node Mode Otomatis, cara mempercepatnya, dan cara membatalkannya jika diperlukan.

Untuk informasi umum tentang rollback versi, termasuk prasyarat, pemeriksaan wawasan, dan keseluruhan proses rollback, lihat. Rollback cluster ke versi Kubernetes sebelumnya

Cara kerja rollback Mode Otomatis

Mode Otomatis EKS menggunakan Karpenter-based sistem untuk mengelola infrastruktur node pekerja, termasuk upgrade dan rollback versi Kubernetes. Saat Anda memanggil UpdateClusterVersion dengan versi sebelumnya (N-1) di cluster dengan Mode Otomatis diaktifkan, EKS melakukan urutan berikut:

  1. Memvalidasi prasyarat dan menyegarkan wawasan kesiapan rollback.

  2. Drifts node menuju versi rollback yang diinginkan menggunakan Karpenter-based sistem, menghormati kontrol gangguan yang dikonfigurasi.

  3. Setelah semua node berada dalam kebijakan kemiringan versi Kubernetes untuk versi rollback yang diinginkan, EKS memeriksa ulang wawasan dan melanjutkan dengan rollback bidang kontrol.

Bidang kontrol tetap pada versi saat ini (yang lebih baru) dan terus melayani lalu lintas secara normal saat node berputar kembali. Kebijakan skew versi Kubernetes memungkinkan node menjalankan hingga tiga versi minor yang lebih lama dari kube-apiserver, sehingga status perantara ini valid.

catatan

Anda memicu rollback menggunakan API dan proses yang sama yang dijelaskan dalam. Rollback cluster ke versi Kubernetes sebelumnya Tidak ada API terpisah untuk rollback node Mode Otomatis.

catatan

Fase rollback node (langkah 2) dapat berlangsung dari menit hingga 7 hari tergantung pada kontrol gangguan Anda. Jika rollback node tidak selesai dalam batas waktu yang dikonfigurasi, pembaruan ditandai sebagai gagal.

catatan

Sementara rollback sedang berlangsung, pembaruan bidang kontrol yang dipicu pelanggan lainnya diblokir. Untuk melakukan pembaruan yang berbeda, batalkan rollback terlebih dahulu menggunakan API. CancelUpdate

Status cluster selama rollback

Fase Status klaster Apa yang terjadi

Rollback node sedang berlangsung

AKTIF

Karpenter mengganti node dengan AMI versi sebelumnya. Pesawat kontrol sehat dan melayani lalu lintas pada versi saat ini.

Kontrol rollback pesawat

MEMPERBARUI

Server API dan komponen bidang kontrol dikembalikan ke versi sebelumnya.

Rollback selesai

AKTIF

Cluster sepenuhnya pada versi sebelumnya.

Status cluster tetap ACTIVE selama fase rollback node. Gunakan ListUpdates atau DescribeUpdate untuk menentukan apakah rollback sedang berlangsung. Di konsol Amazon EKS, navigasikan ke klaster Anda dan buka tab Riwayat pembaruan untuk melihat status ID pembaruan yang terkait dengan rollback.

Untuk melacak progres node individual selama rollback, periksa versi Kubernetes dari node Mode Otomatis Anda:

kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wide

Kontrol gangguan

Rollback Mode Otomatis menghormati semua kontrol gangguan yang ada. Kontrol ini menentukan seberapa cepat node dapat diganti dan mungkin secara signifikan mempengaruhi durasi rollback.

NodePool Anggaran Gangguan

NodePool Anggaran gangguan mengontrol berapa banyak node yang dapat terganggu secara bersamaan. Selama rollback, Karpenter menghormati anggaran ini saat melayang node ke versi sebelumnya.

  • Anggaran nodes: 0 untuk blok drift rollback tanpa batas waktu. Ini memicu wawasan ERROR.

  • Anggaran yang terbatas (misalnya,nodes: 1) memperlambat rollback tetapi memungkinkan kemajuan ke depan.

Contoh NodePool dengan anggaran gangguan yang memungkinkan 10% node diganti sekaligus:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    budgets:
      - nodes: "10%"
        reasons:
          - Drifted

Untuk informasi selengkapnya tentang mengonfigurasi anggaran NodePool gangguan, lihat Membuat Pool Node untuk Mode Otomatis EKS dan anggaran gangguan Karpenter.

PodDisruptionBudgets

Kubernetes dihormati PodDisruptionBudgets selama penggantian node. Jika PDB mencegah penggusuran pod, gangguan node tertunda hingga. TerminationGracePeriod

  • PDB dengan gangguan node maxUnavailable: 0 penundaan. Ini memicu wawasan PERINGATAN.

  • PDB tidak memblokir rollback secara permanen tetapi dapat memperlambatnya secara signifikan.

Untuk informasi selengkapnya, lihat Melindungi beban kerja penting dengan PDB dan dokumentasi Kubernetes PDB.

Do-not-disrupt anotasi

karpenter.sh/do-not-disruptAnotasi dapat diatur pada node atau pod:

Pada node: Memblokir gangguan node tanpa batas. Ini memicu wawasan ERROR dan harus dihapus sebelum rollback dapat melanjutkan pada node itu.

Pada pod: Menunda gangguan node hingga file. TerminationGracePeriod Ini memicu wawasan PERINGATAN tetapi tidak memblokir rollback secara permanen.

Untuk informasi lebih lanjut tentang perilaku gangguan Karpenter, lihat dokumentasi gangguan Karpenter.

Mempercepat rollback

Jika rollback memakan waktu lebih lama dari yang diharapkan, Anda dapat menyesuaikan kontrol gangguan saat rollback sedang berlangsung.

Meningkatkan NodePool anggaran gangguan

Edit NodePool sumber daya untuk memungkinkan penggantian node yang lebih bersamaan:

kubectl edit nodepool default

Ubah anggaran ke nilai yang lebih tinggi:

spec:
  disruption:
    budgets:
      - nodes: "50%"
        reasons:
          - Drifted

Hapus anotasi jangan ganggu dari node

Buat daftar node dengan anotasi dan hapus:

# List nodes with the annotation
kubectl get nodes -o json | jq '.items[] | select(.metadata.annotations["karpenter.sh/do-not-disrupt"] == "true") | .metadata.name'

# Remove from a specific node
kubectl annotate node <node-name> karpenter.sh/do-not-disrupt-

Sesuaikan PodDisruptionBudgets

Jika PDB memperlambat penggusuran pod, sesuaikan sementara:

kubectl edit pdb <pdb-name> -n <namespace>
Awas

Menyesuaikan kontrol gangguan memengaruhi jaminan ketersediaan aplikasi Anda. Pastikan Anda memahami dampaknya sebelum melakukan perubahan dalam produksi.

Untuk informasi selengkapnya tentang mengelola kontrol gangguan, lihat Mencegah gangguan pod dan node dalam Mode Otomatis Amazon EKS.

Membatalkan rollback

Rollback berada dalam keadaan yang dapat dibatalkan hanya saat node berputar kembali. Anda dapat menggunakan CancelUpdate selama fase ini untuk menghentikan operasi.

aws eks cancel-update \
  --name my-cluster \
  --update-id <update-id> \
  --region us-west-2

Batalkan perilaku

Aspek Perilaku

Saat dapat dibatalkan

Hanya saat node Mode Otomatis sedang diputar kembali (sebelum rollback bidang kontrol dimulai)

Semantik

Best-effort berhenti. Menghentikan operasi rollback node.

Mid-disruption simpul

Jika sebuah node mengalami gangguan tengah pada waktu pembatalan, ia menyelesaikan operasinya saat ini.

Post-cancellation status

Perbarui transisi dari Cancelling keCancelled.

Status klaster

Tetap ACTIVE sepanjang.

Setelah pembatalan

Setelah pembatalan berhasil, node melayang menuju versi cluster saat ini seperti biasa. Transisi pembaruan dari Cancelling keCancelled.

Setelah pembatalan, Anda dapat segera:

  • Coba kembali rollback (selama Anda masih dalam jendela kelayakan 7 hari).

  • Lakukan pembaruan cluster yang berbeda.

  • Biarkan cluster apa adanya pada versi saat ini.

Kapan pembatalan tidak dimungkinkan

Pembatalan gagal jika rollback node sudah selesai dan rollback bidang kontrol telah dimulai, atau jika pembaruan telah selesai dengan atau status. Successful Failed

catatan

CloudFormation dan Terraform tidak secara langsung mendukung API. CancelUpdate Jika Anda perlu membatalkan rollback yang dimulai melalui IAc, Anda harus memanggil API secara langsung.

Batas waktu rollback

Rollback node Mode Otomatis memiliki batas waktu yang dapat dikonfigurasi yang dikendalikan oleh parameter di. timeoutMinutes rollbackConfig Batas waktu default adalah 720 menit (12 jam). Anda dapat menetapkan nilai antara 120 menit (2 jam) dan 10080 menit (7 hari). Batas waktu adalah properti terikat minimum, yang berarti itu terjadi tidak lebih cepat dari waktu yang Anda tentukan, tetapi dapat terjadi segera setelahnya.

aws eks update-cluster-version \
  --name my-cluster \
  --kubernetes-version 1.30 \
  --rollback-config timeoutMinutes=1440 \
  --region us-west-2

Jika semua node belum menyelesaikan rollback dalam batas waktu yang ditentukan:

  1. Waktu rollback habis.

  2. Node mulai melayang kembali ke versi cluster saat ini.

  3. Pesawat kontrol tetap pada versi saat ini (tidak pernah diputar kembali).

  4. Transisi status pembaruan keFailed.

Setelah batas waktu, Anda dapat mencoba kembali rollback jika Anda masih dalam jendela kelayakan rollback 7 hari dari upgrade asli. Dalam praktiknya, jika waktu rollback node habis pada hari ke 7, jendela kelayakan rollback kemungkinan juga kedaluwarsa karena keduanya adalah 7 hari.

Untuk menghindari batas waktu, tinjau wawasan kesiapan rollback sebelum memulai rollback. Wawasan ini memperingatkan tentang anggaran gangguan atau anotasi yang mungkin memperlambat proses rollback node.

Bendera --force dan Mode Otomatis

--forceBendera UpdateClusterVersion hanya melewati pemeriksaan wawasan klaster. Ini tidak berpengaruh pada perilaku gangguan node Mode Otomatis.

Bahkan dengan--force:

  • NodePool Anggaran gangguan masih dihormati.

  • PodDisruptionBudgets masih dihormati.

  • Do-not-disrupt anotasi masih dihormati.

  • Batas waktu rollback node 7 hari masih berlaku.

Satu-satunya cara untuk mempercepat rollback node adalah dengan menyesuaikan kontrol gangguan itu sendiri. Lihat Mempercepat rollback untuk detail.

Konflik batas waktu IAc

Infrastructure-as-Code alat memiliki batasan batas waktu yang mungkin bertentangan dengan durasi rollback Mode Otomatis. CloudFormation memungkinkan hingga 36 jam per sumber daya. Jika waktu operasi habis, CloudFormation perlakukan itu sebagai no-op, yang dapat meninggalkan cluster dalam keadaan hanyut di mana template tidak mencerminkan versi cluster yang sebenarnya. Versi rollback harus dimulai secara eksplisit. Terraform Enterprise/Cloud memiliki batas waktu sekitar 24 jam, meskipun batas waktu sisi klien dapat bervariasi tergantung pada kedaluwarsa kredenal dan faktor lainnya.

Untuk menyelaraskan durasi rollback dengan alat IAc Anda, gunakan timeoutMinutes parameter rollbackConfig untuk mengatur batas waktu yang sesuai. Jika alat IAC Anda habis waktu, gunakan CancelUpdate API secara langsung untuk mendapatkan kembali kendali. Jika Anda memiliki anggaran gangguan yang membatasi, pertimbangkan untuk memulai rollback langsung melalui CLI atau API alih-alih IAc.

Pembaruan sistem selama rollback node

Sementara node Mode Otomatis berputar kembali, EKS terus menjaga bidang kontrol tetap aman dan tersedia.

Customer-triggered pembaruan (seperti UpdateClusterVersion atau UpdateClusterConfig) diblokir saat rollback node sedang berlangsung. Jika Anda perlu melakukan pembaruan prioritas tinggi, batalkan rollback terlebih dahulu menggunakanCancelUpdate, lalu lakukan pembaruan Anda, dan mulai kembali rollback jika masih dalam jendela kelayakan.