当 Service 间调用偶发超时,或 NetworkPolicy
生效后某些流量被意外丢弃,该如何定位问题?传统
tcpdump 在数百
Pod、数十节点的集群中效率远远不够。
网络可观测性(Network Observability)将网络行为从”黑盒”变为”白盒”,让每一个数据包的路径、每一条连接的状态、每一次策略判定都变得可见、可查、可告警。
本文按三个递进层次构建完整的 Kubernetes 网络可观测性体系:
- 经典工具层:tcpdump/tshark、ss/conntrack/nstat、iptables 规则审计
- eBPF 原生层:Hubble 实时流观测、Tetragon 进程级事件、bpftrace 自定义探针
- 全栈可观测层:Pixie 自动协议捕获、Grafana+Prometheus 指标体系、Jaeger/Tempo 分布式追踪
最终将三层串联为一条完整的排查 Pipeline:指标告警 -> 流日志定位 -> 抓包根因分析。
一、网络可观测性的三个支柱
指标(Metrics)
聚合的数值型时间序列,回答”发生了多少”:
- 网络层:TCP 重传率、连接建立/关闭速率、丢包率
- 服务层:请求延迟 P99、错误率、吞吐量(RED 方法)
- 基础设施层:节点网卡流量、conntrack 表使用率、iptables 规则命中数
指标存储成本低、查询速度快,适合长期趋势分析和告警触发。
日志(Logs)
离散的事件记录,回答”发生了什么”:
- 流日志:Hubble 记录的每一条 L3/L4/L7 网络流
- 审计日志:NetworkPolicy 的 ALLOW/DENY 判定
- DNS 日志:DNS 查询和应答的详细记录
日志提供比指标更丰富的上下文,但存储成本更高,通常需要采样。
追踪(Traces)
请求跨越多个服务的完整路径,回答”瓶颈在哪里”:
- Span:一次 RPC 调用的开始、结束时间和状态码
- Trace:多个 Span 组成的有向无环图,描绘请求全路径
- 网络延迟归因:哪段延迟来自 DNS?哪段来自 TCP 握手?哪段来自服务处理?
三者之间的关联逻辑是:指标发现异常 -> 日志定位事件 -> 追踪还原路径。
二、第一层:经典工具
经典工具是网络排查的基石。即使有了 eBPF 平台,深度排查时仍然离不开它们。关键在于掌握容器环境中的正确用法。
tcpdump/tshark 在容器 netns 中的技巧
Pod 运行在独立的 Network Namespace 中,直接在宿主机上执行 tcpdump 无法捕获 Pod 内部流量。
方法一:crictl + nsenter 进入 netns
# 找到容器 PID
PID=$(crictl inspect --output go-template \
--template '{{.info.pid}}' <CONTAINER_ID>)
# 进入 netns 抓包
nsenter -t $PID -n tcpdump -i eth0 -nn -w capture.pcap
# BPF 过滤表达式缩小范围
nsenter -t $PID -n tcpdump -i eth0 -nn \
'tcp port 8080 and (tcp[tcpflags] & (tcp-syn|tcp-rst) != 0)'方法二:kubectl debug 注入临时调试容器
kubectl debug -it my-app-pod \
--image=nicolaka/netshoot \
--target=my-app \
-- tcpdump -i eth0 -nn -c 100netshoot 镜像内含
tcpdump、tshark、curl、dig、ss
等常用工具,适合一次性排查。
tshark 高级用法:解码应用层协议
# 解码 HTTP 请求/响应
nsenter -t $PID -n tshark -i eth0 -Y 'http' \
-T fields -e http.request.method -e http.request.uri \
-e http.response.code -e http.time
# 解码 DNS 查询
nsenter -t $PID -n tshark -i eth0 -Y 'dns' \
-T fields -e dns.qry.name -e dns.resp.addr -e dns.timess/conntrack/nstat 看连接状态
三个工具从不同角度观测连接状态:
ss:socket 级别连接信息
# TCP 连接(含进程信息)
nsenter -t $PID -n ss -tnpi
# TIME_WAIT 数量(端口耗尽前兆)
nsenter -t $PID -n ss -tan state time-wait | wc -l
# socket 内存和拥塞窗口
nsenter -t $PID -n ss -tnmi
# 输出:cubic wscale:7,7 rto:204 rtt:1.5/0.75 cwnd:10
# 按目的地址汇总连接数
nsenter -t $PID -n ss -tn | awk '{print $5}' | \
cut -d: -f1 | sort | uniq -c | sort -rn | head -20conntrack:Netfilter 连接跟踪表
# 按状态过滤
conntrack -L -p tcp --state ESTABLISHED
# 表容量和使用量
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max
# 实时监听事件
conntrack -Enstat:内核网络计数器
# TCP 重传相关指标
nstat -az | grep -i retrans
# TcpRetransSegs 142 0.0
# TcpTimeouts 23 0.0
# 每秒刷新观察趋势
nstat -az -d 1 | grep TcpRetransSegsiptables 规则命中统计
在 kube-proxy iptables 模式下,规则命中计数器可以判断流量是否按预期转发:
# NAT 表 Service 转发规则
iptables -t nat -L KUBE-SERVICES -v -n --line-numbers
# 某个 Service 的后端选择
iptables -t nat -L KUBE-SVC-XXXXXXXXXXXXXXXX -v -n
# filter 表 NetworkPolicy 规则
iptables -t filter -L KUBE-NWPLCY-XXXXXXXX -v -n
# 找 DROP 规则及命中计数
iptables -t filter -L -v -n | grep -i drop排查示例:Service 访问超时
# 1. 确认 Service ClusterIP
kubectl get svc my-service -o wide
# 2. 追踪 iptables 链
iptables -t nat -L KUBE-SERVICES -v -n | grep "10.96.100.200"
# 3. 检查后端 Endpoint(pkts 列为 0 说明流量未到达)
iptables -t nat -L KUBE-SVC-XXXXXXX -v -n
# 4. conntrack 确认 DNAT
conntrack -L -d 10.96.100.200
# 5. Pod 内抓包
nsenter -t $PID -n tcpdump -i eth0 -nn 'host 10.96.100.200'三、第二层:eBPF 原生可观测
经典工具需要手动操作,不适合大规模持续监控。eBPF 在内核层面高效安全地采集网络数据,几乎不影响性能。
关于 eBPF 基础知识,请参考 eBPF 与 bpftrace 实战 和 eBPF 性能分析。
Hubble:Cilium 的网络可观测引擎
Hubble 是 Cilium CNI 内置的可观测组件,核心优势:零侵入(无需 sidecar)、高性能(内核态运行)、语义丰富(L3-L7 + DNS + 策略判定)。
启用 Hubble
cilium install --set hubble.enabled=true \
--set hubble.relay.enabled=true \
--set hubble.ui.enabled=true \
--set hubble.metrics.enableOpenMetrics=true
# 验证状态
cilium hubble port-forward &
hubble statushubble observe:实时网络流观测
# 按 namespace 过滤
hubble observe --namespace default
# 只看被丢弃的流量
hubble observe --verdict DROPPED
# 组合过滤:某 Pod 的 HTTP 丢弃流量
hubble observe --pod default/my-app \
--protocol http --verdict DROPPED
# JSON 输出便于后续处理
hubble observe --output json | jq '.flow.source.namespace'典型输出:
TIMESTAMP SOURCE DESTINATION TYPE VERDICT SUMMARY
2026-04-03T10:15:32 default/frontend-xxx default/backend-yyy L4 FORWARDED TCP SYN
2026-04-03T10:15:32 default/frontend-xxx default/backend-yyy L7 FORWARDED HTTP GET /api/users 200 2ms
2026-04-03T10:15:33 default/backend-yyy kube-system/coredns L7 FORWARDED DNS Query db.default A
2026-04-03T10:15:35 default/test-pod default/backend-yyy L4 DROPPED Policy denied
每条流包含:时间戳、源/目的 Pod 身份、L3/L4/L7 类型、判定结果(FORWARDED/DROPPED/ERROR)、摘要。
DNS 审计与策略判定
# DNS 查询与解析失败
hubble observe --protocol dns --verdict DROPPED
# 策略判定详情
hubble observe --verdict DROPPED --output json | \
jq '{src: .flow.source.labels, dst: .flow.destination.labels,
policy: .flow.drop_reason_desc}'Hubble Relay + UI:跨节点聚合
单节点 Hubble 只能看到本节点流量。Hubble Relay 通过 gRPC 聚合所有节点数据:
# 全集群观察
hubble observe --server localhost:4245
# Hubble UI
kubectl port-forward -n kube-system svc/hubble-ui 12000:80Hubble UI 提供三个核心视图:Service Map(服务调用关系图)、Flow Table(实时流表)、Policy Verdict(策略命中详情)。
Hubble Metrics 导出到 Prometheus
hubble:
metrics:
enabled:
- dns
- drop
- tcp
- flow
- httpV2:exemplars=true;labelsContext=source_ip,source_namespace,destination_ip,destination_namespace
serviceMonitor:
enabled: true关键指标:
| 指标名称 | 说明 |
|---|---|
hubble_flows_processed_total |
已处理网络流总数 |
hubble_drop_total |
丢弃包总数(按原因分类) |
hubble_dns_queries_total |
DNS 查询总数 |
hubble_tcp_flags_total |
TCP 标志位统计(SYN/FIN/RST) |
hubble_http_requests_total |
HTTP 请求总数(按方法/状态码) |
hubble_http_request_duration_seconds |
HTTP 请求延迟分布 |
Tetragon:进程级网络事件
Tetragon 比 Hubble 粒度更细:不仅看到网络流,还能看到哪个进程、哪个系统调用产生的。
helm install tetragon cilium/tetragon -n kube-system
# 查看进程级事件
kubectl exec -n kube-system ds/tetragon -c tetragon -- \
tetra getevents -o compact
# 输出:
# connect default/my-app /usr/bin/curl -> 10.96.0.1:443
# sendmsg default/my-app /usr/bin/python -> 10.96.100.200:8080
# accept default/backend /usr/bin/node <- 10.244.1.5:42316TracingPolicy 自定义观测
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: tcp-connect-monitor
spec:
kprobes:
- call: "tcp_v4_connect"
syscall: false
args:
- index: 0
type: "sock"
selectors:
- matchNamespaces:
- namespace: default
operator: In
values: ["default", "production"]
return: true
returnArg:
index: 0
type: "int"自定义 eBPF 网络探针:bpftrace
当 Hubble 和 Tetragon 无法满足特定需求时,bpftrace 可以编写一次性诊断探针。
追踪 TCP 重传事件
bpftrace -e '
tracepoint:tcp:tcp_retransmit_skb {
printf("retransmit: %s:%d -> %s:%d state=%d\n",
ntop(args->saddr), args->sport,
ntop(args->daddr), args->dport,
args->state);
}'追踪 conntrack 事件
bpftrace -e '
kprobe:nf_conntrack_hash_check_insert {
printf("conntrack insert: comm=%s pid=%d\n", comm, pid);
}
kprobe:nf_ct_delete {
printf("conntrack delete: comm=%s pid=%d\n", comm, pid);
}'测量 TCP 连接建立延迟
bpftrace -e '
kprobe:tcp_v4_connect {
@start[tid] = nsecs;
}
kretprobe:tcp_v4_connect /@start[tid]/ {
$dur = (nsecs - @start[tid]) / 1000;
printf("connect latency: %d us, comm=%s\n", $dur, comm);
@latency = hist($dur);
delete(@start[tid]);
}'四、第三层:全栈可观测
第三层将 Metrics、Logs、Traces 统一到一个平台,实现从宏观到微观的无缝切换。
Pixie:eBPF 驱动的自动协议捕获
Pixie(CNCF 沙箱项目)用 eBPF 自动捕获应用层协议,无需代码修改或 sidecar。支持 HTTP/1.1、HTTP/2(含 gRPC)、MySQL、PostgreSQL、Redis、Kafka、DNS 等协议。
# 安装与部署
bash -c "$(curl -fsSL https://withpixie.ai/install.sh)"
px deploy
px get viziersPxL 脚本查询
# 查看 HTTP 错误
import px
df = px.DataFrame(table='http_events', start_time='-5m')
df = df[df.ctx['namespace'] == 'default']
df.resp_status = df.resp_status.astype('int64')
df = df[['time_', 'source', 'destination', 'req_method',
'req_path', 'resp_status', 'latency']]
df = df[df.resp_status >= 400]
px.display(df, 'HTTP Errors')# 按 Service 聚合延迟 P99
import px
df = px.DataFrame(table='http_events', start_time='-10m')
df.service = df.ctx['service']
df = df.groupby('service').agg(
count=('latency', px.count),
p50=('latency', px.quantiles, 0.5),
p99=('latency', px.quantiles, 0.99),
error_rate=('resp_status', lambda x: px.mean(x >= 400)),
)
px.display(df, 'Service Latency Summary')Grafana + Prometheus + kube-state-metrics
kube-state-metrics 网络相关指标
kube_pod_status_phase{phase="Running"}
kube_endpoint_address_available
kube_endpoint_address_not_ready
kube_networkpolicy_labelsnode-exporter 节点级网络指标
# 网卡流量速率
rate(node_network_receive_bytes_total{device="eth0"}[5m])
rate(node_network_transmit_bytes_total{device="eth0"}[5m])
# conntrack 使用率
node_nf_conntrack_entries / node_nf_conntrack_entries_limit
# TCP socket 统计
node_sockstat_TCP_tw
node_sockstat_TCP_alloc
Prometheus 告警规则
groups:
- name: kubernetes-network
rules:
- alert: ConntrackTableNearlyFull
expr: >
node_nf_conntrack_entries / node_nf_conntrack_entries_limit > 0.8
for: 5m
labels:
severity: warning
annotations:
summary: "conntrack 表使用率超过 80%"
- alert: HighTCPRetransmissions
expr: >
rate(node_netstat_Tcp_RetransSegs[5m]) /
rate(node_netstat_Tcp_OutSegs[5m]) > 0.01
for: 10m
labels:
severity: warning
annotations:
summary: "TCP 重传率超过 1%"
- alert: HubbleHighDropRate
expr: rate(hubble_drop_total[5m]) > 100
for: 5m
labels:
severity: critical
annotations:
summary: "Hubble 检测到高丢包率"
description: "丢包原因:{{ $labels.reason }}"
- alert: HighDNSFailureRate
expr: >
rate(hubble_dns_responses_total{rcode!="No Error"}[5m]) /
rate(hubble_dns_responses_total[5m]) > 0.05
for: 5m
labels:
severity: warning
annotations:
summary: "DNS 解析失败率超过 5%"Grafana Dashboard 关键面板
| 面板 | PromQL |
|---|---|
| 节点网络吞吐量 | rate(node_network_*_bytes_total[5m]) |
| TCP 连接状态 | node_sockstat_TCP_* |
| conntrack 使用率 | node_nf_conntrack_entries / limit |
| Hubble 流量概览 | rate(hubble_flows_processed_total[5m]) |
| Hubble 丢包详情 | rate(hubble_drop_total[5m]) by reason |
| HTTP 延迟 P99 | histogram_quantile(0.99, hubble_http_*) |
Jaeger/Tempo:分布式追踪网络延迟
OpenTelemetry 集成架构
应用程序
└── OTel SDK / Auto-Instrumentation
└── OTLP Exporter
└── OpenTelemetry Collector
├── Jaeger (追踪存储/查询)
└── Tempo (Grafana 追踪后端)
Tempo 核心配置
apiVersion: v1
kind: ConfigMap
metadata:
name: tempo-config
namespace: monitoring
data:
tempo.yaml: |
server:
http_listen_port: 3200
distributor:
receivers:
otlp:
protocols:
grpc:
endpoint: "0.0.0.0:4317"
storage:
trace:
backend: local
local:
path: /var/tempo/traces
metrics_generator:
processor:
service_graphs:
dimensions: [k8s.namespace.name, k8s.pod.name]网络延迟归因
一个典型的微服务调用延迟可以分解为:
总延迟 = DNS 解析 + TCP 握手 + TLS 协商 + 请求排队 + 服务处理 + 响应传输
[frontend] ── GET /api/orders ──────────────────── 150ms
[gateway] ── route + auth ────────── 20ms
[order-svc] ── query DB ─────── 80ms
[mysql] ── SQL exec ──── 60ms
[order-svc] ── call inventory ── 40ms
[inventory-svc] ── check ── 30ms
通过 TraceQL 定位网络延迟异常:
{ duration > 500ms }
{ span.service.name = "order-service" && duration > 200ms }
{ status = error }
Hubble 流日志与 Trace 关联
通过 Pod 名称和 namespace 标签,将网络层流日志与应用层 Trace 关联:
# Trace 中找到慢请求的 Pod,再查 Hubble 对应的网络流
hubble observe --pod default/order-svc-xxx \
--since "2026-04-03T10:15:00Z" \
--until "2026-04-03T10:15:05Z"五、构建完整排查 Pipeline
三层工具串联为五步排查法:
第一步:指标告警发现异常
Prometheus AlertManager
├── ConntrackTableNearlyFull → 连接跟踪表即将满
├── HighTCPRetransmissions → 网络质量恶化
├── HubbleHighDropRate → 策略或路由丢包
└── HighDNSFailureRate → DNS 解析问题
先在 Grafana Dashboard 查看宏观趋势:异常是突发还是渐变?全局还是局部?
第二步:Hubble 流日志定位范围
hubble observe --namespace default --verdict DROPPED --last 100
# 汇总丢包原因
hubble observe --namespace default --verdict DROPPED -o json | \
jq -r '.flow.drop_reason_desc' | sort | uniq -c | sort -rn常见丢包原因:
| drop_reason | 含义 | 排查方向 |
|---|---|---|
POLICY_DENIED |
NetworkPolicy 拒绝 | 检查 CiliumNetworkPolicy |
CT_MAP_INSERTION_FAILED |
conntrack 表满 | 调大 bpf-ct-global-max |
NO_TUNNEL_ENDPOINT |
隧道端点不存在 | 检查节点间隧道 |
INVALID_PACKET |
数据包格式异常 | 抓包分析 |
第三步:Tetragon/Pixie 定位进程
# Tetragon 查看异常连接的进程
kubectl exec -n kube-system ds/tetragon -c tetragon -- \
tetra getevents --namespace default --process-name my-app
# Pixie 查看应用层协议
px run px/http_data -- --start_time=-5m --namespace=default第四步:经典工具深度抓包
PID=$(crictl inspect --output go-template \
--template '{{.info.pid}}' <CONTAINER_ID>)
nsenter -t $PID -n tcpdump -i eth0 -nn -w debug.pcap 'tcp port 8080'
# tshark 分析重传
tshark -r debug.pcap -Y 'tcp.analysis.retransmission' \
-T fields -e frame.time -e ip.src -e ip.dst -e tcp.analysis.rto第五步:根因确认与修复
| 根因 | 现象 | 修复 |
|---|---|---|
| NetworkPolicy 错误 | Hubble POLICY_DENIED | 修改策略 spec |
| conntrack 表满 | nstat insert_failed | 调大 nf_conntrack_max |
| DNS 超时 | Hubble DNS 延迟高 | 扩容 CoreDNS / NodeLocal DNSCache |
| MTU 不匹配 | tcpdump 分片/ICMP need-frag | 统一 MTU 配置 |
| TCP 连接泄漏 | ss 大量 CLOSE_WAIT | 修复应用层连接释放 |
六、实验:部署 Hubble + Grafana 完整排查链
环境准备
# Cilium + Hubble
cilium install \
--set hubble.enabled=true \
--set hubble.relay.enabled=true \
--set hubble.ui.enabled=true \
--set hubble.metrics.enableOpenMetrics=true \
--set hubble.metrics.enabled="{dns,drop,tcp,flow,httpV2:exemplars=true;labelsContext=source_ip,source_namespace,destination_ip,destination_namespace}"
cilium status --wait
# Prometheus + Grafana
helm repo add prometheus-community \
https://prometheus-community.github.io/helm-charts
helm install kube-prom prometheus-community/kube-prometheus-stack \
-n monitoring --create-namespace \
--set grafana.enabled=true \
--set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false部署测试应用
apiVersion: apps/v1
kind: Deployment
metadata:
name: http-server
spec:
replicas: 2
selector:
matchLabels:
app: http-server
template:
metadata:
labels:
app: http-server
spec:
containers:
- name: server
image: nginx:alpine
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: http-server
spec:
selector:
app: http-server
ports:
- port: 80
targetPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: http-client
spec:
replicas: 1
selector:
matchLabels:
app: http-client
template:
metadata:
labels:
app: http-client
spec:
containers:
- name: client
image: curlimages/curl:latest
command: ["/bin/sh", "-c"]
args:
- |
while true; do
curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" \
http://http-server/
sleep 1
done制造丢包并排查
# deny-policy.yaml -- http-client 标签不匹配,流量被拒绝
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: restrict-http-server
spec:
endpointSelector:
matchLabels:
app: http-server
ingress:
- fromEndpoints:
- matchLabels:
app: http-client-authorized
toPorts:
- ports:
- port: "80"
protocol: TCP# 应用策略
kubectl apply -f deny-policy.yaml
# 排查步骤一:Hubble 观察丢包
hubble observe --namespace default --verdict DROPPED
# 输出:http-client -> http-server DROPPED Policy denied
# 排查步骤二:查看详细原因
hubble observe --namespace default --verdict DROPPED -o json | \
jq '{src: .flow.source.labels, dst: .flow.destination.labels,
reason: .flow.drop_reason_desc}'
# 排查步骤三:确认策略内容
kubectl describe cnp restrict-http-server
# 排查步骤四:修复
kubectl label pod -l app=http-client \
app=http-client-authorized --overwrite
# 排查步骤五:验证
hubble observe --namespace default --last 10
# 状态变为 FORWARDEDGrafana 告警配置
kubectl port-forward -n monitoring svc/kube-prom-grafana 3000:80
# 导入 Hubble Dashboard(ID: 16611)告警规则示例:
name: Network Policy Drops
condition: rate(hubble_drop_total{reason="POLICY_DENIED"}[5m]) > 10
for: 2m
annotations:
summary: "NetworkPolicy 拒绝了大量流量"
runbook: "hubble observe --verdict DROPPED 查看详情"七、生产环境最佳实践
采样与存储策略
hubble:
eventBufferCapacity: 4096
metrics:
enabled:
- dns
- drop
- "tcp:sourceContext=pod;destinationContext=pod"
- "httpV2:exemplars=true;sourceContext=pod;destinationContext=pod"存储分层:
- 短期(小时级):Hubble
内存环形缓冲区,
hubble observe直接查看 - 中期(天级):导出到 Loki / Elasticsearch,Grafana 查询
- 长期(月级):仅保留 Prometheus 聚合指标,原始流日志按策略过期
性能开销参考
| 组件 | CPU | 内存/节点 | 说明 |
|---|---|---|---|
| Hubble Agent | < 1% | 50-200 MB | 取决于流量和配置 |
| Hubble Relay | < 0.5% | 100-500 MB | 取决于节点数 |
| Tetragon | < 1% | 50-150 MB | 取决于 TracingPolicy 数量 |
| Pixie PEM | 2-5% | 500 MB-2 GB | 协议解码开销较大 |
# 查看 eBPF 程序 CPU 使用
bpftool prog show
# 监控 Hubble 资源
kubectl top pod -n kube-system -l k8s-app=hubble-relay多集群架构
集群 A 集群 B
Hubble ─┐ Hubble ─┐
OTel ─┤ ┌──────────┐ OTel ─┤
Prom ─┴───→│ Thanos │←──────────┘
│ Loki │
│ Tempo │
└─────┬────┘
│
┌──────────┐
│ Grafana │
└──────────┘
关键要点:Prometheus 联邦或 Thanos 做跨集群指标聚合;Loki 统一收集 Hubble 流日志;Tempo 做跨集群追踪后端;Grafana 配置多数据源统一展示。
工具选型
| 场景 | 推荐组合 |
|---|---|
| 开发/测试 | tcpdump + kubectl debug |
| 小型生产(< 20 节点) | Hubble + Prometheus + Grafana |
| 中型生产(20-100 节点) | Hubble + Pixie + Grafana + Tempo |
| 大型生产(> 100 节点) | Hubble + Thanos + Tempo + Loki |
| 安全审计 | Hubble + Tetragon |
| 深度排查 | bpftrace + tcpdump + ss/conntrack |
八、总结
Kubernetes 网络可观测性是一个分层递进的体系:
第一层(经典工具) 提供最底层的排查能力。tcpdump/tshark 捕获原始数据包,ss/conntrack/nstat 观测连接状态,iptables 审计规则命中。核心技巧是正确进入 Pod 的 Network Namespace。
第二层(eBPF 原生) 将可观测性从”手动排查”提升到”持续监控”。Hubble 提供实时 L3-L7 流可视化和策略审计;Tetragon 细化到进程和系统调用级别;bpftrace 是内核级自定义探针的利器。
第三层(全栈可观测) 将 Metrics/Logs/Traces 统一到 Grafana 生态。Prometheus 负责指标和告警,Hubble/Loki 负责流日志,Jaeger/Tempo 负责分布式追踪,Pixie 补充无侵入的协议捕获。
三层并非互相替代,而是互补的。完整的排查 Pipeline 是:指标发现异常 -> 流日志缩小范围 -> 追踪定位链路 -> 抓包确认根因。掌握这套方法论,才能在复杂的 Kubernetes 网络环境中快速定位和解决问题。