DevOps 30/08/2026 7 phút

Định tuyến Ingress theo tên miền chạy ngay, còn theo đường dẫn thì trả 404 — và nó hoàn toàn đúng đặc tả, chỉ có kỳ vọng của tôi là sai

Service cho một IP một dịch vụ; Ingress cho một điểm vào nhiều dịch vụ, phân biệt bằng tên miền hoặc đường dẫn ở tầng HTTP. Đo cái giá: thêm một chặng proxy mà độ trễ không đo được (0,28 so 0,29 ms), nhưng định tuyến theo đường dẫn trả 404 vì Ingress chuyển nguyên đường dẫn xuống backend — phải viết rewrite-target, mà đó là annotation riêng của ingress-nginx chứ không phải chuẩn Kubernetes. Đổi sang bộ điều khiển khác là viết lại toàn bộ. Và thiếu ingressClassName thì Ingress nằm im, không controller nào nhận, không lỗi.

DevOps 30/08/2026 8 phút

Ứng dụng của tôi bắt đủ SIGTERM, SIGINT, SIGHUP để dọn dẹp trước khi chết — khi bị OOMKill, nó không nhận được một tín hiệu nào và Kubernetes cũng chẳng sinh event nào

OOMKilled là trạng thái pod hay bị chẩn đoán sai nhất. Dựng nó có chủ ý: container vượt limits.memory bị kernel giết bằng SIGKILL (exitCode 137) — không tín hiệu, không giai đoạn dọn dẹp, nên mọi cơ chế tắt sạch bạn viết đều vô dụng, thứ cần giữ phải ghi LIÊN TỤC chứ không phải lúc tắt. Kubernetes không sinh event nào cho OOM — thông tin chỉ nằm ở status pod, nên bảng theo dõi dựa vào event mù hoàn toàn. Và OOMKilled (mức container, không đổi node) khác hẳn Evicted (mức node, đổi node) cả cơ chế lẫn cách chữa.

DevOps 30/08/2026 8 phút

Bộ lập lịch Kubernetes xếp chỗ trong 50 mili giây — nhưng nó đặt chỗ theo tờ khai 'requests', không theo mức bạn dùng thật, và một pod ưu tiên cao sẵn sàng giết pod đang chạy để có chỗ

Xếp một pod lên node chỉ tốn khoảng 50 mili giây. Nhưng bộ lập lịch cộng 'requests' chứ không nhìn CPU dùng thật — nên node có thể 'đầy' trong khi thật ra rỗng, và một pod PriorityClass cao sẽ đuổi pod đang chạy để lấy chỗ. Bài này đo cả ba hành vi đó.

DevOps 30/08/2026 8 phút

Toàn bộ trạng thái một cụm Kubernetes nằm gọn trong 2,6 MB — và 173 trong ~450 khoá chỉ là event; mất cái tệp bé tí này là mất cả cụm

etcd là nơi duy nhất Kubernetes lưu trạng thái, và nó nhỏ đến bất ngờ: 2,6 MB cho cả một cụm. Trần mỗi object là đúng 1.048.576 byte, áp cho mọi loại. Ghi vào etcd chỉ tốn 5 mili giây. Bài này mở nó ra xem bên trong, và vì sao bốn node etcd chịu lỗi không hơn gì ba.

DevOps 30/08/2026 8 phút

Docker chạy 3 container trong nửa giây; Kubernetes mất 10,6 giây và ngốn thêm 743 MB trước khi làm gì — đây là thứ 743 MB đó mua được

Tôi dựng đúng một ứng dụng nginx ba bản bằng Docker thuần rồi bằng Kubernetes, và đo cả hai — kể cả cái giá. Docker thắng mọi chỉ số tốc độ và bộ nhớ. Rồi tôi giết một thứ đang chạy, và mọi thứ đảo chiều: Docker chạy thứ bạn bảo nó chạy, Kubernetes giữ thứ bạn khai là phải có.

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.