Kubernetes 故障排查：日志收集与链路追踪

在 Kubernetes（K8s）集群中，故障排查是运维的关键环节。日志收集帮助捕获应用和系统的运行时信息，而链路追踪（Trace）则用于可视化请求在微服务间的流转路径。两者结合，能快速定位性能瓶颈、错误源头。以下我将逐步解释核心概念、工具选择、实现步骤，并提供示例配置。整个过程基于真实实践，确保可靠性。

1. 日志收集：基础与实现

日志是故障排查的“第一手资料”。K8s 中，Pod 日志通常输出到 stdout/stderr，需通过日志收集器聚合到中央存储（如 Elasticsearch），便于查询和分析。

为什么重要？

• 捕获应用错误、资源使用情况（如内存泄漏）。
• 支持实时监控和历史回溯。
• 例如，当 Pod 崩溃时，日志能显示错误堆栈。

常用工具：

• Fluentd：轻量级日志收集器，支持多种输入/输出插件。
• Filebeat：作为 Elastic Stack 的一部分，高效收集文件日志。
• 存储后端：Elasticsearch（索引和搜索）+ Kibana（可视化），构成 EFK 堆栈。

部署步骤：

1. 设置 DaemonSet：在 K8s 每个节点部署日志收集器，确保所有 Pod 日志被捕获。
2. 配置收集规则：定义日志源（如容器日志路径）和目标（如 Elasticsearch）。
3. 验证与查询：使用 Kibana 界面搜索日志。

示例配置（Fluentd DaemonSet） 以下 YAML 文件定义了一个 Fluentd DaemonSet，将日志发送到 Elasticsearch。保存为 fluentd-daemonset.yaml 并应用（kubectl apply -f fluentd-daemonset.yaml）。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      tolerations:
        - key: node-role.kubernetes.io/master
          effect: NoSchedule
      containers:
        - name: fluentd
          image: fluent/fluentd-kubernetes-daemonset:v1.16-debian-elasticsearch8
          env:
            - name: FLUENT_ELASTICSEARCH_HOST
              value: "elasticsearch-logging"  # Elasticsearch 服务名
            - name: FLUENT_ELASTICSEARCH_PORT
              value: "9200"
          volumeMounts:
            - name: varlog
              mountPath: /var/log
            - name: varlibdockercontainers
              mountPath: /var/lib/docker/containers
              readOnly: true
      volumes:
        - name: varlog
          hostPath:
            path: /var/log
        - name: varlibdockercontainers
          hostPath:
            path: /var/lib/docker/containers

最佳实践：

• 添加日志标签（如 Pod 名称、命名空间），便于过滤。
• 设置日志轮转，避免磁盘爆满。
• 监控日志量：如果日志速率超过阈值（例如，每秒 1000 条），可能表示异常。

2. 链路追踪：原理与集成

链路追踪用于追踪请求在微服务间的路径，帮助识别延迟或错误点。在 K8s 的分布式环境中，这尤其关键。

为什么重要？

• 可视化请求流：例如，一个 HTTP 请求从 Ingress 到 Service A，再到 Service B。
• 定位瓶颈：如果某个服务延迟高，追踪能显示具体阶段。
• 支持根因分析：结合日志，能复现错误场景。

常用工具：

• Jaeger：开源分布式追踪系统，支持 OpenTelemetry 标准。
• Zipkin：轻量级替代方案，易于集成。
• OpenTelemetry（OTel）：标准 SDK，用于在应用中注入追踪数据。

部署步骤：

1. 注入 SDK：在应用代码中添加 OTel 库（如 Python 的 opentelemetry-instrumentation）。
2. 部署 Collector：在 K8s 中部署 OTel Collector，接收和转发追踪数据。
3. 设置后端：部署 Jaeger 或 Zipkin 作为存储和 UI。
4. 配置采样率：控制追踪数据量（例如，采样率 10% 以降低开销）。

示例配置（Jaeger 和 OTel Collector） 首先，部署 Jaeger（保存为 jaeger-deployment.yaml）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: jaeger
spec:
  replicas: 1
  selector:
    matchLabels:
      app: jaeger
  template:
    metadata:
      labels:
        app: jaeger
    spec:
      containers:
        - name: jaeger
          image: jaegertracing/all-in-one:1.40
          ports:
            - containerPort: 16686  # Jaeger UI 端口
            - containerPort: 14268  # 接收追踪数据端口
---
apiVersion: v1
kind: Service
metadata:
  name: jaeger
spec:
  selector:
    app: jaeger
  ports:
    - protocol: TCP
      port: 16686
      targetPort: 16686

然后，部署 OTel Collector（保存为 otel-collector.yaml）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: otel-collector
spec:
  replicas: 1
  selector:
    matchLabels:
      app: otel-collector
  template:
    metadata:
      labels:
        app: otel-collector
    spec:
      containers:
        - name: otel-collector
          image: otel/opentelemetry-collector-contrib:0.81.0
          command: ["/otelcol-contrib", "--config=/etc/otel/config.yaml"]
          volumeMounts:
            - name: config
              mountPath: /etc/otel
      volumes:
        - name: config
          configMap:
            name: otel-config
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-config
data:
  config.yaml: |
    receivers:
      otlp:
        protocols:
          grpc:
          http:
    exporters:
      jaeger:
        endpoint: "jaeger:14250"  # 指向 Jaeger 服务
        tls:
          insecure: true
    service:
      pipelines:
        traces:
          receivers: [otlp]
          exporters: [jaeger]

在应用中使用 OTel（Python 示例） 假设你的应用是 Python Flask 服务。添加以下代码以启用追踪：

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.instrumentation.flask import FlaskInstrumentor

# 初始化追踪
provider = TracerProvider()
processor = BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317"))  # OTel Collector 服务
provider.add_span_processor(processor)
trace.set_tracer_provider(provider)

# 在 Flask 应用中集成
from flask import Flask
app = Flask(__name__)
FlaskInstrumentor().instrument_app(app)

@app.route('/')
def hello():
    return "Hello, World!"

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

3. 结合日志与链路追踪进行故障排查

日志提供细节，追踪提供上下文。结合使用能高效定位问题。

排查流程：

1. 触发警报：如通过 Prometheus 监控到高错误率。
2. 查询日志：在 Kibana 中过滤错误日志（例如，搜索 ERROR 级别）。
3. 查看追踪：在 Jaeger UI 中输入 Trace ID（通常日志中包含），可视化请求路径。
4. 关联分析：如果追踪显示某个服务超时，检查其日志以确认原因（如数据库连接失败）。

示例场景：

• 问题：用户请求超时，返回 HTTP 500。
• 步骤：
  • 在 Kibana 中搜索相关 Pod 日志，发现 Service B 抛出 TimeoutException。
  • 在 Jaeger 中搜索 Trace ID，看到请求卡在 Service B 调用外部 API。
  • 解决方案：优化 Service B 的超时设置或扩容。

最佳实践：

• 统一标识：在日志和追踪中使用相同的 Trace ID，便于关联。例如，在日志中输出 trace_id=$trace_id。
• 采样策略：生产环境中设置动态采样（如错误请求 100% 采样，正常请求 1%）。
• 资源开销：监控收集器资源使用（CPU/内存），避免影响应用性能。
• 安全：使用 TLS 加密数据传输，确保 Elasticsearch/Jaeger 访问控制。

通过以上步骤，您可以构建健壮的 K8s 故障排查体系。实践中，建议从小规模测试开始，逐步优化配置。如果您有具体场景（如特定错误代码），可提供更多细节，我会给出针对性建议！