Lưu trữ — Tháng 8/2026

197 bài viết
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.

#kubernetes#zero-to-hero#devops
18
Message Queue 30/08/2026 8 phút

Bỏ ZooKeeper, cả ngăn xếp Kafka dựng trong 2,8 giây thay vì 26,3 — nhưng KRaft không xoá quorum, nó chỉ dời quorum vào trong Kafka

Suốt mười năm Kafka cần ZooKeeper; từ 4.0 thì không. Tôi dựng cả hai kiểu cạnh nhau: KRaft nhanh gấp chín lần, nhẹ hơn, bớt một tiến trình. Nhưng bài học đáng nhớ hơn là khi ZooKeeper chết, Kafka vẫn ghi đọc bình thường — chỉ mặt phẳng điều khiển dừng — và bỏ ZooKeeper không có nghĩa bỏ được yêu cầu đa số 2f+1.

#zero-to-hero#hieu-nang#message-queue#kafka
16
Message Queue 30/08/2026 8 phút

Tôi dựng đúng kịch bản làm Kafka mất 500 tin đã xác nhận, và nhìn bộ đếm offset đi lùi từ 1.500 về 1.000 — thứ Kafka vốn hứa không bao giờ xảy ra

Có một tham số Kafka mà bật lên là bạn đồng ý mất dữ liệu trong vài tình huống. Tôi dựng đúng tình huống đó: unclean.leader.election.enable=true cho một bản sao cũ lên làm leader, 500 tin đã ack biến mất, và offset đi lùi — phá vỡ giả định nền của mọi thứ xây trên Kafka. Đây là lựa chọn giữa 'dừng lại chờ' và 'tiến lên với dữ liệu sai'.

#zero-to-hero#hieu-nang#message-queue#kafka
15
Message Queue 30/08/2026 9 phút

Xoá sạch bộ đệm trang rồi bắt Kafka đọc lại — chỉ chậm đi 1,6 lần, không phải 100 lần; vì đọc tuần tự thì trượt đệm gần như không đau

Kafka hay được khen nhanh nhờ 'zero-copy' và 'page cache', hai cụm từ ít khi được đo. Tôi đo cả hai: một broker 1,2 GB phục vụ 1.130 MB/giây, và khi xoá sạch bộ đệm trang, đọc lạnh chỉ chậm 1,6 lần chứ không phải hai bậc độ lớn — vì Kafka đọc tuần tự, và với truy cập tuần tự thì bộ đệm gần như là tuỳ chọn.

#zero-to-hero#hieu-nang#message-queue#kafka
15
DevOps 30/08/2026 8 phút

83% thời gian một lệnh kubectl chỉ là khởi động binary, không phải việc của cụm — và một cụm Kubernetes không ai đụng vào vẫn gọi API server ba lượt mỗi giây

kube-apiserver là cửa duy nhất vào cụm, nặng 265 MB — gấp năm lần etcd. Nhưng phần việc thật của nó cho một lệnh kubectl chỉ 4–8 mili giây; 24 mili giây còn lại là binary khởi động. Bài này đo chi phí một lệnh, cơ chế watch thay cho hỏi liên tục, và chỗ nguy hiểm nhất: webhook admission nằm ngay giữa đường ghi.

#kubernetes#zero-to-hero#devops
15
Message Queue 30/08/2026 8 phút

30.000 tin với 1.000 khoá, nén xong còn 2.908 chứ không phải 1.000 — 'mỗi khoá một tin' là câu sai, và consumer nào tin nó sẽ đếm nhầm

cleanup.policy=compact biến topic Kafka thành gần một bảng khoá–giá trị. Nhưng tôi đo thấy nó không để lại mỗi khoá đúng một tin: phần đầu log vừa ghi vẫn giữ nguyên bản trùng, chỉ phần đuôi đã nén mới sạch. Bảo đảm ở đây là 'rốt cuộc hội tụ về giá trị mới nhất', không phải một bất biến tức thời — và có một cái bẫy bia mộ khiến dữ liệu xoá vẫn còn.

#zero-to-hero#hieu-nang#message-queue#kafka
16