Respons Insiden Kubernetes: Mengendalikan Tekanan Memori dan Pengusiran Pod

Senario

Bayangkan anda mengendalikan kluster Kubernetes dalam pengeluaran, dan tiba-tiba banyak amaran berbunyi: beberapa nod melaporkan MemoryPressure, pod sedang diusir, dan aplikasi menjadi tidak stabil. Ini adalah insiden biasa tetapi menekan. Tanpa playbook yang jelas, anda berisiko memburukkan keadaan. Artikel ini membimbing anda melalui insiden tekanan memori yang realistik, memberikan arahan berguna dan titik keputusan untuk memulihkan perkhidmatan dengan selamat.

Gejala dan Amaran

Gejala biasa termasuk:

• Keadaan nod menunjukkan MemoryPressure atau NotReady.
• Pod berulang kali diusir (status Evicted atau Failed).
• Pemeriksaan kesihatan aplikasi gagal, peningkatan kependaman, atau ralat kepada pengguna.
• Sistem amaran (Prometheus, DataDog, dll.) menghantar notifikasi MemoryPressure, NodeNotReady, atau PodEvicted.

Aliran Diagnosis

1. Nilai Keadaan Kluster

Mula dengan mendapatkan pandangan global:

kubectl get nodes
kubectl get pods -A -o wide

Jika banyak nod NotReady, masalah mungkin berkaitan dengan satah kawalan. Jika hanya beberapa nod terjejas, fokus pada kehabisan sumber peringkat nod.

2. Periksa Keadaan Nod

Gunakan describe untuk memeriksa status nod:

kubectl describe node <nama-nod>

Lihat bahagian Conditions, terutamanya sama ada MemoryPressure adalah True. Juga semak Allocated resources untuk melihat permintaan/ had versus beban sebenar.

3. Semak Penggunaan Sumber pada Tahap Nod dan Pod

Gunakan arahan top untuk metrik langsung:

kubectl top node
kubectl top pods -A --sort-by='memory'

Kenal pasti pengguna memori tertinggi. Jika penggunaan memori pod jauh melebihi hadnya, kemungkinan berlaku kebocoran memori atau saiz heap yang terlalu besar.

4. Semak Events dan Log Kubelet

Events merekodkan pengusiran:

kubectl get events --sort-by='.lastTimestamp' -A | grep -i evict

Periksa log kubelet (laluan mungkin berbeza mengikut pengedaran):

journalctl -u kubelet -n 100 --no-pager

Log ini selalunya mengandungi Evicting dan MemoryPressure yang menjelaskan keputusan.

Kawalan Risiko Segera dan Mitigasi

1. Hadkan Skop Kesan

• Jangan padam semua replika: Jika aplikasi tanpa keadaan dan berbilang replika, pastikan sekurang-kurangnya satu replika sihat.
• Gunakan PodDisruptionBudgets (PDB): Jika belum dikonfigurasi, buat PDB untuk beban kerja kritikal sebelum sebarang gangguan sukarela (contohnya, drain).
• Simpan sandaran konfigurasi: Sebelum membuat perubahan, simpan definisi sumber semasa untuk membolehkan pengembalian.

2. Kurangkan Tekanan Nod Serta-merta

Jika nod tertentu mengalami tekanan memori, anda boleh:

• Padam pod yang tidak perlu secara manual: bash kubectl delete pod <nama-pod> -n <namespace>
• Pertimbangkan untuk membuang atau menjeda kerja batch berkeutamaan rendah.
• Selamatkan drain nod selepas memastikan PDB wujud: bash kubectl drain <nama-nod> --ignore-daemonsets --delete-emptydir-data Nota keselamatan: Drain menyebabkan nod tidak boleh dijadualkan. Lakukan semasa waktu lalu lintas rendah dan ingat untuk uncordon kemudian.

3. Laraskan Permintaan dan Had Sumber Beban Kerja

Periksa spesifikasi sumber aplikasi yang bermasalah. Jika requests dan limits tiada, penjadual tidak dapat mengagihkan sumber dengan cekap, dan kubelet mungkin mengusir pod akibat OOM. Kemas kini manifes:

resources:
  requests:
    memory: "512Mi"
    cpu: "500m"
  limits:
    memory: "1Gi"
    cpu: "1"

Gunakan kemas kini dan mulakan semula deployment:

kubectl rollout restart deployment/<nama-app> -n <namespace>

4. Skala Naik Kapasiti

Jika kluster penuh, tambah nod atau aktifkan autoscaling. Pada Kubernetes terurus, laraskan kumpulan nod. Dalam persekitaran awan, sahkan kluster autoscaler berfungsi.

Strategi Pengembalian

Jika perubahan yang anda buat memburukkan insiden, kembalikan dengan segera:

• Kembalikan Deployment: bash kubectl rollout undo deployment/<nama-app> -n <namespace>
• Kembalikan konfigurasi: Pulihkan fail konfigurasi kluster atau kubelet yang disandarkan dan mulakan semula komponen terjejas.

Jika anda telah drain nod, aktifkan semula penjadualan selepas mengesahkan isu diselesaikan:

kubectl uncordon <nama-nod>

Pengesahan dan Semakan Selepas Insiden

1. Sahkan Pemulihan Kluster

• Semak status nod: bash kubectl get nodes Pastikan semua nod Ready dan bebas daripada tekanan.
• Semak status pod: bash kubectl get pods -A | grep -v Running Pastikan tiada pod tersekat dalam Pending atau Evicted.
• Pantau kesihatan aplikasi melalui papan pemuka atau ujian permintaan langsung.

2. Jalankan Postmortem Tanpa Menyalahkan

• Bina semula garis masa dan kenal pasti punca (perubahan deploy, lonjakan trafik, kebocoran memori).
• Gunakan kubectl describe node dan metrik sejarah untuk menganalisis trend.
• Tentukan tindakan: tetapkan had sumber sesuai, tambah PDB, laraskan ambang amaran, dan pertimbangkan autoscaling kluster.

Bila Perlu Menghubungi OpsGlobal

Pasukan sokongan DevOps/SRE jauh OpsGlobal boleh membantu dalam situasi berikut:

• Kluster mati dan anda kekurangan liputan 24/7 untuk bertindak segera.
• Punca utama adalah kompleks (kernel, kubelet, atau isu penyedia awan) dan pasukan anda memerlukan kepakaran senior.
• Anda perlu memulihkan pengeluaran dengan cepat tanpa risiko kesilapan daripada operasi peringkat rendah.
• Anda ingin membina sistem kebolehpercayaan yang lebih mantap: playbook, penambahbaikan pemantauan, dan latihan kegagalan.

Jika mana-mana berkenaan, serahkan tiket OpsGlobal. Jurutera kami akan bertindak dalam beberapa minit dan memberikan sokongan jauh secara langsung untuk menstabilkan kluster anda.

Kesimpulan

Respons insiden Kubernetes memerlukan pendekatan yang tenang dan sistematik. Senario tekanan memori ini hanyalah satu contoh, tetapi menguasai langkah-langkah ini menyediakan anda untuk banyak isu sumber kluster. Ingat: mitigasi cepat, operasi selamat, dan postmortem menyeluruh adalah tonggak kebolehpercayaan kluster.