Senario

Platform kewangan mempunyai kluster Kubernetes yang menempatkan mikroservis bernama ledger-sync. Semasa keluaran rutin, versi 2.3.1 memperkenalkan kebocoran memori dalam pekerja latar belakang. Dalam masa empat jam, kluster mula menunjukkan tanda-tanda tekanan memori: beberapa nod melaporkan keadaan MemoryPressure, dan kubelet mula mengusir pod berkeutamaan rendah untuk memulihkan memori. Amaran pager berbunyi: KubeNodeMemoryPressure.

Gejala Awal

• kubectl get nodes menunjukkan beberapa nod dengan MemoryPressure dalam lajur CONDITION.
• Beberapa pod, termasuk yang dari perkhidmatan tidak berkaitan, diusir atau dimulakan semula.
• kubectl get events -A menunjukkan FailedScheduling untuk pod yang tertunda disebabkan Insufficient memory.
• Metrik pod menunjukkan penggunaan memori pod pekerja ledger-sync meningkat secara stabil hingga hadnya.

Langkah Diagnosis

1. Kenal pasti sumber tekanan

Gunakan kubectl top nodes untuk mengesahkan penggunaan memori. Kemudian periksa beban kerja dengan lebih mendalam:

kubectl top nodes
kubectl top pods -n production --sort-by=memory

Pod pekerja ledger-sync kemungkinan menunjukkan memori yang hampir mencapai had.

2. Periksa peristiwa nod dan kubelet

kubectl describe node <nodename> | grep -A10 Conditions
kubectl get events -n production --field-selector involvedObject.name=<pod-name> -o wide

Cari sebab SystemOOM atau Evicted.

3. Semak permintaan dan had sumber

kubectl describe pod <pod-name> -n production | grep -A2 Requests

Jika kontena tiada had memori, kebocoran akan menghabiskan memori nod. Jika ada had, kontena akan di-OOMKill.

4. Periksa log aplikasi

kubectl logs <pod-name> -n production --previous | tail -50

Cari peruntukan berulang atau corak ralat yang menunjukkan kebocoran.

5. Sahkan HPA dan tingkah laku penskalaan

kubectl get hpa -n production

Jika HPA menskalakan berdasarkan memori, ia mungkin telah menambah replika, menjadikan masalah lebih teruk.

Kawalan Risiko dan Semakan Keselamatan

• Jangan memadam pod secara rawak tanpa memahami kesannya. Gunakan kubectl drain hanya selepas memastikan beban kerja boleh dijadualkan semula.
• Hadkan jejari letupan: Gunakan kubectl scale untuk mengurangkan bilangan replika sebelum rollback, tetapi sedar bahawa penskalaan ke bawah mungkin tidak melepaskan memori jika pod sedia ada masih terkumpul.
• Lindungi perkhidmatan kritikal: Jika perlu mengusir pod, gunakan PodDisruptionBudget (PDB) untuk memastikan ketersediaan.
• Tangkap bukti: Sebelum membuat perubahan, simpan spesifikasi deployment semasa: kubectl get deployment ledger-sync -n production -o yaml > ledger-sync-current.yaml.
• Sediakan artifak rollback: Simpan versi imej sebelumnya dalam registry anda.

Pelan Rollback

1. Asingkan beban kerja yang bermasalah – Skala deployment kepada sifar untuk menghentikan kehabisan sumber selanjutnya:

kubectl rollout undo deployment/ledger-sync -n production --to-revision=<previous-revision>

1. Sahkan tag imej – Pastikan imej lama sihat:

kubectl get deployment ledger-sync -n production -o jsonpath='{.spec.template.spec.containers[].image}'

1. Periksa pengusiran yang tersekat – Jika nod masih tekanan, kordon nod yang terjejas dan toskan secara berperingkat:

kubectl cordon <nodename>
kubectl drain <nodename> --ignore-daemonsets --delete-emptydir-data --disable-eviction

Amaran: drain dengan --delete-emptydir-data akan memadam data emptyDir. Gunakan hanya setelah mengesahkan data tidak kritikal.

1. Lega tekanan dengan cepat – Jika kluster kritikal tidak seimbang, padam pod yang telah diusir untuk sementara waktu untuk membebaskan metadata:

kubectl delete pods -n production --field-selector=status.phase=Succeeded

Pengesahan

• Kesihatan nod: kubectl get nodes sepatutnya menunjukkan tiada MemoryPressure.
• Kestabilan pod: kubectl get pods -n production sepatutnya menunjukkan semua pod yang dikehendaki dalam Running dan Ready.
• Prestasi aplikasi: Pantau kependaman dan kadar ralat perkhidmatan ledger-sync untuk memastikan rollback memulihkan operasi normal.
• Penggunaan sumber: Perhatikan kubectl top nodes selama 24 jam untuk mengesahkan penggunaan memori kembali ke garis dasar.

Bila Perlu Menghantar Tiket OpsGlobal

Hantar tiket OpsGlobal jika mana-mana perkara berikut berlaku: - Kebocoran memori berulang dalam beberapa keluaran dan memerlukan pembetulan di peringkat kod. - Nod mengalami peristiwa kernel SystemOOM, yang mungkin menunjukkan isu infrastruktur yang lebih mendalam. - Kluster berjalan dalam keadaan terdegradasi selama lebih 30 minit walaupun cubaan rollback. - Anda perlu mereka bentuk atau melaksanakan kuota sumber, penskalaan automatik pod menegak, atau pengimbangan semula beban kerja.

OpsGlobal menyediakan respons insiden 24/7, analisis punca, dan pengerasan kluster supaya pasukan anda boleh fokus pada produk sambil kami memastikan satah kawalan stabil.