Panduan Mendalam: Menyelesaikan Masalah Runtime Kontena Docker untuk SRE

Skenario

Pukul 2 pagi. Telefon anda berbunyi. API kontena kritikal pada hos produksi telah dimulakan semula selama 20 minit. docker ps menunjukkan Restarting, docker logs kosong. Objektif Tahap Perkhidmatan (SLO) sudah berada di ambang risiko. Anda perlu bertindak cepat tetapi teratur.

Hos ini menjalankan beberapa kontena. Pasukan aplikasi melaporkan bahawa satu perkhidmatan terus dimulakan semula, tetapi tiada ralat dalam log. Beban hos sedikit tinggi, tetapi tidak mencapai kapasiti. Anda mengesyaki runtime Docker itu sendiri, bukan kod aplikasi.

Gejala

Petunjuk biasa ini membantu anda menyempitkan masalah dengan cepat:

• docker ps menunjukkan kontena dalam keadaan Restarting dengan kiraan restart yang semakin meningkat.
• docker inspect melaporkan ExitCode: 137 atau OOMKilled: true — tanda klasik untuk pembunuhan akibat kekurangan memori (OOM).
• journalctl atau dmesg mengandungi baris seperti Out of memory: Kill process atau oom-killer.
• df -h menunjukkan partition akar atau direktori data Docker /var/lib/docker penuh.
• Permulaan kontena gagal dengan ralat seperti failed to create shim task atau runc create failed.
• Kontena bermula tetapi keluar secara senyap selepas beberapa minit, tiada output dalam docker logs.

Diagnosis

Bekerja dari luar ke dalam. Ikuti urutan ini:

1. Semak Status Daemon Docker

systemctl status docker
journalctl -u docker --since "10 minutes ago"

Lihat sama ada daemon ranap akibat kekurangan sumber atau kebuntuan. Jika perkhidmatan berada dalam keadaan inactive (dead) atau dalam gelung restart, masalahnya pada tahap Docker.

2. Dapatkan Maklumat Kontena Terperinci

docker ps -a --filter "name=your-service"
docker inspect <container-id> --format '{{.State.Status}} | ExitCode={{.State.ExitCode}} | OOMKilled={{.State.OOMKilled}}'

Jika OOMKilled adalah true, kontena tersebut telah dibunuh oleh kernel OOM killer.

3. Semak Log Kernel

dmesg -T | grep -i -E "oom|killed process" | tail -20
journalctl -k --since "10 minutes ago" | grep -i oom

Perintah ini menunjukkan proses/kontena mana yang mencetuskan OOM dan bagaimana tekanan memori pada masa itu.

4. Periksa Log Kontena dan Stdout

docker logs --tail 50 <container-id>

Nota: jika kontena dimulakan semula dengan pantas, gunakan docker logs --tail 50 --timestamps untuk melihat garis masa. Kadang-kadang aplikasi menulis ke stderr tetapi pemacu log tidak menghantarnya dengan betul.

5. Semak Cakera Hos dan Penggunaan Cakera Docker

df -h
docker system df
du -sh /var/lib/docker/*

Imej, volume, atau fail log yang tidak dibersihkan boleh memenuhi cakera dan menghalang kontena daripada mencipta fail atau menulis.

6. Periksa Had cgroup

cat /sys/fs/cgroup/memory/docker/<container-id>/memory.oom_control
cat /sys/fs/cgroup/memory/docker/<container-id>/memory.limit_in_bytes
cat /sys/fs/cgroup/pids/docker/<container-id>/pids.current

Sahkan sama ada had memori dan PID kontena terlalu rendah. Jika hos itu sendiri kekurangan memori, kontena boleh tetap dibunuh walaupun hadnya longgar.

7. Sahkan Komponen Runtime (containerd/runc)

docker info | grep -i runtime
systemctl status containerd

runc atau containerd yang rosak akan menghalang kontena daripada dimulakan.

Kawalan Risiko

Sebelum memulakan pemulihan, kurangkan kesan sampingan:

• Elakkan memulakan semula daemon: systemctl restart docker akan mengganggu semua kontena kecuali anda bersedia untuk mengasingkan risiko.
• Utamakan arahan hanya-baca: inspect, logs, dan dmesg tidak mengubah keadaan.
• Simpan bukti: Simpan output docker inspect, dmesg, dan journalctl untuk analisis kemudian.
• Keluarkan nod dari beban: Jika hos menjalankan replika, tandakan nod sebagai "maintenance" dalam pengimbang beban (cth., Nginx/LVS) dan kemudian debug dengan tenang.

Strategi Rollback

Jika masalah bermula selepas perubahan terkini, rollback pantas adalah langkah paling selamat:

• Tukar tag imej: Jika latest baru sahaja dikemas kini, pergi semula ke versi stabil sebelumnya, contohnya v1.0.1.
• Laraskan parameter kontena: Jika had memori terlalu rendah, cipta semula kontena dengan --memory dan --memory-swap yang lebih besar.
• Cipta semula kontena: Gunakan docker run dan bukannya docker start untuk mengekalkan mount dan tetapan rangkaian.

Sebelum rollback, sahkan bahawa tag imej lama masih ada secara tempatan (docker images).

Pengesahan

Selepas pembaikan, jangan hanya semak proses masih hidup:

docker ps --filter "status=running" --filter "name=your-service"
docker inspect --format '{{.State.Status}}, RestartCount={{.RestartCount}}' <container-id>

Kemudian uji fungsi sebenar:

curl -f http://localhost:8080/healthz

Perhatikan sekurang-kurangnya 15 minit untuk memastikan tiada OOM atau restart berulang. Gunakan docker stats untuk memantau sumber:

docker stats --no-stream <container-id>

Pastikan penggunaan memori kekal di bawah 60% daripada had dan CPU berada dalam jangkaan.

Bila Untuk Menghantar Tiket OpsGlobal

Jika anda menghadapi mana-mana keadaan berikut, jangan terus debug dalam gelap — buka tiket dengan segera:

• Anda telah mengikuti semua langkah di atas tetapi isu masih belum selesai dalam masa 1 jam.
• Isu memerlukan penalaan parameter kernel (cth., vm.overcommit_memory) atau terdapat disyaki bug runc/containerd.
• Banyak kontena pada hos yang sama terjejas, dan kesannya besar.
• Anda mengesyaki masalah perkakasan atau isu pemacu aras rendah, seperti device mapper yang rosak.

Pakar SRE OpsGlobal boleh mengambil alih dalam masa 15 minit, menyediakan sokongan jauh 24/7 untuk melindungi SLO dan integriti data anda.