Tindak Balas Insiden Kubernetes: Menangani Tekanan Cakera Nod dan Mengekalkan Kebolehpercayaan Kluster

Senario

Tengah malam, telefon anda berbunyi: amaran P1 daripada PagerDuty menunjukkan kadar ralat perkhidmatan checkout meningkat melebihi 2%. Apabila anda log masuk ke kluster, anda mendapati beberapa Pod ditamatkan, ada yang berada dalam keadaan CrashLoopBackOff, dan satu nod pekerja melaporkan DiskPressure. Ini adalah insiden biasa yang berisiko tinggi—jika ditangani tanpa berhati-hati, ia boleh menyebabkan penghalauan (eviction) secara meluas dan kehilangan data.

Gejala

• Pengguna melihat ralat 503 atau 504.
• Amaran Prometheus HighErrorRate berbunyi.
• kubectl get pods -n checkout menunjukkan banyak Pod CrashLoopBackOff atau Evicted.
• kubectl get nodes menunjukkan nod dengan keadaan DiskPressure.
• Peristiwa Kubelet termasuk mesej The node was low on resource: disk.

Diagnosis

1. Mula dengan menyemak peristiwa terbaru dalam kluster:

bash kubectl get events --all-namespaces --sort-by=.lastTimestamp

1. Periksa keadaan nod:

bash kubectl describe node worker-3 | grep -A5 Conditions

Jika DiskPressure=True, nod kehabisan ruang cakera atau inode.

1. Akses nod (atau gunakan kubectl debug node/worker-3 -it --image=busybox) dan semak penggunaan cakera:

bash df -h df -i

1. Kenal pasti Pod yang menggunakan cakera: lihat peristiwa Pod yang dihalau:

bash kubectl describe pod checkout-xyz -n checkout | grep -A3 Events

1. Semak log container untuk penulisan yang berlebihan atau tidak diputar:

bash kubectl logs checkout-xyz --previous -n checkout | tail -100

1. Semak log kubelet pada nod untuk mengesahkan keputusan penghalauan:

bash journalctl -u kubelet --since "30 min ago" | grep -i evict

Kawalan Risiko dan Nota Keselamatan

• Jangan sekali-kali memadam PersistentVolume (PV) atau PersistentVolumeClaim (PVC) melainkan anda telah mengesahkan sandaran. Penghalauan Pod boleh dipulihkan, tetapi kehilangan data adalah kekal.
• Jangan gunakan kubectl delete node untuk memaksa buang nod; ini menjadikan beban kerja tidak boleh dijadualkan dan boleh menyebabkan masalah dengan Cloud Controller Manager.
• Jika menggunakan kubectl drain, elakkan --ignore-daemonsets=false kecuali anda memahami kesannya terhadap daemonset kritikal.
• Jangan padam Pod secara rawak; gunakan kubectl delete pod hanya jika beban kerja diurus oleh Deployment/StatefulSet, dan lebih baik gunakan kubectl rollout restart jika perlu.

Rollback

Jika anda mengecilkan Deployment sebagai langkah sementara, kembalikan kepada bilangan replika asal:

kubectl scale deployment checkout --replicas=3

Jika anda mengubah had sumber atau permintaan, gunakan kubectl rollout undo deployment/checkout untuk kembali ke versi sebelumnya.

Oleh kerana kami tidak mengubah infrastruktur, kebanyakan tindakan rollback adalah untuk mengembalikan sebarang pelarasan sementara yang anda lakukan.

Pengesahan

• Pastikan Pod berjalan dan sedia: kubectl get pods -n checkout menunjukkan semua Running dan Ready.
• Semak keadaan nod: kubectl describe node worker-3 | grep -A3 Conditions menunjukkan DiskPressure=False.
• Sahkan kadar ralat aplikasi menurun dalam Grafana atau papan pemantauan.
• Semak log terkini: kubectl logs -n checkout deployment/checkout --tail=20.

Bila Perlu Menghubungi OpsGlobal

Anda perlu segera menghubungi OpsGlobal jika:

• Anda mengesyaki isu pesawat kawalan (etcd tidak sihat, API Server tidak responsif, atau ralat etcdserver: request timed out).
• Beberapa nod serentak masuk ke keadaan NotReady.
• Tekanan cakera berterusan lebih daripada 30 minit walaupun mitigasi telah dilakukan.
• Anda melihat tanda-tanda rasuah data berterusan atau risiko kehilangan PVC/PV.
• Anda tidak pasti tentang punca dan memerlukan pandangan pakar kedua.

OpsGlobal menyediakan sokongan 24/7 untuk membantu anda menstabilkan kluster kritikal dan mengelakkan insiden berulang.