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.
Xếp một pod lên node chỉ tốn khoảng 50 mili giây. Nhưng bộ lập lịch cộng 'requests' chứ không nhìn CPU dùng thật — nên node có thể 'đầy' trong khi thật ra rỗng, và một pod PriorityClass cao sẽ đuổi pod đang chạy để lấy chỗ. Bài này đo cả ba hành vi đó.
Ba mốc cuối của việc khởi động một pod xảy ra gọn trong cùng một giây — kubelet gần như không tốn thời gian. Chỗ đắt là kéo ảnh: 5,9 giây cho 4 MB, 15,7 giây cho 400 MB. Bài này đo đoạn đường từ 'bộ lập lịch ghi tên node' tới 'container đang chạy', và chỉ ra vì sao kubelet là thành phần duy nhất trong Kubernetes không phải là một pod.
Người ta viết Deployment và nghĩ nó quản pod. Nó không — nó quản ReplicaSet, và tầng ở giữa đó giải thích cả việc quay lui tức thì lẫn việc phản ứng chậm. Đổi ảnh thì ReplicaSet cũ không bị xoá, chỉ đặt mong muốn=0, nên quay lui chỉ là dịch số giữa hai ReplicaSet đã có sẵn (2,3 giây, không kéo ảnh). Node chết thì ReplicaSet chờ bốn phút vì pod ma vẫn báo Ready. Và trong bốn phút đó, kubectl get deployment vẫn hiện 4/4 — chỉ Endpoints nói thật.
Đo kỹ rolling update, đổi từng tham số để tìm thứ nào thật sự tạo ra 'không gián đoạn'. Có readinessProbe thì maxUnavailable 0, 1, hay 3 đều 0 lỗi — nhanh gấp sáu lần vẫn không mất yêu cầu nào, vì cấu hình quyết định TỐC ĐỘ chứ không quyết định AN TOÀN. Bỏ readinessProbe đi thì cùng lệnh đó mất 8% yêu cầu (Recreate 18%), và kubectl rollout status báo hoàn tất sau 2,6 giây trong khi container còn tám giây nữa mới nghe cổng. Thứ tạo ra không gián đoạn là readinessProbe, không phải RollingUpdate.
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.