Giám sát Mạng Kubernetes với Cilium Hubble: Trực quan hóa Traffic Thời gian thực và Kiểm tra Network Policy

Table of Contents

So sánh Tiếp cận: Bắt gói tin Truyền thống vs. Khả năng Giám sát Bằng eBPF

Bây giờ là 2:14 sáng thứ Ba. Chuông PagerDuty reo: checkout service liên tục gặp lỗi 504 Gateway Timeout chập chờn, còn các request thanh toán downstream thì fail hàng loạt. Bạn ssh vào bastion host, chạy kubectl get pods và thấy mọi container đều đang healthy. Log ứng dụng hầu như chẳng có gì ngoài những thông báo connection reset khó hiểu. Bạn hoàn toàn mất phương hướng giữa hạ tầng mạng ảo của cluster.

Khi các gói tin biến mất bí ẩn trong hệ thống mạng ảo của Kubernetes, các kỹ sư thường phải dựa vào ba giải pháp rời rạc sau:

Ephemeral debug container kết hợp tcpdump: Bạn attach một debug container vào network namespace của pod mục tiêu hoặc chạy lệnh nsenter trực tiếp trên node để bắt file PCAP thô. Dù chính xác, cách này cực kỳ chậm chạp khi đang có sự cố. Việc dump 50.000 gói tin mỗi giây có thể khiến CPU của node tăng vọt thêm 20% đến 30%, chưa kể terminal của bạn sẽ ngập tràn mã hex thô mà không hề có tên pod, service đích hay Kubernetes namespace.
Service Mesh sidecar (Envoy / Istio): Các proxy ở tầng ứng dụng xử lý traffic HTTP rất tốt, nhưng chúng không thể cho bạn biết điều gì đang diễn ra bên dưới Layer 7. Nếu một quy tắc iptables hoặc CNI bên dưới âm thầm drop gói tin SYN, sidecar proxy chỉ có thể báo lỗi upstream timeout chung chung. Hơn nữa, việc inject proxy còn ngốn thêm từ 80MB đến 150MB RAM trên mỗi pod và làm tăng độ trễ khứ hồi từ 1ms đến 3ms.
eBPF ở cấp độ Kernel với Cilium Hubble: Thay vì inject proxy vào từng pod hay phải bới tìm từng byte dữ liệu thô sau khi sự cố đã lan rộng, Cilium gắn trực tiếp các chương trình Extended Berkeley Packet Filter (eBPF) vào các hook trong Linux kernel. Hubble chạy trên nền tảng engine này, kiểm tra các luồng traffic ngay tại tầng socket và packet. Các quá trình bắt tay (handshake), truy vấn DNS, giao dịch HTTP và các gói tin bị drop đều được ánh xạ với metadata của Kubernetes—như source pod, target service, label và namespace—ngay trước khi chạm tới user space.

Ưu & Nhược điểm của các Chiến lược Giám sát Mạng

Việc lựa chọn phương pháp kiểm tra mạng phụ thuộc vào việc cân bằng giữa overhead tài nguyên, độ an toàn vận hành và tính rõ ràng của ngữ cảnh khi hệ thống production gặp sự cố.

1. Bộ công cụ Truyền thống (tcpdump, log iptables, conntrack)

Ưu điểm: Được cài sẵn trên hầu hết các bản phân phối Linux; không làm xáo trộn kiến trúc toàn cụm.
Nhược điểm: Tiềm ẩn rủi ro cao gây quá tải các node đang bận rộn trong quá trình capture; làm mất metadata của workload; không thể theo dõi các IP pod tạm thời vốn liên tục thay đổi trong quá trình rolling update.

2. Layer 7 Service Mesh Proxy

Ưu điểm: Khả năng trace HTTP/gRPC phong phú; đo lường chi tiết các golden signal (độ trễ, tỷ lệ lỗi); hỗ trợ mutual TLS (mTLS) trong suốt.
Nhược điểm: Tiêu tốn nhiều tài nguyên (thường ngốn hơn 100MB RAM cho mỗi replica của workload); không thể quan sát traffic non-TCP và các trường hợp drop ở kernel tầng thấp; vòng đời inject và nâng cấp dễ phát sinh lỗi.

