IPVS-Based In-Cluster Load Balancing Deep Dive
Bài tóm tắt Kubernetes 2018 3. Quy mô lớn Độ khó: Trung bình
Kubernetes · 2018 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc
Bài của dự án mã nguồn mở, giới thiệu một tính năng lên GA ở Kubernetes 1.11. Phần lớn bài là tham số cấu hình; wiki chỉ ghi phần lý do kiến trúc.
Bối cảnh
- kube-proxy chạy trên mỗi node, biến Service (một IP ảo) thành việc chuyển gói tới các pod phía sau. Trước đó có hai chế độ: userspace (cũ) và iptables (mặc định).
- iptables được thiết kế cho firewall, luật nằm thành danh sách trong kernel. Theo bài, nó khó lên tới hàng chục nghìn Service.
- Kubernetes đã hỗ trợ 5.000 node từ bản 1.6, nhưng kube-proxy dùng iptables lại là nút cổ chai để thật sự chạy cụm cỡ đó. Ví dụ trong bài: cụm 5.000 node, 2.000 Service NodePort, mỗi Service 10 pod thì mỗi worker có ít nhất 20.000 luật iptables, kernel rất bận.
Thay đổi chính
- Chế độ IPVS (IP Virtual Server, bộ cân bằng tải tầng 4 trong kernel Linux, một phần của LVS) lên GA ở 1.11: bật bằng
--proxy-mode=ipvs. - IPVS được thiết kế riêng cho cân bằng tải và dùng bảng băm, nên theo bài gần như không giới hạn quy mô.
- Có nhiều thuật toán chọn backend: round-robin (mặc định), least connection, hash theo đích/nguồn, shortest expected delay, never queue.
- Cách dựng: một interface giả (
kube-ipvs0) trên mỗi node, gắn mọi IP của Service vào đó, mỗi IP của Service là một virtual server của IPVS; mỗi endpoint (IP + port của pod) là một real server. Dùng chế độ NAT vì chỉ NAT hỗ trợ đổi port. - IPVS chỉ cân bằng tải; các việc khác (lọc gói, SNAT, masquerade, NodePort, LoadBalancer) vẫn dựa vào iptables, kết hợp ipset để giữ số luật nhỏ.
- Có tham số chu kỳ đồng bộ luật tối thiểu/tối đa, và danh sách CIDR không được đụng tới khi dọn luật (để không xoá luật IPVS do người dùng tự đặt).
Vì sao
- Theo bài, khả năng mở rộng của Service quyết định việc các công ty chạy tải lớn có dùng được Kubernetes hay không. Cấu trúc dữ liệu tuyến tính (danh sách luật) ổn ở cụm nhỏ nhưng thành chi phí trên mọi node khi số Service × số pod tăng.
Bài học cho SWE
- Một thành phần mặc định của nền tảng (kube-proxy dùng iptables) có thể là giới hạn ẩn của cả cụm; con số "hỗ trợ 5.000 node" của control plane không nói gì về data plane (Nền tảng nội bộ cho service (đường ray chung)).
- Đổi cấu trúc dữ liệu (danh sách → bảng băm) thường là cách scale rẻ nhất, khi công cụ ban đầu được thiết kế cho mục đích khác.
- Tải trên mỗi node tăng theo tích số Service × endpoint, cùng họ với tải WATCH tăng theo N² mà OpenAI 2021 gặp.
Liên quan
Được nhắc tới trong
Công ty (1)
Bài tóm tắt (3)