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

197 bài viết
DevOps 30/08/2026 7 phút

Vượt giới hạn CPU thì container bị bóp chậm lại nhưng sống nhăn; vượt giới hạn bộ nhớ thì bị giết ngay — cùng một cặp tham số, hai số phận trái ngược

requests và limits trông như một cặp, nhưng là hai cơ chế khác nhau, và CPU với bộ nhớ còn được xử lý khác nhau nữa. Đo cả bốn tổ hợp: limit CPU 100m thì container bị bóp 100% chu kỳ mà RESTARTS vẫn 0 (chậm mà không chết), còn limit RAM 128Mi thì OOMKilled exitCode 137 và RESTARTS tăng đều. Khác biệt cốt lõi: CPU nén được nên bị bóp, bộ nhớ không nén được nên bị giết. Kèm ba lớp QoS, vì sao không khai requests là tự nhận vé chết trước, và vì sao limits.cpu thường nên bỏ.

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

Đặt min.insync.replicas = 3 với 3 bản sao nghe như 'an toàn nhất' — thực ra nó biến mọi lần vá máy thành một sự cố dừng ghi toàn phần

min.insync.replicas quyết định lúc nào Kafka thà từ chối ghi còn hơn nhận rồi mất. Tôi đo cả ba giá trị ở ba mức hỏng: đặt bằng đúng replication-factor thì không còn dư địa nào, mỗi lần bảo trì một broker đều dừng ghi. Và có một kiểu hỏng — mất quorum controller — mà không cấu hình topic nào chạm tới được, trong khi describe vẫn báo khoẻ.

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

Giết một broker Kafka mất 9,142 giây mới bầu xong leader mới — không phải vì bầu chậm, mà vì phải chờ đủ lâu để chắc chắn nó đã chết chứ không phải chỉ chậm

Bản sao là cơ chế Kafka dùng để không mất dữ liệu khi máy chết. Tôi giết máy thật và bấm giờ: 9,142 giây để bầu leader mới, đúng bằng broker.session.timeout.ms — vì không thể phân biệt tức thời 'đã chết' với 'chỉ chậm'. Không mất tin nào, nhưng có tin mất 11,7 giây mới tới, và broker sống lại thì ngồi không cho tới khi được trao lại việc.

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

Thử lại tin hỏng ngay tại chỗ chậm hơn 25 lần so với đẩy sang hàng đợi chết — vì một tin kẹt trên partition chặn đứng mọi tin tốt phía sau nó

Khi một tin không xử lý được, phản xạ tự nhiên là thử lại. Tôi đo cái giá đó ở bốn mức tỉ lệ hỏng: ở mức 50%, thử lại tại chỗ cho 30 tin/giây còn đẩy sang DLQ cho 766 — chênh 25,5 lần. Chi phí của một tin hỏng không phải là chờ nó, mà là toàn bộ hàng phía sau cũng phải chờ theo.

#kafka#message-queue#zero-to-hero#hieu-nang
29
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.

#zero-to-hero#devops#kubernetes#etcd
33
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.

#zero-to-hero#devops#kubernetes
31