Bài viết mới nhất

Tổng 1741 bài
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ỏ.

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.

Message Queue 30/08/2026 8 phút

MirrorMaker 2 chép 200.000 tin sang cụm Kafka khác trong 8,7 giây — nhưng offset của consumer thì không sang, và nó hỏng mà không báo một tiếng; chép sách dễ, chép dấu trang mới khó

Sao chép Kafka giữa hai vùng là nền của mọi kế hoạch phục hồi thảm hoạ. Tôi dựng hai cụm thật, chạy MirrorMaker 2: dữ liệu sang hoàn hảo trong 8,7 giây, nhưng vị trí đọc của consumer thì không — topic checkpoint được tạo ra, rỗng, và im lặng. Đó là khác biệt giữa 'có bản sao dữ liệu' và 'có kế hoạch chuyển vùng'.

Message Queue 30/08/2026 8 phút

Avro nhỏ hơn JSON 2,5 lần — nhưng sau khi bật nén thì chỉ còn 1,4 lần; cái lợi bạn tưởng mình mua đã được một tầng miễn phí làm hộ

Lời khuyên phổ biến là 'đừng dùng JSON trên Kafka, dùng Avro'. Tôi đo cả ba định dạng trên cùng dữ liệu: thô thì Avro nhỏ hơn JSON 2,5 lần nhưng mã hoá lại chậm hơn. Rồi bật nén — mà cụm nào cũng bật — và lợi thế co xuống 1,4 lần, vì nén xoá đúng phần dư thừa (tên trường lặp lại) mà Avro xoá bằng tay. Lý do thật để chọn Avro nằm ở chỗ khác.

DevOps 30/08/2026 8 phút

Ba probe của Kubernetes nghe như cùng một việc 'kiểm tra sức khoẻ' — nhưng khi hỏng, một cái giết container, một cái chỉ ngừng gửi việc, một cái bảo hai cái kia chờ

Ba probe trả lời ba câu hỏi khác nhau và Kubernetes phản ứng theo ba cách khác hẳn. livenessProbe hỏng thì container bị khởi động lại (và nếu lỗi không tự khỏi thì lặp mãi); readinessProbe hỏng thì pod bị gỡ khỏi Endpoints nhưng KHÔNG khởi động lại (RESTARTS=0, vẫn Running, chỉ 0/1); startupProbe thì tạm dừng cả hai cái kia cho ứng dụng khởi động lâu kịp lên. Đo cả ba, và vì sao dùng startupProbe đúng hơn hẳn việc nâng initialDelaySeconds — cái sau chữa lúc khởi động nhưng làm ì việc phát hiện lỗi suốt đời container.

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.