CLOUD TESTING

Kiểm thử service mesh mTLS và resiliency: từ identity đến retry storm

29/7/2026 · 16 phút

Service mesh nhiều workload với sidecar proxy, control plane, mTLS và fault injection
Mục lục bài viết 9 phần

Ngày đăng · 16 phút đọc Service mesh có thể tự động hóa mTLS, routing và telemetry, nhưng cấu hình sai timeout/retry hoặc certificate rotation có thể biến lỗi nhỏ thành retry storm. Test plan cần nối workload identity, data-plane proxy, control plane và KPI ứng dụng trong cùng topology.

ĐỌC NHANH

Bài viết giúp bạn

  • Câu hỏi kiểm thử service mesh
  • Topology và trust boundary
  • Biến số phải kiểm soát
Tùy chỉnh đọc
01

Câu hỏi kiểm thử service mesh

#

Cần chứng minh đúng identity được cấp, traffic bắt buộc mTLS theo policy, request được route đúng, và lỗi downstream không gây retry vô hạn. Tách mesh configuration correctness khỏi application correctness.

Không coi biểu tượng “mTLS enabled” trên dashboard là bằng chứng duy nhất; cần handshake/identity/log và negative test.

02

Topology và trust boundary

#

Topology gồm client workload, frontend, backend, data-plane proxy, control plane/CA, ingress/egress gateway, DNS và telemetry. Đặt fault injection trước/sau proxy để biết lỗi thuộc app, network hay mesh.

Vẽ trust boundary cho namespace/cluster/region; ghi identity format, certificate lifetime và policy source.

Topology service mesh với workload identity, mTLS và điểm fault injection.
Topology service mesh với workload identity, mTLS và điểm fault injection.
03

Biến số phải kiểm soát

#

Khóa mesh/proxy/Kubernetes version, policy revision, protocol HTTP/gRPC/TCP, connection reuse, timeout, retry budget, circuit breaker, outlier detection và load-balancing. Giữ request rate/concurrency cố định khi thay một policy.

Certificate lifetime/rotation, clock, DNS TTL và readiness phải được ghi. Một pod chưa ready nhưng vẫn nhận traffic có thể bị hiểu nhầm là lỗi mesh.

04

KPI và bằng chứng

#

KPI: success/error rate, p50/p95/p99 latency, retry rate, retry amplification, circuit-open duration, connection reset, mTLS handshake failure, certificate rotation interruption, CPU/memory proxy và telemetry completeness.

Bằng chứng: config dump/policy, certificate metadata không chứa private key, proxy access/error log, distributed trace, application metrics và traffic result có correlation ID.

05

Ma trận security–resiliency

#
  • Kịch bản: Identity hợp lệ · Kỳ vọng: mTLS và authorization pass
  • Kịch bản: Identity sai/namespace sai · Kỳ vọng: Deny có log
  • Kịch bản: Certificate hết hạn/CA sai · Kỳ vọng: Fail closed theo policy
  • Kịch bản: Backend timeout · Kỳ vọng: Retry trong budget, không storm
  • Kịch bản: Một replica lỗi · Kỳ vọng: Outlier/circuit behavior đúng
  • Kịch bản: Control plane mất · Kỳ vọng: Data plane giữ cấu hình theo thiết kế
  • Kịch bản: Policy update lỗi · Kỳ vọng: Rollback/deny có kiểm soát
  • Kịch bản: Telemetry backend down · Kỳ vọng: Traffic không bị ảnh hưởng ngoài ngưỡng
06

Test plan fault injection

#

Chạy baseline rồi tiêm latency, reset, HTTP 5xx, packet loss và pod termination từng loại. Đo request gốc và tổng attempt để phát hiện load amplification. Thử request idempotent và non-idempotent riêng; không bật retry cho thao tác side effect nếu chưa có cơ chế an toàn.

Thử timeout ở client, proxy và app theo thứ tự. Nếu timeout không phối hợp, upstream có thể bỏ request trong khi downstream vẫn xử lý.

07

Scale và failure control plane

#

Tăng service, endpoint và connection rate; quan sát config convergence, proxy CPU/memory và xDS/control-plane load theo implementation. Thử rolling upgrade và certificate rotation dưới tải.

Mất control plane, CA hoặc telemetry backend phải được thử riêng. Xác minh data plane dùng last-known-good bao lâu và policy mới có bị áp dụng một phần.

Retry storm trong service mesh khi timeout và retry budget không phối hợp.
Retry storm trong service mesh khi timeout và retry budget không phối hợp.
08

Runbook thực hành

#
  • Ghi version, identity/policy và topology.
  • Xác minh positive/negative mTLS.
  • Thu baseline latency/error/retry.
  • Tiêm delay, reset, 5xx, pod failure.
  • Đếm request gốc và attempts.
  • Thử certificate rotation/clock issue.
  • Thử control-plane/telemetry failure.
  • Chạy scale/rolling upgrade.
  • Lưu config, trace, logs và verdict.
09

Giới hạn kết luận

#

Hành vi khác theo service mesh, mode data plane và version. mTLS bảo vệ hop trong phạm vi mesh, không tự chứng minh end-to-end data security. Fault injection không thay threat model.

Kết quả trên một cluster không chứng minh multi-cluster/region. Không so sánh overhead nếu workload, sidecar resources và connection reuse khác nhau.

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