Tindak Balas Insiden Kubernetes: Mengendalikan Pod OOMKilled dan Kebolehpercayaan Kluster

Senario

Kluster Kubernetes anda melaporkan lonjakan but semula pod akibat ralat kekurangan memori (OOMKilled). Pelbagai mikrosiber mengalami tamat masa, dan beberapa nod memasuki keadaan tekanan. Pasukan pembangunan mengesahkan pelepasan baru tetapi tidak pasti punca. Sebagai SRE, anda perlu bertindak balas dengan pantas untuk memulihkan perkhidmatan dan mengelakkan kehilangan data.

Gejala

• Pengguna melaporkan ralat 502 atau permintaan lambat.
• kubectl get pods menunjukkan banyak pod dalam status CrashLoopBackOff.
• kubectl describe pod <name> menunjukkan Exit Code: 137 atau Reason: OOMKilled.
• Metrik nod (cth., kubectl top node) menunjukkan penggunaan memori hampir 100%.
• Peristiwa Kubernetes (kubectl get events) menunjukkan FailedKillPod atau OOMKilling.

Diagnosa

1. Periksa status pod: Gunakan kubectl get pods --all-namespaces | grep -E 'CrashLoopBackOff|OOMKilled'.
2. Lihat peristiwa pod: kubectl describe pod <pod-name> -n <namespace> dan cari Reason: OOMKilled.
3. Periksa sumber nod: kubectl top nodes dan kubectl describe node <node-name> untuk melihat memori di bawah tekanan.
4. Lihat log kontena: kubectl logs <pod-name> --previous untuk mendapatkan log sebelum ranap.
5. Periksa konfigurasi sumber: kubectl get deployment <deployment-name> -o yaml dan lihat resources.requests dan limits.memory.

Perintah (dengan nota keselamatan)

# Senarai semua pod yang gagal
kubectl get pods --all-namespaces --field-selector=status.phase=Failed | grep -v Completed

# Dapatkan butiran untuk pod tertentu
export POD_NAME=$(kubectl get pods -n production -l app=myapp -o jsonpath='{.items[0].metadata.name}')
kubectl describe pod $POD_NAME -n production

# Lihat log dari kontena sebelumnya (penting)
kubectl logs $POD_NAME -n production --previous

# Dapatkan penggunaan sumber nod (memerlukan metrics-server)
kubectl top node

# Tingkatkan had memori untuk deployment (awas: tidak but semula, tetapi elakkan OOM pada but semula seterusnya)
kubectl set resources deployment myapp -n production --limits=memory=512Mi --requests=memory=256Mi

Nota keselamatan: Sebelum menambah had sumber, sahkan kapasiti nod menggunakan kubectl describe node untuk memeriksa memori boleh diperuntukkan.

Kawalan Risiko

• Tindakan segera: Jika perkhidmatan tidak tersedia, pertimbangkan untuk menambah sementara replika (kubectl scale deployment myapp --replicas=5) untuk menyebarkan beban.
• Hadkan keserentakan: Gunakan PodDisruptionBudget untuk mengelakkan gangguan serentak.
• Jeda auto-rollout: Jika isu disebabkan perubahan baru, hentikan saluran paip CI/CD untuk mengelakkan pelepasan selanjutnya.
• Pemantauan penggera: Sediakan penggera Prometheus untuk peristiwa OOMKilled dan tekanan memori nod.

Undur

1. Kenal pasti pelepasan bermasalah: Periksa sejarah pelepasan terkini. kubectl rollout history deployment/myapp -n production.
2. Undur ke versi stabil sebelumnya: kubectl rollout undo deployment/myapp -n production --to-revision=<previous-revision>.
3. Sahkan undur: Pantau status pod dan kadar ralat.
4. Jika undur pantas tidak boleh dilaksanakan, ubah had sumber (seperti di atas) sebagai langkah sementara.

Pengesahan

• Pod harus berjalan tanpa gelung ranap: kubectl get pods --field-selector=status.phase=Running.
• Penggunaan memori nod berkurang (cth., kubectl top node menunjukkan <80%).
• Titik akhir aplikasi mengembalikan 200: curl -I https://myapp.example.com/health.
• Peristiwa berhenti menunjukkan OOM: kubectl get events --all-namespaces | grep -i OOM.

Bila Menghantar Tiket OpsGlobal

Hantar tiket OpsGlobal jika: - Punca akar tidak jelas (cth., kebocoran memori dalam kod yang memerlukan analisis pembangunan). - Isu berterusan selepas menyesuaikan sumber, menunjukkan keperluan peningkatan skala atau perubahan seni bina. - Anda memerlukan penalaan prestasi peringkat kluster atau tindak balas insiden automatik. - Kegagalan nod atau isu satah kawalan berlaku dan memerlukan kepakaran luaran.

Jurutera OpsGlobal boleh membantu dengan analisis mendalam, melaksanakan corak kebolehpercayaan, dan strategi penskalaan automatik untuk meningkatkan ketahanan kluster.