Scaling Kubernetes to 2,500 nodes

OpenAI · 2018 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Phần 1 của cặp bài; phần sau: OpenAI 2021.

Bối cảnh

OpenAI chạy Kubernetes cho thí nghiệm deep learning hơn 2 năm (workload lớn nhất thì quản lý VM trực tiếp). Kubernetes cho vòng lặp nhanh, scale vừa đủ, ít boilerplate. Trên đường lên 2.500 node, lần lượt các thành phần vỡ: etcd, master, kéo image, mạng, KubeDNS, thậm chí ARP cache.

Các nút cổ chai gặp lần lượt

• Khoảng 500 node: etcd chậm. kubectl hay timeout; thêm master chỉ đỡ tạm. Ổ SSD mạng P30 (5.000 IOPS) nhưng etcd ghi tuần tự, nên bị giới hạn bởi latency (2 ms mỗi lần ghi), chỉ dùng được khoảng 10% IOPS. Chuyển thư mục etcd sang SSD cục bộ thì latency ghi còn 200 µs.
• Khoảng 1.000 node: apiserver đọc hơn 500 MB/s từ etcd. Thủ phạm là agent giám sát (Fluentd, Datadog) trên mọi node mặc định đều hỏi apiserver. Giảm tần suất poll là xong. Thêm: tách Kubernetes Events ra một cụm etcd riêng để spike event không ảnh hưởng etcd chính.
• Chạm giới hạn lưu trữ etcd (mặc định 2 GB): etcd ngừng nhận ghi → mọi node fail health check → autoscaler quyết định xoá toàn bộ worker. Họ tăng giới hạn kích thước.
• Scheduler: chính sách mặc định rải đều pod. Họ đổi sang ưu tiên dồn pod (MostRequestedPriority) để autoscaler tắt được node rỗng, tiết kiệm chi phí. Hệ quả: có máy chạy hơn 10 bản KubeDNS, thành điểm nóng. Sửa bằng anti-affinity cho KubeDNS.
• Kéo image: image Dota khoảng 17 GB mất tới 30 phút; kubelet huỷ pull vì "không tiến triển". Kubelet còn mặc định kéo một image đặc biệt từ gcr.io, nếu chạm quota thì node không khởi động được container nào.
• Mạng: giữa máy 10–15 Gbit/s nhưng pod qua Flannel thấp hơn nhiều. Tạm cho pod dùng hostNetwork.
• ARP cache: mỗi pod một IP làm đầy bảng ARP của kernel (kết nối Redis mất hơn 30 giây). Tăng ngưỡng gc_thresh như các cụm HPC vẫn làm.
• Kết quả: khoảng 3 tháng không sự cố.

Bài học cho SWE

• Scale một cụm là chuỗi nút cổ chai lần lượt lộ ra; mỗi bậc (500, 1.000 node) có một thủ phạm khác (Scale dọc trước khi scale ngang).
• Agent chạy trên mọi node mà gọi về control plane thì tải tăng theo số node: kẻ gây quá tải thường là công cụ giám sát.
• Tự động hoá có thể khuếch đại sự cố: etcd đầy → health check hỏng → autoscaler xoá hết máy. Cùng mẫu với Pacemaker của GoCardless (Sự cố và postmortem).
• Kho trạng thái của nền tảng (etcd) phải được đo theo latency, không theo IOPS (Nền tảng nội bộ cho service (đường ray chung)).

Liên quan

• Nền tảng nội bộ cho service (đường ray chung)
• Scale dọc trước khi scale ngang
• Tự động hoá vận hành và auto-remediation