Senario

Pukul 3:14 pagi, pager anda berbunyi. Kluster produksi yang menjalankan beban e-dagang berhadapan pelanggan sedang menurun. Pengguna melihat ralat 503, dan papan pemuka SRE menunjukkan lonjakan pod yang diusir. Anda mempunyai tiga nod dalam kumpulan ubuntu-west1-a, dua dalam ubuntu-west1-b, dan tiada orang lain yang berjaga. Ini adalah peristiwa kebolehpercayaan Kubernetes klasik: tekanan nod, beban kerja tidak dapat dijadualkan, dan kegagalan bertingkat.

Gejala

• Pod berulang kali dimulakan semula atau tersekat dalam status Pending.
• Nod memaparkan keadaan Pressure (MemoryPressure, DiskPressure, atau PIDPressure).
• Pengusiran gagal dalam kubectl get events.
• Latensi API server meningkat.
• kubectl top nodes mungkin menunjukkan CPU hampir sifar tetapi memori tinggi.

Diagnosis

Sempitkan skop isu dengan cepat tanpa membuat perubahan. Jalankan pemeriksaan status dahulu:

• kubectl get nodes -o wide – perhatikan status nod dan taint.
• kubectl describe node <node> – periksa bahagian Conditions. Cari MemoryPressure=True atau DiskPressure=True.
• kubectl top node – cari siapa yang menggunakan sumber daya.
• kubectl get pods --all-namespaces -o wide – lihat pod mana sedang berjalan dan mana dalam keadaan Error/OOMKilled.

Kemudian fokus pada pod yang terjejas:

• kubectl get pod <pod> -n <ns> -o yaml – lihat lastState.terminated.reason (biasanya OOMKilled atau Evicted).
• kubectl logs <pod> -n <ns> --previous – lihat log aplikasi sebelum ranap.

Arahan untuk Menghentikan Pendarahan

Jangan panik dan jangan memadam semua secara membuta tuli. Gunakan arahan berikut untuk menstabilkan:

# 1. Cordon nod yang tidak sihat untuk menghalang pod baharu diterbangkan kepadanya
kubectl cordon <node>

# 2. Drain nod untuk mengusir pod secara selamat (akan menghormati PDB)
#    Tambah --ignore-daemonsets jika terdapat DaemonSet seperti agen log
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data

Drain akan mengusir pod, tetapi jika PodDisruptionBudget salah dikonfigurasi, ia mungkin tergantung. Tambah tempoh tamat: --grace-period=120.

Jika tekanan memori adalah punca, kurangkan bilangan replika atau skala turun beban kerja bukan kritikal:

kubectl scale deploy <non-critical-deploy> --replicas=0 -n <ns>

Kawalan Risiko

• Jangan sekali-kali drain nod tanpa --ignore-daemonsets jika DaemonSet wujud.
• Gunakan --delete-emptydir-data hanya apabila anda pasti pod tidak memerlukan data emptyDir.
• Gunakan PodDisruptionBudget (PDB) untuk memastikan ketersediaan minimum semasa drain.
• Sebelum pemadaman paksa, periksa sama ada pod adalah sebahagian daripada StatefulSet. Memadam pod yang disokong PVC mungkin selamat, tetapi anda akan kehilangan keadaan cakera tempatan.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: frontend-pdb
  namespace: prod
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: frontend

Penggulungan Semula (Rollback)

Jika penggunaan terkini mencetuskan peristiwa tersebut, gulung semula sebelum menyiasat lebih dalam:

kubectl rollout undo deployment/<deployment> -n <namespace>

Jika kluster berada dalam keadaan buruk (beberapa nod ke bawah), gunakan pelan pemulihan bencana kluster. Untuk kubeadm atau kluster terurus, anda tidak boleh menyertai semula nod pekerja sedia ada tanpa membaiki runtime kontena.

Pengesahan

Selepas cordon/drain/gulung semula:

kubectl get nodes -o wide
kubectl get pods --all-namespaces -o wide | grep -v Running
kubectl get evictions -n <ns>

Uji titik akhir aplikasi secara luaran:

curl -I https://app.example.com/healthz

Semak kadar ralat dan latensi dalam pemantauan. Pastikan kluster stabil selama sekurang-kurangnya 10-15 minit sebelum menganggap insiden selesai.

Bila Perlu Hantar Tiket OpsGlobal

Anda boleh mengendalikan banyak insiden bersendirian, tetapi hubungi pakar OpsGlobal apabila:

• Lebih daripada satu nod tidak tersedia dan anda tidak pasti perkhidmatan mana yang menjadi punca.
• Anda melihat cakera penuh berterusan selepas pengusiran, atau penggunaan semula overlay Docker gagal.
• Kluster berjalan dengan konfigurasi kubelet tersuai yang anda tidak tulis sendiri.
• Anda perlu memulihkan sandaran etcd atau membina semula satah kawalan.
• Insiden masih tidak jelas selepas 60 minit penyahpepijatan aktif.

Jurutera kami menjawab dalam masa 15 minit dan boleh membantu anda mencegah berulang dengan menyemak permintaan sumber, pemantauan, dan ujian beban.