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.

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 7 phút

Xoá pod db-1 của StatefulSet rồi để nó dựng lại: IP đổi, nhưng tên, PVC và dữ liệu 'du lieu cua db-1' còn nguyên vẹn — đó là cả điểm khác biệt với Deployment

Deployment giả định các bản thay thế được cho nhau; với cơ sở dữ liệu thì không. Đo ba thứ StatefulSet có mà Deployment không: khởi động tuần tự (4,3 / 9,6 / 14,9 giây, chờ bản trước), danh tính ổn định (tên DNS và PVC riêng cho từng bản — xoá pod rồi dựng lại thì chỉ IP đổi, dữ liệu còn), và thu gọn không xoá PVC (an toàn dữ liệu nhưng vẫn trả tiền đĩa). Cùng cái bẫy nguy hiểm nhất: node chết thì StatefulSet CHỜ, vì hai bản cùng tên ghi cùng dữ liệu là hỏng — và --force là lời cam đoan 'bản cũ đã chết' mà nếu sai thì mất dữ liệu.

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

Tôi cấp một ServiceAccount đúng quyền 'chỉ đọc' Secret — rồi đọc ra ngay SieuBiMat123, và ba quyền nghe vô hại khác hoá ra tương đương quyền quản trị

Cấp quyền từng lớp cho một ServiceAccount rồi đo chính xác nó mở ra được gì. Role bó rất chặt (đúng động từ, đúng tài nguyên, đúng namespace), nhưng 'chỉ đọc' Secret là đọc được mọi mật khẩu vì base64 không phải mã hoá. Ba quyền nghe vô hại trong một bản YAML — create pods, get secrets, create rolebindings — đều là đường leo thang lên quyền toàn cụm. Và kubectl auth can-i là cách duy nhất kiểm quyền thực tế thay vì đọc YAML rồi đoán.

DevOps 31/08/2026 7 phút

Manifest khai cpu=50m nhưng pod chạy với cpu=410m — VPA sửa con số giữa đường, và kubectl get deployment vẫn thản nhiên hiện số cũ

HPA thêm bản, VPA sửa requests của từng bản. Đo VPA trên cụm thật: khuyến nghị đầu tiên sau ~60 giây (target 410m dùng được, nhưng upperBound 8.856 nhân là vô nghĩa vì chưa đủ lịch sử). Auto mode làm hai việc dễ tưởng là một: bộ admission ghi đè requests lúc tạo pod (manifest 50m → pod 410m, mà get deployment vẫn hiện 50m — vỡ nguồn-sự-thật của GitOps), và bộ updater chỉ giết pod khi requests nằm NGOÀI khoảng tin cậy. Vì sao VPA hay trông như không làm gì, và vì sao VPA với HPA-theo-CPU đá nhau.