Menguasai Respons Insiden Kubernetes: Panduan Praktikal untuk Kebolehpercayaan Kluster

Senario

Deployment kritikal mengalami persaingan sumber semasa trafik tinggi, menyebabkan kependaman meningkat dan sebahagian permintaan tamat masa.

Gejala

• Kiraan but semula Pod melonjak (kubectl get pods menunjukkan CrashLoopBackOff).
• Aplikasi mengembalikan ralat 503.
• Penggunaan CPU/memori nod melebihi 80%.
• Pengguna melaporkan masa respons lambat.

Diagnosis

1. Periksa sumber nod: kubectl top nodes menunjukkan penggunaan.
2. Periksa status Pod: kubectl get pods -o wide mengenal pasti taburan Pod abnormal.
3. Selidiki Pod: kubectl describe pod <pod-name> untuk peristiwa dan had sumber.
4. Analisis log: kubectl logs <pod-name> --tail=100 untuk mencari ralat.
5. Peristiwa kluster: kubectl get events --sort-by='.lastTimestamp' untuk mencari pencetus.

Contoh Arahan

# Lihat sumber nod
kubectl top nodes

# Senarai Pod yang tidak Running merentasi namespace
kubectl get pods --all-namespaces | grep -v Running

# Huraikan deployment
kubectl describe deployment <deployment-name>

# Log ekor untuk label
kubectl logs --tail=50 -l app=<app-label>

Kawalan Risiko

• Tetapkan ResourceQuota untuk mengelakkan satu pasukan menghabiskan sumber kluster.
• Gunakan PriorityClass untuk memastikan perkhidmatan kritikal dijadualkan dahulu.
• Konfigurasikan PodDisruptionBudget untuk mengelakkan gangguan penuh semasa pengemaskinian bergulir.
• Aktifkan HorizontalPodAutoscaler untuk deployment kritikal.

Prosedur Pengembalian

# Kembali ke semakan sebelumnya
kubectl rollout undo deployment/<deployment-name>

# Kembali ke semakan tertentu
kubectl rollout undo deployment/<deployment-name> --to-revision=3

# Sahkan status pengembalian
kubectl rollout status deployment/<deployment-name>

Pengesahan

• Pantau metrik: kependaman permintaan (P99), kadar ralat, kiraan but semula Pod.
• Pelancaran canary: gunakan versi baharu pada subset kecil dan perhatikan.
• Ujian beban: simulasi trafik menggunakan hey atau wrk untuk memastikan prestasi.

Bila Hantar Tiket OpsGlobal

• Punca tidak jelas dan isu berterusan melebihi 30 minit.
• Perlukan audit peringkat kluster, contohnya pertanyaan etcd perlahan, anomali satah kawalan.
• Pasukan dalaman kurang pengalaman dalam semakan selepas insiden.
• Perlukan bantuan pakar dalam pengoptimuman sumber atau seni bina.

Pasukan SRE OpsGlobal menyediakan sokongan 24/7 untuk membantu anda pulih dengan cepat dan mencegah pengulangan.