3. Cilium kết hợp với Hubble

Ưu điểm: Overhead thu thập gói tin ở cấp kernel gần như không đáng kể; quan sát L3/L4/L7 nguyên bản mà không cần sidecar; tự động ánh xạ các luồng dữ liệu thô sang Kubernetes label; phản hồi tức thì về các gói tin bị chặn dựa trên các quy tắc CiliumNetworkPolicy đang áp dụng.
Nhược điểm: Yêu cầu Linux kernel hiện đại (Linux 5.4 trở lên; khuyến nghị Linux 5.10+); bắt buộc phải triển khai Cilium làm CNI chính hoặc chạy theo dạng chaining đè lên CNI hiện có.

Kiến trúc Đề xuất: Stack Giám sát eBPF Bền bỉ

Khi sự cố xảy ra, các agent ghi log bị nghẽn do traffic tăng cao còn tệ hơn là không có gì. Cilium loại bỏ nút thắt cổ chai này bằng cách tách biệt khâu kiểm tra gói tin trong kernel với khâu tổng hợp dữ liệu ở user-space:

Cilium Agent (DaemonSet): Load mã bytecode eBPF vào các network interface của node, chẳng hạn như veth pair và card mạng vật lý (NIC). Nó đẩy metadata của flow vào các per-CPU ring buffer trực tiếp bên trong kernel space.
Hubble Server (tích hợp sẵn trong Cilium Agent): Lưu trữ các flow gần đây trong một ring buffer 4.096 mục trên bộ nhớ RAM của từng node. Bộ nhớ đệm cục bộ này giúp mạng của bạn không bị quá tải khi lưu lượng traffic tăng đột biến.
Hubble Relay: Một deployment tập trung, gọn nhẹ, kết nối tới gRPC socket cục bộ trên từng node, gom toàn bộ flow trong toàn cụm về một endpoint duy nhất để truy vấn.
Hubble CLI & UI: Bàn điều khiển dành cho kỹ sư vận hành. CLI cung cấp khả năng lọc theo luồng stream tức thì ngay trong terminal, trong khi UI tạo biểu đồ phụ thuộc service trực quan và làm nổi bật các điểm bị drop gói tin theo thời gian thực.

Hướng dẫn Triển khai: Từ Con số 0 đến Giám sát Flow Thời gian thực

Khi các service âm thầm gặp lỗi, việc truy vết luồng gói tin ở tầng kernel chỉ trong vài giây chính là ranh giới giữa một ca trực xử lý xong sau mười phút và một buổi post-mortem kéo dài sáu tiếng.

Bước 1: Cài đặt Cilium và Kích hoạt Hubble cùng Relay

Triển khai hoặc nâng cấp Cilium bằng Helm chart chính thức, chú ý kích hoạt tường minh Hubble Relay, web UI và các bộ đo lường metric cốt lõi:

helm repo add cilium https://helm.cilium.io/
helm repo update

helm upgrade --install cilium cilium/cilium \
  --namespace kube-system \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true \
  --set hubble.metrics.enabled="{dns,drop,tcp,flow,port-distribution,icmp,http}"

Kiểm tra trạng thái rollout trên toàn bộ cluster của bạn:

kubectl rollout status daemonset/cilium -n kube-system
kubectl rollout status deployment/hubble-relay -n kube-system
kubectl rollout status deployment/hubble-ui -n kube-system

Bước 2: Cài đặt và Kết nối Hubble CLI

Web dashboard rất hữu ích cho việc đánh giá kiến trúc tổng quan. Tuy nhiên, khi cần ứng cứu sự cố trực tiếp, CLI độc lập mới là vũ khí sắc bén nhất. Tải file binary client chính thức:

