Menguasai Runbook SRE Linux: Panduan Praktikal untuk Penyelesaian Masalah Pengeluaran

Sebagai SRE, anda tahu bahawa insiden pengeluaran tidak dapat dielakkan. Perbezaan antara gangguan kecil dan kegagalan besar selalunya bergantung pada seberapa cepat dan sistematik anda dapat mendiagnosis serta menyelesaikan isu. Runbook yang tersusun dengan baik adalah barisan pertahanan pertama anda. Dalam artikel ini, kita akan meneliti senario sebenar melibatkan nod Kubernetes yang menjadi tidak responsif akibat kubelet tergantung, menggunakan pendekatan berasaskan runbook. Anda akan mempelajari arahan praktikal, kawalan risiko, strategi rollback, dan bila untuk eskalasi kepada OpsGlobal.

Senario

Bayangkan pagi Selasa yang biasa. Tindanan pemantauan anda (Prometheus) menghantar amaran: NodeNotReady untuk node-prod-03. Nod ini menjalankan pelbagai beban kerja kritikal, termasuk API pembayaran dan replika pangkalan data. Kadar ralat API meningkat, dan beberapa pod tersekat dalam keadaan Terminating. Anda perlu bertindak pantas, tetapi juga secara teratur.

Simptom

• kubectl get nodes menunjukkan node-prod-03 sebagai NotReady.
• Pod pada nod tersebut berada dalam keadaan Pending atau Terminating.
• kubectl describe node node-prod-03 menunjukkan keadaan KubeletNotReady dengan sebab seperti PLEG is not healthy atau Docker Daemon not running.
• Beban sistem pada nod sangat tinggi (contohnya, purata beban > 100).
• Nod mungkin tidak responsif kepada SSH.

Diagnosa

Mulakan dengan arahan baca-sahaja untuk mengumpul data tanpa mengubah keadaan. Jangan terus memulakan semula tanpa memahami punca sebenar.

1. Semak Status dan Keadaan Nod

kubectl get nodes -o wide
kubectl describe node node-prod-03

Lihat bahagian Conditions. Punca biasa untuk NotReady: - KubeletNotReady dengan PLEG is not healthy (sering disebabkan oleh runtime kontena tergantung). - MemoryPressure, DiskPressure, PIDPressure, atau NetworkUnavailable.

2. Akses Nod

Jika SSH responsif, log masuk. Jika tidak, gunakan pengurusan luar jalur (contohnya, iDRAC, IPMI) atau konsol awan.

ssh sre@node-prod-03

3. Periksa Log Kubelet

Log kubelet selalunya mengandungi punca sebenar.

journalctl -u kubelet -n 200 --no-pager

Cari ralat berulang seperti PLEG is not healthy, Failed to connect to containerd, atau probe Unhealthy.

4. Semak Sumber Sistem

Jalankan top, vmstat, free -h, df -h untuk menilai CPU, memori, swap, dan cakera.

top -bn1 | head -20
vmstat 1 5
free -m
df -h

Beban CPU tinggi mungkin disebabkan oleh proses yang tidak terkawal, kernel panic OOM, atau isu infrastruktur (contohnya, gangguan jiran pada hypervisor kongsi).

5. Mesej Kernel

dmesg boleh mendedahkan pembunuhan OOM, ralat I/O cakera, atau isu perkakasan.

dmesg --time-format iso | tail -100

6. Kesihatan Runtime Kontena

Sejak Kubernetes 1.24+, runtime lalai ialah containerd. Semak statusnya.

systemctl status containerd
journalctl -u containerd -n 100 --no-pager

7. Semak Proses Zombi

Ribut proses zombi boleh merosakkan kubelet. Periksa:

ps aux | awk '$8=="Z" {print}'

Kawalan Risiko

Sebelum membuat sebarang perubahan, nilai jejari impak:

• Cordon nod untuk mengelakkan beban kerja baharu daripada dijadualkan: kubectl cordon node-prod-03.
• Jika beban kerja kritikal, pertimbangkan untuk mengosongkan (drain) nod, tetapi hanya selepas memahami isu. Pengosongan boleh menyebabkan gangguan jika perkhidmatan tidak dijadualkan semula dengan betul.
• Elakkan memulakan semula kubelet melainkan anda mempunyai alasan yang jelas. Memulakan semula kubelet mungkin tidak menyelesaikan isu sistem asas dan boleh menyebabkan kawanan pod dimulakan semula.
• Gunakan systemctl untuk memulakan semula perkhidmatan hanya jika perlu, dan sentiasa semak komponen bergantung.
• Jangan bunuh proses tanpa mengesahkan PID dan induknya. Gunakan ps -ef untuk mengesahkan.

Rollback

Jika anda membuat perubahan dan keadaan menjadi lebih teruk, anda memerlukan pelan untuk kembali.

• Jika anda memulakan semula kubelet dan nod kembali tetapi kemudian serta-merta tidak stabil, anda mungkin perlu rollback kepada kernel atau pakej sistem sebelumnya. Itu di luar skop runbook, tetapi anda perlu merekod langkah yang tepat.
• Jika anda mengosongkan nod, gunakan kubectl uncordon node-prod-03 untuk membolehkan penjadualan semula.
• Jika anda menukar sysctl atau fail konfigurasi, sandarkan fail asal (contohnya, cp /etc/sysctl.conf /etc/sysctl.conf.bak) dan pulihkannya.

Sentiasa uji rollback dalam persekitaran pementasan apabila mungkin. Dalam kecemasan, anda boleh bergantung pada sistem pengurusan konfigurasi (contohnya, Ansible, Terraform) untuk menggunakan semula keadaan yang diketahui baik.

Pengesahan

Selepas pemulihan, sahkan bahawa nod sihat dan beban kerja kembali normal.

1. Semak status nod: bash kubectl get nodes
2. Semak keadaan nod: bash kubectl describe node node-prod-03 | grep Conditions -A5
3. Sahkan pod berjalan: bash kubectl get pods --field-selector spec.nodeName=node-prod-03 -o wide
4. Pantau beban sistem dan log kubelet selama beberapa minit: bash uptime journalctl -u kubelet -f
5. Sahkan kadar ralat API kembali ke garis dasar melalui papan pemuka pemantauan anda.

Bila untuk Menyerahkan Tiker OpsGlobal

Anda boleh mengendalikan banyak insiden dengan runbook, tetapi sesetengah situasi memerlukan siasatan yang lebih mendalam. Serahkan tiker kepada OpsGlobal jika:

• Anda tidak dapat menentukan punca sebenar walaupun mengikuti panduan ini.
• Nod terus menjadi NotReady selepas beberapa kali dimulakan semula.
• Anda melihat tanda-tanda kegagalan perkakasan (contohnya, ralat smartctl, ralat ECC memori).
• Anda memerlukan bantuan dengan isu peringkat kernel atau sokongan khusus vendor.
• Insiden memberi kesan kepada perniagaan dan anda memerlukan bantuan tambahan semasa anda terus bekerja.

Di OpsGlobal, kami menyediakan sokongan DevOps dan SRE jarak jauh 24/7. Jurutera kami berpengalaman dalam penyelesaian masalah Linux dan Kubernetes. Kami boleh membantu anda membina runbook yang lebih mantap, mendiagnosis insiden kompleks, dan mengembalikan perkhidmatan anda dalam talian dengan lebih pantas.

Runbook ini adalah dokumen hidup. Kemas kini berdasarkan pengalaman yang dipelajari dalam setiap insiden. Matlamatnya adalah untuk mengurangkan MTTR dan meningkatkan keyakinan apabila pager berbunyi.