Q

Quản trị viên

Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.

2300 bài viết · Website
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 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 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 7 phút

HPA phóng từ 2 lên 8 bản trong 30 giây, nhưng thu về mất tới 258 giây — bốn phút rưỡi ôm 8 bản ở 0% CPU, và đó là cố ý

HPA tự tăng giảm số bản theo tải — đo cả hai chiều thì chúng chênh nhau 8,6 lần. Mở rộng 30 giây (HPA tính thẳng số bản cần bằng ceil(bản × CPU/mục tiêu), không nhích từng cái), thu gọn 258 giây vì stabilizationWindow mặc định của scaleDown là 300 giây còn scaleUp là 0. Bất đối xứng này có chủ ý: mở rộng chậm thì người dùng khổ, thu gọn chậm chỉ tốn ít tiền vài phút. Thêm hai cái bẫy: thiếu requests.cpu thì HPA im lặng không bao giờ chạy, và co giãn theo bộ nhớ hiếm khi đúng vì JVM/Go không trả RAM.

DevOps 30/08/2026 9 phút

Tôi giết một node Kubernetes, ba pod chết theo — nhưng kubectl vẫn thản nhiên báo đủ 6 Running suốt gần mười phút; 'pod ma' và vì sao đếm Running là dối

kind dựng cụm 3 node trong 30 giây và 791 MB. Nhưng phép đo đáng nhớ nhất là khi tôi docker stop một worker: gần mười phút trôi qua, không pod nào được chuyển đi, và kubectl get pods vẫn báo đủ sáu Running — trong khi ba bản đã ngừng phục vụ từ giây thứ 61. Đây là lý do bảng theo dõi dựa trên đếm pod sẽ lừa bạn.

Message Queue 30/08/2026 9 phút

Kafka mặc định không bao giờ gọi fsync — bật nó lên, thông lượng còn chưa tới một phần ba; độ bền của Kafka đến từ bản sao, không đến từ đĩa

Mọi hệ lưu trữ phải trả lời: ghi vào bộ đệm hệ điều hành đã coi là an toàn chưa? Kafka trả lời khác PostgreSQL, và tôi đo cái giá: fsync mỗi lô kéo thông lượng từ 540k xuống 170k tin/giây. Kèm một câu chuyện về phép đo hình chữ U mà tôi suýt công bố — hoá ra do một lệnh tạo topic hỏng bị nuốt lỗi.