DEV Community

Alex Carter
Alex Carter

Posted on

Pod bị OOMKilled trong Kubernetes: chẩn đoán nhanh và cách fix bền vững

Nếu bạn làm DevOps/SRE, kiểu gì cũng gặp những tình huống đau đầu giống nhau: pipeline lúc xanh lúc đỏ, cảnh báo kêu cả đêm, hoặc lỗi chỉ xuất hiện ở production.

Bài này tập trung vào Kubernetes OOMKilled: dấu hiệu nhận biết, cách debug nhanh, và các biện pháp phòng tránh để hệ thống ổn định hơn.

Vấn đề nhiều người gặp

  • Triệu chứng không ổn định: hôm nay fail, mai lại pass.
  • Khó tái hiện (reproduce) lỗi ở máy local.
  • Debug tốn thời gian vì thiếu dữ liệu (logs/metrics/traces).

Nguyên nhân gốc (root causes) thường gặp

  1. Môi trường chạy không đồng nhất (dependency drift, config khác nhau).
  2. Thiếu kiểm soát dữ liệu test (seed data / time / network).
  3. Race condition hoặc test phụ thuộc thứ tự.
  4. Thiếu quan sát (observability) khiến bạn đoán mò.

Cách giải quyết (thực chiến)

1) Chuẩn hoá môi trường chạy

  • Dùng container để “đóng gói” runtime.
  • Pin phiên bản dependency (lockfile) và base image.

2) Tách lớp test và đặt kỳ vọng hợp lý

  • Unit test: nhanh, ít phụ thuộc.
  • Integration test: có thể chậm nhưng phải deterministic.
  • E2E: chạy ít hơn, ưu tiên các luồng critical.

3) Bổ sung quan sát để debug nhanh hơn

  • Metrics: tỉ lệ fail theo thời gian, theo commit.
  • Logs: log có correlation id.
  • Traces: thấy request đi qua service nào, nghẽn ở đâu.

Nếu bạn chưa dùng, OpenTelemetry là bước khởi đầu rất đáng giá: đọc docs tại https://kubernetes.io/docs/.

4) Checklist chống “fail vặt”

  • [ ] Test không phụ thuộc thời gian thực (inject clock)
  • [ ] Không phụ thuộc network ngoài (mock hoặc record/replay)
  • [ ] Không dùng shared mutable state giữa test
  • [ ] Có retry có kiểm soát và có thống kê tần suất

3 FAQ

FAQ 1: Khi nào nên bật retry cho test?

Chỉ nên retry khi bạn đo được flaky rate và retry có giới hạn. Nếu retry che lấp lỗi thật, bạn sẽ trả giá ở production.

FAQ 2: Làm sao chứng minh test flaky hay code flaky?

Chạy lại cùng commit nhiều lần trong cùng môi trường. Nếu kết quả dao động, ưu tiên điều tra nondeterminism trong test/môi trường.

FAQ 3: Nên ưu tiên logs hay metrics?

Bắt đầu với metrics để thấy xu hướng và đặt alert đúng. Sau đó logs/traces giúp drill-down khi có sự cố.

Bài trong series

Tài liệu tham khảo

Top comments (0)