IPVS là gì? khi nào dùng cho L4 load balancing

IPVS hay IP Virtual Server là L4 load balancing chạy trong Linux kernel, cho phép bạn tạo một virtual service, rồi phân phối connection tới nhiều real server theo scheduler.

Trong DevOps và SRE, IPVS hay gặp ở Kubernetes khi kube-proxy chạy ipvs mode, ở những hệ thống cần scale nhiều Service và nhiều endpoints, và ở những nơi bạn muốn dataplane ổn định hơn so với iptables nat khi rule tăng rất nhanh theo số lượng endpoints.

Ví dụ: Client truy cập 10.0.0.100 port 443, IPVS chuyển connection sang 10.0.1.10 port 8443.

IPVS xử lý ở kernel path, nên thường cho latency thấp và throughput cao khi cấu hình đúng, đặc biệt khi số lượng backend lớn.

IPVS cho biết điều gì

IPVS cho bạn một cách nhìn rất rõ về L4 service delivery:

Một VIP và port đang đại diện cho service nào
Backend nào đang tham gia nhận traffic
Scheduler đang dùng kiểu gì và đang phân phối ra sao
Connection counters, packet counters, byte counters cho từng backend

Điều này giúp on call nhanh trả lời câu hỏi traffic có vào VIP không, có được phân phối không, backend nào đang bị bỏ qua.

Thành phần chính của IPVS

Virtual service: VIP và port mà client truy cập
Real server: Backend thực tế nhận traffic
Scheduler: Thuật toán chọn backend cho mỗi connection mới
Forwarding method: Cách kernel chuyển traffic từ VIP sang backend

Forwarding method phổ biến và tradeoff

NAT mode: Kernel đổi destination và thường cần xử lý return path qua cùng node NAT. Dễ triển khai, nhưng conntrack và egress path là điểm cần chú ý.
DR mode: Client vẫn truy cập VIP, request tới load balancer, nhưng response thường đi thẳng từ backend về client. Hiệu năng tốt, nhưng cần kiểm soát ARP và routing rất chặt.
TUN mode: Gói tin được tunnel tới backend. Phù hợp vài topology đặc biệt, vận hành phức tạp hơn.

Trong môi trường Kubernetes ipvs mode, kube-proxy thường dùng cơ chế gần với NAT cho Service traffic, và sự khác biệt lớn nhất với iptables là cách lưu state và cách scale rule.

IPVS vs iptables nat

iptables nat dựa trên tập rule match theo thứ tự, khi endpoints tăng nhiều, rule list lớn, chi phí match tăng theo.
IPVS dùng cấu trúc dữ liệu phù hợp cho lookup và load balancing, thường ổn định hơn khi số endpoints lớn.

Dấu hiệu bạn nên cân nhắc IPVS:

Cluster có nhiều Service và nhiều endpoints
kube-proxy iptables mode update rule liên tục gây spike CPU
Bạn cần quan sát rõ per backend counters để debug distribution

Scheduling trong IPVS

Một số scheduler hay gặp:

rr: Round robin
wrr: Weighted round robin
lc: Least connection
wlc: Weighted least connection
sh: Source hashing, hay dùng cho sticky theo source
dh: Destination hashing, ít gặp hơn trong thực chiến Kubernetes

Chọn scheduler là câu chuyện workload:

Workload đồng đều, rr hoặc wrr đủ tốt
Workload chênh lệch theo connection duration, lc hoặc wlc thường hợp hơn
Cần sticky theo client identity ở L4, sh có thể hữu ích nhưng phải hiểu rủi ro hot key

Session persistence trong IPVS

Persistence giúp một client quay lại cùng backend trong một khoảng thời gian.

Use case:

Protocol stateful ở L4
Backend cache theo client
Giảm risk session break khi backend thay đổi liên tục

Tradeoff:

Sticky làm distribution kém đều hơn
Khi một backend degrade, sticky có thể giữ client ở backend xấu lâu hơn

IPVS trong Kubernetes khi kube-proxy chạy ipvs mode

Trong ipvs mode, kube-proxy sẽ tạo virtual service cho ClusterIP, NodePort, ExternalIP, rồi add real server là các Pod IP tương ứng.

Những điểm hay gây incident:

Endpoint churn cao, conntrack giữ mapping cũ lâu, tạo cảm giác lúc được lúc không
Node nhận traffic nhưng không có local endpoint, traffic phải hop sang node khác
Source IP preservation phụ thuộc Service type và policy, dễ gây hiểu nhầm khi đọc access log

Observability và troubleshooting IPVS

Các thứ hay check:

Xem bảng IPVS và counters

ipvsadm -Ln --stats --rate

Đọc nhanh trạng thái trong proc

cat /proc/net/ip_vs
cat /proc/net/ip_vs_stats

Kiểm tra conntrack khi dùng NAT mode nhiều

conntrack -S
conntrack -L | head

Pattern debug nhanh:

VIP có counters tăng nhưng backend counters không tăng Thường là rule không map đúng, health state không đúng, hoặc traffic không đi qua đúng node
Backend counters tăng nhưng client vẫn timeout Thường là return path, conntrack, hoặc mtu mismatch trên đường về

Pitfalls của IPVS

Conntrack full: Symptom kiểu drop ngẫu nhiên, timeout theo burst
ARP issue trong DR mode: ARP reply sai làm traffic đi nhầm node, rất khó debug nếu không bắt ARP
MTU mismatch: Request vào được, response lớn bị drop, hay lộ ra khi enable TLS hoặc khi payload lớn
Observability gap giữa L7 và L4: L7 log thấy request ít, nhưng IPVS counters lại tăng, hoặc ngược lại, cần correlate theo time window

Checklist vận hành IPVS cho production

Xác định rõ mode đang dùng và return path có quay về đúng node không
Monitor conntrack usage, nf_conntrack_max, và drop counters
Theo dõi per backend rate và error rate để phát hiện imbalance sớm
Chuẩn hóa debug flow: ipvsadm, conntrack, tcpdump ở interface vào và interface ra
Có rollback plan: Chuyển kube-proxy từ ipvs mode về iptables mode hoặc ngược lại theo quy trình rõ ràng