#hieu-nang

370 bài viết
DevOps 31/08/2026 8 phút

Cùng một máy, cùng một phép thử: kindnet đạt 87,4 Gbit/s giữa hai node, Calico chỉ 45,6 — và cả 48% chênh lệch nằm gọn trong một dòng bảng định tuyến

CNI quyết định pod nhận IP thế nào và gói tin đi giữa các node ra sao. Dựng hai cụm giống hệt, đổi mỗi plugin mạng: kindnet định tuyến thuần đạt 87,4 Gbit/s liên node, Calico với đường hầm IPIP chỉ 45,6 — chậm 48%, vì mỗi gói bị bọc thêm một lớp IP header (dev tunl0). Qua Service chỉ tốn thêm 1,7%: cái đắt là đóng gói chứ không phải chuyển địa chỉ. Con số tuyệt đối cao bất thường vì đo trong một máy với MTU 65535, nhưng TỈ LỆ giữ nguyên vì nguyên nhân là phí trên mỗi gói, không phải tốc độ dây.

#zero-to-hero#kubernetes#hieu-nang#devops#network
22
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.

#zero-to-hero#kubernetes#hieu-nang#devops
17
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.

#zero-to-hero#kubernetes#hieu-nang#devops
13
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ỡ.

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

'Luôn dùng cooperative-sticky' — tôi đo thử và thấy nó khiến tổng thời gian partition ngừng chạy cao gấp 375 lần lời khuyên đó đang cố tránh

Cân bằng lại nhóm consumer được vẽ nhiều mà đo ít. Tôi bắt từng sự kiện kèm dấu thời gian: kiểu 'nhả hết' xong trong 4 ms không ai để ý, còn kiểu hợp tác giữ được partition đang chạy nhưng mỗi partition nhường mất 3 giây — tổng đắt gấp 375 lần. Lời khuyên 'luôn dùng cooperative' chỉ đúng khi ngắt một partition là đắt.

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

Cùng một lần sập, ba cách chốt offset: một cách trùng 1.150 tin, một cách trùng 50, một cách mất hẳn 50 tin mà không một lỗi nào — và không cách nào cho ra đúng 5.000

Chốt offset là chỗ dữ liệu thật sự mất hoặc trùng. Tôi dựng một lần sập giống hệt nhau rồi chạy ba cách: chốt trước khi xử lý mất tin, chốt sau khi xử lý trùng tin, không cách nào từ Kafka cho ra đúng một lần. Thứ tự giữa 'làm việc' và 'ghi nhận đã làm' quyết định crash làm mất hay làm trùng.

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