Kubernetes cho những người phải vận hành nó

Các hướng dẫn Kubernetes dạy bạn cách deploy một pod. Không ai dạy bạn phải làm gì khi một node im lặng mất trạng thái Ready lúc 3 giờ sáng và điện thoại on-call của bạn không ngừng rung. Đây là về phần thứ hai.

Resource requests và limits không phải là tùy chọn

Nếu bạn bỏ qua resources.requests và resources.limits trên các containers của bạn, scheduler đang đoán mò, và kubelet không biết phải evict cái gì trước khi một node hết memory. Đặt requests thành những gì mà container thực sự sử dụng dưới tải bình thường, không phải những gì bạn hy vọng nó sử dụng. Đặt memory limits gần với requests vì các pods bị OOM-killed sẽ restart sạch sẽ, nhưng CPU limits nên rộng hơn hoặc không có trừ khi bạn đang chống lại các noisy neighbors, vì CPU throttling dưới một hard limit gây ra latency spikes rất khó debug. Chạy kubectl top pods -n your-namespace thường xuyên và so sánh với những gì bạn đã khai báo. Các sự không khớp tích tụ nhanh trong các clusters có nhiều hơn một vài services.

etcd là toàn bộ cluster, hãy đối xử với nó theo cách đó

Mọi thứ Kubernetes biết đều nằm trong etcd. Mất nó và bạn mất trạng thái cluster, không chỉ một số metadata. Chạy etcdctl snapshot save /backup/etcd-snapshot.db theo lịch, và thực sự test restore nó trên một scratch cluster ít nhất một lần. Tôi đã thấy các teams với backups hàng đêm mà hóa ra bị corrupt trong ba tháng vì không ai verify chúng. Nếu bạn đang sử dụng một managed control plane (EKS, GKE, AKS), bạn không quản lý etcd trực tiếp, nhưng bạn vẫn nên biết câu chuyện backup và restore của provider của bạn trước khi bạn cần nó, không phải trong một incident.

Liveness và readiness probes cần phải không đồng ý đôi khi

Một lỗi thường gặp là sử dụng cùng một endpoint cho cả liveness và readiness probes. Liveness nên trả lời