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.
Probe là thứ hiếm hoi mà cấu hình sai còn tệ hơn không cấu hình. Dựng ba kiểu sai phổ biến nhất và đo hậu quả: livenessProbe kiểm phụ thuộc ngoài khiến cả fleet restart khi DB chết (và restart không sửa được gì, còn làm phục hồi tệ hơn); timeoutSeconds mặc định 1 giây giết pod hoàn toàn khoẻ chỉ vì nó trả lời chậm hơn một giây; readinessProbe với failureThreshold 1 làm cả dịch vụ mất hết endpoint khi mọi pod cùng trượt một nhịp — mà kubectl get pods trông gần như bình thường. Và vì sao nhiều ứng dụng KHÔNG nên có livenessProbe.