DevOps 31/08/2026 8 phút

Chỉ dời một lệnh echo từ trước ra sau, thời gian xoá pod nhảy từ 0,6 lên 31 giây — và câu 'dùng sh -c là mất tín hiệu' hoá ra sai

Cùng một chương trình Python bắt SIGTERM, bốn cách khai lệnh, thời gian dừng chênh nhau 50 lần. Bí mật nằm ở một tối ưu hoá vô hình của shell: nếu lệnh cuối không còn gì phía sau, shell tự exec thành chính nó nên ứng dụng thành PID 1 và nhận tín hiệu; thêm một echo phía sau là shell phải ở lại giữ PID 1, và kernel bỏ qua mọi tín hiệu PID 1 không đăng ký. Thêm phép đo thứ hai nghịch trực giác: ứng dụng đóng cổng càng NHANH càng mất nhiều yêu cầu, và preStop sleep 5 đưa 3 lỗi về 0.

DevOps 31/08/2026 8 phút

ulimit thề rằng 'unlimited' — nhưng container của tôi chết đứng ở đúng 19.162 tiến trình, và cái trần đó không nằm ở chỗ ulimit nhìn

Container có hai cái trần vô hình mà nó thường chạm trước cả trần RAM. ulimit -u báo unlimited trong khi trần thật là 19.162 (pids.max của cgroup, đúng 15% threads-max) — công cụ cũ tự tin trả lời sai câu hỏi vì nó chỉ thấy cơ chế RLIMIT có từ trước cgroup. Chạm trần thì lỗi tên là EAGAIN 'thử lại sau' nhưng không bao giờ hết, nên phần lớn thư viện thử lại vô hạn và biến một cái trần cứng thành vòng lặp đốt CPU không báo lỗi. Và lời khuyên 'nhớ tăng ulimit -n' đã hết việc vì trình chạy container đặt sẵn một triệu.

DevOps 31/08/2026 8 phút

Pod in ra 400.000 dòng nhật ký, nằm sờ sờ 53 MB trên đĩa — kubectl logs trả về đúng 0 dòng, không một lời cảnh báo

kubectl logs là lệnh ai cũng gõ đầu tiên khi có sự cố — bài này đo nó thực sự đọc gì và không đọc gì. Log là tệp văn bản trên đĩa node, không qua control plane; kubectl logs chỉ đọc tệp HIỆN TẠI, nên 400.000 dòng đã xoay vòng ra file khác trả về 0 dòng không lỗi. Hệ quả đáng sợ: pod ồn ào tự xoá log của chính mình, và đúng lúc sự cố thì nó in nhiều nhất nên chính phần đầu sự cố bị đẩy ra khỏi tầm với. Thêm: containerLogMaxSize 10Mi không phải trần cứng — đo được 55 MB vì kubelet chỉ kiểm định kỳ.

DevOps 31/08/2026 8 phút

Cùng một container, kubectl top báo 12 Mi bộ nhớ còn Grafana vẽ 413 Mi — cả hai đều đúng, và biết vì sao thì bảng cảnh báo của bạn hết kêu oan

Bốn con số bộ nhớ cho một container, chênh nhau 34 lần, tất cả đều đúng vì chúng trả lời những câu hỏi khác nhau. memory.current 413 Mi gồm 400 Mi bộ đệm tệp mà kernel vứt trong tích tắc; working_set chỉ 13 Mi mới là phần OOM killer nhìn vào. Đây là nguồn của phần lớn báo động giả 'rò bộ nhớ'. Thêm: kubectl top chậm hơn thực tế 30 giây và lặp lại y hệt mẫu cũ — nó không đo, chỉ đọc lại mẫu gần nhất, nên một đợt tải ngắn hơn 15 giây có thể không lọt vào mẫu nào.

DevOps 31/08/2026 8 phút

Sự kiện cũ nhất trong cụm Kubernetes của tôi chỉ 61 phút tuổi — và 'BackOff x26' không hề nghĩa là pod khởi động lại 26 lần

Sự kiện là nơi Kubernetes tự nói ra vì sao nó làm điều vừa làm — nhưng nó tự xoá sau đúng một giờ (mặc định --event-ttl, trần cứng, không bản sao ở đâu). Đo ba cái bẫy: sự kiện hết hạn là mất sạch khác hẳn nhật ký còn trên đĩa; BackOff x26 nhưng restart thật chỉ 5 vì count đếm số lần kubelet NÓI về một tình trạng chứ không đếm số lần nó xảy ra; và sự kiện sống lâu hơn chính pod đã bị xoá, nên nó là dấu vết duy nhất trả lời 'pod của tôi đâu rồi'.

DevOps 31/08/2026 8 phút

Pod distroless không có cả sh lẫn ls, kubectl exec bó tay hoàn toàn — nhưng vẫn đọc được cấu hình và biến môi trường thật của nó qua /proc/1/root

Image càng gọn thì kẻ tấn công càng ít thứ để dùng — và bạn cũng vậy lúc gỡ rối. Khi exec vô dụng với distroless, kubectl debug luồn một ephemeral container vào ĐÚNG pod đang hỏng mà không khởi động lại gì. Đo cái bẫy lớn nhất: thiếu --target thì container gỡ rối nằm không gian PID riêng, không thấy tiến trình nào của ứng dụng (PID 1 là sh của chính nó, không phải /pause của mục tiêu). Có --target rồi thì đọc cả hệ tệp lẫn /proc/1/environ thật của container mục tiêu — thứ exec không bao giờ với tới.