export HUBBLE_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/hubble/master/stable.txt)
curl -L --fail --remote-name "https://github.com/cilium/hubble/releases/download/${HUBBLE_VERSION}/hubble-linux-amd64.tar.gz"
tar xzvf hubble-linux-amd64.tar.gz
sudo mv hubble /usr/local/bin/
rm hubble-linux-amd64.tar.gz

Tiếp theo, forward port của Hubble Relay chạy dưới nền:

cilium hubble port-forward &

Kiểm tra xem CLI trên máy cục bộ đã giao tiếp được với cluster chưa:

hubble status

Lệnh này sẽ báo cáo rằng Hubble Relay đang hoạt động ổn định (healthy) và đã kết nối tới 100% các node (ví dụ: Connected Nodes: 12/12).

Bước 3: Truy lùng Traffic Bị Drop trong Thời gian thực

Quay lại với sự cố lúc 2:14 sáng: pod checkout không thể gọi sang API của payment. Hãy quên việc grep log thủ công đi—chúng ta sẽ stream trực tiếp toàn bộ các gói tin bị drop trên toàn cluster:

hubble observe --verdict DROPPED --follow

Terminal của bạn cuộn quá nhanh? Hãy thu hẹp phạm vi truy vấn vào namespace production và deployment payment:

hubble observe \
  --namespace production \
  --to-label app=payment \
  --verdict DROPPED \
  -o compact

Chỉ trong vài giây, eBPF sẽ log sự kiện drop cùng nguyên nhân chính xác từ kernel:

TIMESTAMP             SOURCE                                 DESTINATION                         TYPE             VERDICT
Nov 07 02:18:41.102   production/checkout-6d48b99-xk92w:42180   production/payment-574b6df-j9xkp:8080   Policy denied    DROPPED (Policy denied (Ingress))

Thủ phạm đã lộ diện. Một ingress policy đang hiệu lực đã chặn gói tin ngay tại virtual interface của payment container. Không cần phỏng đoán, không cần packet capture, cũng chẳng cần restart pod trong mù quáng.

Bước 4: Kiểm tra và Khắc phục Lỗi Network Policy Không Khớp

Hãy cùng kiểm tra các policy đang áp dụng cho payment service:

kubectl get ciliumnetworkpolicies -n production -o yaml

Bạn đã nhận ra vấn đề chưa? Policy yêu cầu traffic đi vào phải đến từ các pod có label tier: frontend. Tuy nhiên, đợt deployment pipeline gần nhất đã cập nhật selector của checkout thành app: checkout mà chưa sửa lại các rule mạng. Hãy khắc phục điều này bằng một CiliumNetworkPolicy tường minh:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: allow-checkout-to-payment
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: payment
  ingress:
  - fromEndpoints:
    - matchLabels:
      app: checkout
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP

Apply policy đã chỉnh sửa:

kubectl apply -f allow-checkout-to-payment.yaml

Bước 5: Xác thực Policy đã có Hiệu lực và Giám sát Flow Layer 7

Cứ để luồng terminal của bạn tiếp tục chạy. Chưa đầy một giây sau khi apply manifest, các sự kiện drop dừng hẳn và trạng thái các gói tin lập tức chuyển từ DROPPED sang FORWARDED:

hubble observe \
  --namespace production \
  --from-pod checkout \
  --to-pod payment \
  --protocol tcp \
  --follow

Bạn cũng muốn kiểm tra cả tầng ứng dụng? Hãy thêm cờ --protocol http để quan sát HTTP status code và độ trễ đường truyền:

hubble observe \
  --namespace production \
  --to-label app=payment \
  --protocol http \
  -o dict

Giờ đây bạn đã có thể thấy các request HTTP POST /charge trả về 200 OK với độ trễ chỉ trong vòng 12ms. Sự cố đã được xử lý dứt điểm, được xác nhận bởi telemetry từ kernel và chứng minh bằng số liệu chuẩn xác ngay cả trước khi kênh on-call kịp thức giấc.