DevOps 31/08/2026 9 phút

Hai pod cùng một dòng mã, đồ thị CPU vẽ y hệt nhau — nhưng một cái chậm gấp 23 lần, và cái chỉ số ai cũng nhìn không hề thấy điều đó

Pod chạy được nhưng chậm khó lần hơn pod hỏng hẳn, vì mọi thứ đều xanh. Hai pod khác nhau đúng mỗi limits.cpu: p50 gần như bằng nhau (4,9 so 3,9 ms) mà p95 chênh 23 lần — và ~96 ms không ngẫu nhiên, đó chính là chu kỳ 100 ms của CFS. Đồ thị 'CPU usage' vẽ hai pod trùng khít vì usage giống nhau; bằng chứng nằm ở cpu.stat: 36/50 chu kỳ bị bóp, 3,28 giây bị treo. Và từ K8s 1.33, đổi limit không cần khởi động lại pod nên p95 rơi từ 95,9 xuống 4,1 ms ngay trong lúc gỡ.

DevOps 31/08/2026 6 phút

DaemonSet hứa 'một bản trên mỗi node' — nhưng cụm 4 node của tôi chỉ có 3 bản, vì chữ 'mỗi' luôn kèm một điều kiện ẩn

DaemonSet chạy đúng một bản trên mỗi node — nghe đơn giản, nhưng 'mỗi node' có một điều kiện ẩn: node control plane bị bỏ qua vì có vết, nên cụm 4 node ra 3 bản. Thêm một dòng toleration là đủ 4. Đo tiếp: DaemonSet phản ứng với thay đổi tập node trong 0,1 giây (theo dõi qua watch) so với gần 6 phút khi node CHẾT — vì độ trễ nằm ở việc kết luận node đã chết, không phải ở việc phản ứng. Và vì sao DaemonSet không có replicas: số bản là hệ quả của số node, nó co giãn theo hạ tầng chứ không theo tải.

DevOps 31/08/2026 7 phút

kubectl báo tạo Deployment thành công, nhưng không một pod nào chạy và màn hình chỉ hiện 0/1 câm lặng — lời từ chối nằm một tầng dưới, chỗ chẳng ai nhìn

ResourceQuota biến namespace thành ranh giới tài nguyên thật. Nhưng nó chặn ở tầng POD chứ không phải tầng Deployment: create deployment báo thành công, get deployment hiện 0/1, và lý do thật giấu trong event của ReplicaSet. Đo bốn loại giới hạn — giới hạn trên object báo lỗi ngay cho người gõ lệnh, giới hạn trên pod báo lỗi ở chỗ ít ai nhìn. Cùng bài học phụ: quota tính theo requests khai báo không theo mức dùng thật, và ai có quyền xoá quota thì quota không giới hạn được họ.

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

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'.