CLOUD TESTING

Kiểm thử lưu lượng east-west trong Kubernetes: từ CNI đến service latency

24/7/2026 · 16 phút

Ba worker node Kubernetes với các đường đi same-node, cross-node và qua lớp service
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.

ĐỌC NHANH

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ùy chỉnh đọc
01

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.

So sánh đường đi same-node, cross-node và pod-to-service trên các lớp CNI overlay và underlay.
So sánh đường đi same-node, cross-node và pod-to-service trên các lớp CNI overlay và underlay.
02

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.

03

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
04

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.

05

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.

06

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
07

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.

Các điểm đo liên tiếp giúp khoanh vùng latency, queue và packet loss trên Kubernetes datapath.
Các điểm đo liên tiếp giúp khoanh vùng latency, queue và packet loss trên Kubernetes datapath.
08

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.

THUẬT NGỮ NHANH

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.

Nguyên tắc biên tập

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.

Thông số và khả năng sản phẩm có thể thay đổi theo phiên bản. Hãy đối chiếu tài liệu chính thức trước khi xây dựng cấu hình hoặc tiêu chí nghiệm thu.
BẮT ĐẦU TỪ BÀI TOÁN

Cần chuyển kiến thức thành test plan?

Chia sẻ mục tiêu, topology và ràng buộc kỹ thuật. NetVali sẽ cùng bạn xác định bài đo phù hợp.

Trao đổi yêu cầu kỹ thuật