Tôi dựng đúng một ứng dụng nginx ba bản bằng Docker thuần rồi bằng Kubernetes, và đo cả hai — kể cả cái giá. Docker thắng mọi chỉ số tốc độ và bộ nhớ. Rồi tôi giết một thứ đang chạy, và mọi thứ đảo chiều: Docker chạy thứ bạn bảo nó chạy, Kubernetes giữ thứ bạn khai là phải có.
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.
Sơ đồ kiến trúc Kubernetes thì ở đâu cũng có. Tôi làm khác: tắt từng thành phần một trên cụm đang chạy rồi đo cái gì hỏng. Kết quả đáng nhớ nhất — mất control plane, mọi thứ vẫn chạy y như thường, cho tới đúng lần tiếp theo có một pod chết mà không ai thay nó. Và apiserver nặng gần gấp năm lần etcd.
Câu 'pod là đơn vị nhỏ nhất, không phải container' nghe như chi tiết thuật ngữ. Đo thử thì ra hai điều thú vị: hai container trong một pod chung một IP và nói chuyện qua localhost, và thời gian xoá pod hoàn toàn không phụ thuộc việc ứng dụng tắt nhanh hay chậm — nó chỉ đo đúng terminationGracePeriodSeconds.
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.
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.