DevOps 31/08/2026 7 phút

Tín hiệu 'cụm cần thêm máy' sinh ra sau 0,2 giây, dọn một node hết 14,3 giây — còn khúc giữa tôi không đo được, và tôi nói thẳng điều đó

HPA thêm pod, Cluster Autoscaler thêm NODE khi hết chỗ. Đo hai đầu của vòng lặp trên cụm thật: pod vào Pending sau 0,2 giây, drain một node hết 14,3 giây. Còn khúc giữa — nhà cung cấp đám mây thật sự tạo ra một máy — thì kind không dựng được, nên tôi không có số đo và không mượn số của người khác rồi gọi là phép đo. Bài học rơi ra: hai đầu đều nhanh, toàn bộ thời gian chờ nằm ở khúc bạn không kiểm soát — nên tối ưu thời gian cụm phản ứng thì đừng nhìn Kubernetes, hãy nhìn thời gian khởi động máy và kéo ảnh.

DevOps 31/08/2026 8 phút

Ba lỗi mạng hoàn toàn khác nhau trong Kubernetes cho ra đúng một thông báo và đúng một thời gian — và một lệnh duy nhất phân biệt được cả ba

Nhãn sai, cổng sai, pod chưa sẵn sàng — ba nguyên nhân khác hẳn nhau nhưng đều ra ConnectionRefused ~0 ms, và DNS thì phân giải tốt ở cả ba nên nslookup chẳng chứng minh gì. Đo cách một bảng endpointslices tách được ba bệnh cùng triệu chứng, và vì sao khác biệt Refused-ngay-lập-tức so với Timeout-đúng-hạn-chờ (3004 ms khi bật NetworkPolicy) là phép chia đôi tốt nhất khi lần lỗi mạng.

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

DevOps 31/08/2026 7 phút

Ai cũng bảo nginx non-root chết vì không mở nổi cổng 80 — tôi đo thì cổng 80 mở ngon lành, thứ giết nó là một lệnh mkdir

Thêm runAsUser: 1000 vào nginx thì pod chết — nhưng không phải vì cổng. Log chỉ thẳng: lỗi mkdir /var/cache/nginx, tức lỗi ghi hệ tệp, sửa bằng chown chứ chẳng cần đặc quyền gì. Đo tiếp cái ai cũng lặp lại 'cổng dưới 1024 cần root hoặc NET_BIND_SERVICE': uid 1000 mở cổng 80 vẫn được, capability kia chẳng làm gì, vì ip_unprivileged_port_start trong netns container là 0. Và một lần thử fsGroup không tái tạo nổi lỗi vì thư mục emptyDir là 0777 — bài học về phép thử dễ dãi cho kết quả xanh vô nghĩa.

DevOps 31/08/2026 7 phút

Mức restricted của Kubernetes từ chối thẳng một pod nginx hoàn toàn vô hại — không vì nó nguy hiểm, mà vì nó không chịu khai rằng mình an toàn

Pod Security Standards bật bằng đúng một nhãn namespace, không cài gì thêm. Đo trên cùng một pod ở ba mức: restricted từ chối cả một nginx bình thường, và toàn văn lời từ chối cho thấy lý do — nó đòi bốn dòng securityContext khai báo tường minh, vì mặc định của Kubernetes là mở (chạy root, giữ đủ capability, cho leo thang quyền) nên im lặng bị coi là nguy hiểm. Thêm cái bẫy: enforce chỉ xét lúc TẠO pod nên pod vi phạm đang chạy vẫn sống, và sự cố chỉ nổ ở lần deploy hoặc scale tiếp theo.