
Mục lục bài viết 8 phần
Một service Kubernetes chậm không đồng nghĩa ứng dụng chậm. Độ trễ có thể đến từ CNI datapath, encapsulation, service routing, NetworkPolicy, conntrack, CPU throttling hoặc underlay giữa node. Test plan cần chia đường đi thành các lớp và dùng cùng một traffic profile để so sánh.
Bài viết giúp bạn
- Tách các đường đi cần đo
- Topology và điểm quan sát
- Traffic profile và biến số
Tách các đường đi cần đo
#Ít nhất đo pod cùng node, pod khác node, pod tới ClusterIP và pod tới endpoint ngoài cluster. Ingress/gateway hoặc service mesh là đường riêng vì thêm proxy, TLS và policy.
Pod-to-pod đo CNI datapath; pod-to-service thêm service selection và kube-proxy hoặc eBPF tương ứng; cross-node thêm NIC, underlay, encapsulation và MTU. Tách L3/L4 khỏi HTTP/gRPC để không trộn DNS, TLS và application time.

Topology và điểm quan sát
#Dùng tối thiểu ba worker node, pin client/server có chủ đích, một endpoint ngoài cluster và hệ thống metric độc lập. Ghi zone/rack, NIC, MTU và đường underlay.
Quan sát application, pod, node, CNI, host interface và switch. Capture ở pod namespace, host và underlay; lưu ý GRO/GSO/TSO có thể làm packet trong capture khác packet trên dây.
Traffic profile và biến số
#Kết hợp short-lived và long-lived connection. Short-lived nhạy với SYN, conntrack, DNS và TLS; long-lived phù hợp throughput ổn định. UDP sequence đo loss/jitter nhưng không thay thế TCP.
Cố định Kubernetes, CNI, kernel, node image, CPU request/limit, MTU, offload, kube-proxy mode, NetworkPolicy, encryption, mesh và autoscaling. So CNI chỉ có ý nghĩa khi placement và hạ tầng tương đương.
- Payload 1 KB, 16 KB và streaming lớn
- Từ vài kết nối bền tới hàng nghìn kết nối đồng thời
- So Pod IP, ClusterIP, mesh/ingress bằng cùng workload
KPI và baseline
#KPI gồm application goodput và wire rate, latency p50/p95/p99, jitter, loss, connection setup/failure, retransmission/reset/timeout, CPU/memory, SoftIRQ, conntrack, NIC/CNI drop và endpoint convergence.
Baseline nên có host-to-host, pod same-node, pod cross-node và pod-to-service. Báo overhead theo chênh lệch trong cùng môi trường, không so với datasheet hoặc benchmark khác điều kiện.
Ma trận bài đo
#Ma trận gồm same-node, cross-node, ClusterIP, NetworkPolicy, encryption, endpoint scale, rollout, node drain và MTU mismatch. Mỗi case gắn KPI và nguồn bằng chứng.
NetworkPolicy cần cả positive và negative test: traffic bị chặn đúng, traffic được phép vẫn đạt SLO và namespace khác không chịu side effect.
Runbook thực hành
#Chụp inventory; kiểm tra clock và tài nguyên; chạy host baseline; pin same-node rồi cross-node nhiều cặp; đi qua ClusterIP; bật policy/mesh/encryption từng bước; tăng concurrency; quan sát CPU, SoftIRQ, conntrack và drop; scale endpoint, rollout và drain node khi giữ tải.
Lặp ít nhất 5 vòng và báo median, p95, worst case. Lưu manifest, config, raw result, PCAP cần thiết và snapshot metric.
- Xác nhận pod placement mỗi vòng
- Kiểm tra MTU end-to-end gồm tunnel overhead
- Bảo đảm generator/server chưa bão hòa trước datapath
Khoanh vùng sai lệch
#Same-node nhanh nhưng cross-node chậm: kiểm tra underlay, tunnel, MTU, NIC queue và encryption. Pod IP nhanh nhưng ClusterIP chậm: kiểm tra service datapath, conntrack và endpoint selection.
Nếu chỉ p99 xấu, tìm microburst, CPU scheduling, GC hoặc queue. Capture có ‘gói lớn’ trên host có thể do offload, không tự động là MTU sai.

Giới hạn của kết luận
#Kết quả phụ thuộc Kubernetes, kernel, CNI, cloud instance, NIC, topology và cấu hình. Không thể kết luận CNI A nhanh hơn CNI B khi khác node type, offload, encryption hoặc policy.
Microbenchmark L4 không đại diện ứng dụng có database, retry và service mesh. Dùng benchmark datapath để khoanh vùng, rồi workload ứng dụng để nghiệm thu SLO.
Khái niệm cần nhớ
- DUT / SUT
- Thiết bị hoặc toàn bộ hệ thống đang là đối tượng của bài kiểm thử.
- Steady state
- Giai đoạn tải đã ổn định và đủ điều kiện để lấy số liệu đại diện.
- Pass / fail
- Kết luận dựa trên ngưỡng đã thống nhất, luôn đi cùng topology, cấu hình và điều kiện đo.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo4 nguồn +
Nội dung được biên soạn độc lập, theo hướng vendor-neutral và đối chiếu các tài liệu gốc dưới đây. Tính năng sản phẩm cần được kiểm tra lại theo phiên bản đang sử dụng.
NetVali ưu tiên nguồn tiêu chuẩn và tài liệu chính thức; phân biệt khuyến nghị triển khai với yêu cầu của tiêu chuẩn; không công bố thông số sản phẩm chưa gắn với phiên bản và điều kiện đo.
