土法炼钢兴趣小组的算法知识备份

Kubernetes 网络可观测性:从 tcpdump 到 Hubble 到 Pixie

目录

当 Service 间调用偶发超时,或 NetworkPolicy 生效后某些流量被意外丢弃,该如何定位问题?传统 tcpdump 在数百 Pod、数十节点的集群中效率远远不够。

网络可观测性(Network Observability)将网络行为从”黑盒”变为”白盒”,让每一个数据包的路径、每一条连接的状态、每一次策略判定都变得可见、可查、可告警。

本文按三个递进层次构建完整的 Kubernetes 网络可观测性体系:

  1. 经典工具层:tcpdump/tshark、ss/conntrack/nstat、iptables 规则审计
  2. eBPF 原生层:Hubble 实时流观测、Tetragon 进程级事件、bpftrace 自定义探针
  3. 全栈可观测层:Pixie 自动协议捕获、Grafana+Prometheus 指标体系、Jaeger/Tempo 分布式追踪

最终将三层串联为一条完整的排查 Pipeline:指标告警 -> 流日志定位 -> 抓包根因分析。

Kubernetes 网络可观测性分层架构

一、网络可观测性的三个支柱

指标(Metrics)

聚合的数值型时间序列,回答”发生了多少”:

指标存储成本低、查询速度快,适合长期趋势分析和告警触发。

日志(Logs)

离散的事件记录,回答”发生了什么”:

日志提供比指标更丰富的上下文,但存储成本更高,通常需要采样。

追踪(Traces)

请求跨越多个服务的完整路径,回答”瓶颈在哪里”:

三者之间的关联逻辑是:指标发现异常 -> 日志定位事件 -> 追踪还原路径

二、第一层:经典工具

经典工具是网络排查的基石。即使有了 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 100

netshoot 镜像内含 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.time

ss/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 -20

conntrack:Netfilter 连接跟踪表

# 按状态过滤
conntrack -L -p tcp --state ESTABLISHED

# 表容量和使用量
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

# 实时监听事件
conntrack -E

nstat:内核网络计数器

# TCP 重传相关指标
nstat -az | grep -i retrans
# TcpRetransSegs     142    0.0
# TcpTimeouts        23     0.0

# 每秒刷新观察趋势
nstat -az -d 1 | grep TcpRetransSegs

iptables 规则命中统计

在 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 status

hubble 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:80

Hubble 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:42316

TracingPolicy 自定义观测

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 viziers

PxL 脚本查询

# 查看 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_labels

node-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
# 状态变为 FORWARDED

Grafana 告警配置

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"

存储分层:

性能开销参考

组件 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 网络环境中快速定位和解决问题。


上一篇:Kubernetes NetworkPolicy 进阶:从 Calico 到 Cilium

下一篇:Kubernetes 网络故障排查实战手册


By .