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.
Nối hai dòng dữ liệu là việc phổ biến nhất và dễ làm sai nhất trong Kafka Streams. Tôi dựng một phép nối rồi chỉ đổi độ dài cửa sổ: kết quả đi từ đầy đủ xuống bằng không, không một dòng log. Cửa sổ nối so thời gian sự kiện, nên nó phải khớp khoảng cách thật trong nghiệp vụ — và cái giá của cửa sổ dài tỉ lệ với lưu lượng, không với độ dài.
retention.ms là mức *sàn*, không phải hạn chót: việc dọn chạy theo chu kỳ 5 phút và chỉ xoá nguyên cả segment. retention.bytes tính theo từng partition và làm tròn lên một segment, nên đĩa thật gấp 3,4 lần con số bạn viết. Đây là công thức dự trù đĩa đúng, và vì sao 'xoá sau 30 ngày' không phải một bảo đảm tuân thủ.
Xác thực trả lời 'bạn là ai', ACL trả lời 'bạn được làm gì'. Tôi bật ACL trên cụm thật rồi cấp quyền từng lớp: broker bị chính luật của nó chặn vì lưu lượng nội bộ là ANONYMOUS, đọc cần tới hai ACL, và lỗi của producer idempotent nói về cụm chứ không nói về topic. Mỗi lỗi đều chỉ sai chỗ cần sửa.
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.
Nâng cấp Kafka không cần dừng dịch vụ, quy trình ngắn hơn nhiều người nghĩ. Tôi chạy nó thật trên cụm đang có producer và consumer hoạt động: thay từng broker, ISR đầy lại sau 1–22 giây, không mất tin. Nhưng nhị phân mới không có nghĩa giao thức đã mới — và khoảng cách đó là một cửa sổ lùi được đặt ra có chủ ý.