Tindak Balas Insiden Kubernetes: Panduan Praktikal untuk Tekanan Node dan Pengusiran Pod

Senario

Pada pukul 2 pagi, alert Prometheus berbunyi. Kelompok Kubernetes pengeluaran anda sedang melayan microservice kritikal, tetapi latensi p99 meningkat dan muncul beberapa 503. Pemeriksaan awal mendapati satu node pekerja berstatus NotReady, manakala node lain mengalami MemoryPressure dan DiskPressure. Persaingan sumber jelas menyebabkan kelompok tidak stabil, dan pod sedang diusir—tetapi punca sebenar masih tidak diketahui.

Gejala

• Masa tindak balas meningkat dan terdapat permintaan yang tamat masa.
• Keadaan node bertukar kepada MemoryPressure atau DiskPressure.
• kubectl get events dipenuhi dengan mesej Evicted dan OOMKilling.
• Pod kerap dimulakan semula, dengan CrashLoopBackOff muncul pada perkhidmatan kritikal.
• kubectl top nodes menunjukkan satu atau lebih node menggunakan melebihi 90% CPU atau memori.

Diagnosis

Diagnosis berstruktur membezakan antara kelebihan node dan pod yang tidak terkawal. Mula dengan pandangan global, kemudian mendalami.

1. Pemeriksaan kesihatan kelompok: Jalankan kubectl get nodes dan kubectl get events --all-namespaces --sort-by=.lastTimestamp.
2. Gambaran penggunaan sumber: Guna kubectl top nodes dan kubectl top pods -A untuk mengesan kawasan tumpuan.
3. Pemeriksaan keadaan node: kubectl describe node <node> | grep -A20 'Conditions' mendedahkan keadaan tekanan dan taint.
4. Perincian pada tahap pod: Untuk beban yang mencurigakan, periksa kubectl describe pod <pod> -n <namespace> dan kubectl get pod <pod> -o yaml.
5. Pemeriksaan pengembangan HPA: Jika autoscaling digunakan, jalankan kubectl get hpa -A dan semak nilai min/maks.
6. Metrik sejarah: Gunakan pertanyaan Prometheus seperti node_memory_available dan container_cpu_usage_seconds_total untuk melihat trend.

Arahan

# Pemeriksaan kesihatan pantas
kubectl get nodes -o wide
kubectl get events --all-namespaces --sort-by=.lastTimestamp

# Penggunaan sumber teratas
kubectl top nodes
kubectl top pods -A

# Periksa tekanan node
kubectl describe node <node> | grep -A20 'Conditions'

# Periksa pod bermasalah
kubectl get pod <pod> -n <namespace> -o yaml
kubectl describe pod <pod> -n <namespace>

# Gelagat HPA
kubectl get hpa -A
kubectl describe hpa <hpa-name> -n <namespace>

# Kesihatan API metrik
kubectl get apiservices | grep metrics

Nota keselamatan: Sebelum sebarang tindakan merosakkan (cth., memadam node atau pod), sahkan bilangan replika semasa dan pastikan ketersediaan minimum. Jangan sekali-kali padam node secara sembarangan; cordon dan drain adalah lebih selamat.

Kawalan Risiko

1. Jangan padam node dengan segera—pengusiran berantai boleh menjejaskan kelompok.
2. Elakkan but semula global: kubectl rollout restart boleh menambah beban; lakukan pada waktu trafik rendah jika perlu.
3. Pencilkan node yang tidak stabil: kubectl cordon <node> menghentikan pod baru, kemudian drain secara beransur-ansur dengan kubectl drain --ignore-daemonsets.
4. Kurangkan trafik masuk: Alihkan trafik dari node yang terjejas menggunakan service mesh atau peraturan ingress.
5. Laraskan had HPA: Tetapkan had keras untuk replika bagi mengelakkan autoscaling yang tidak terkawal.

Pembalikan

Jika insiden berpunca daripada perubahan terkini, pembalikan perlu dilakukan terlebih dahulu.

• HPA: Kembalikan nilai min/maks sebelumnya, atau padam HPA untuk kunci bilangan replika.
• Imej Deployment: Jalankan kubectl rollout undo deployment/<name> untuk kembali ke imej yang stabil.
• Kuota sumber: Jika LimitRange atau ResourceQuota salah konfigurasi, hasilkan semula YAML asal.
• Drain manual: Jika drain tersekat, batalkan atau selesaikan dengan kubectl uncordon selepas menyelesaikan isu belanjawan gangguan pod.

Pengesahan

Pemulihan bukan sekadar melihat status hijau—pastikan punca sebenar telah dihapuskan.

• Semua node melaporkan Ready dan tiada keadaan tekanan berterusan.
• kubectl get events tidak lagi menunjukkan Evicted atau OOMKilled baharu.
• Metrik latensi kembali ke garis dasar; tiada 503.
• Perhatikan gelagat skala HPA untuk beberapa minit untuk memastikan kestabilan.

Bila Menghantar Tiket ke OpsGlobal

Serahkan kepada OpsGlobal jika:

• Insiden berlarutan lebih 30 minit dan punca masih tidak jelas.
• Pod berada dalam CrashLoopBackOff dan tidak dapat dibaiki sendiri.
• Anda mengesyaki masalah infrastruktur asas tetapi tiada akses platform.
• Pasukan anda keletihan dan memerlukan sokongan SRE 24/7.

Apabila membuka tiket, lampirkan output utama kubectl get nodes, kubectl describe node, dan log peristiwa. Jurutera OpsGlobal boleh bertindak dengan cepat dengan maklumat tersebut.