一、K8s可观测性体系概述

1.1 可观测性三要素

K8s可观测性由指标（Metrics）、日志（Logging）、追踪（Tracing）三大支柱构成。其中监控聚焦实时指标（如CPU、内存、请求延迟），日志记录系统事件与错误详情，追踪分析请求链路。三者协同形成完整的故障诊断体系。

1.2 为什么需要可观测性？

K8s动态扩缩容特性导致传统监控失效，容器漂移、Pod重启等场景要求实时数据采集。以电商系统为例，双十一流量激增时，需通过监控快速定位数据库连接池耗尽问题，日志分析确认具体错误请求，最终通过扩容解决。

二、监控系统搭建实战

2.1 Metrics Server核心组件

作为K8s原生指标采集器，Metrics Server通过kubelet的Summary API获取节点/Pod资源使用数据。安装命令：

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

验证数据采集：

kubectl top nodes
# 输出示例
NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
node-1     245m         12%    3245Mi          41%

2.2 Prometheus监控方案

2.2.1 架构设计

采用Pull模式采集指标，通过ServiceMonitor CRD定义监控目标。关键组件：

• Prometheus Operator：自动化CRD管理
• Alertmanager：告警路由与抑制
• Grafana：可视化看板

2.2.2 部署实践

# prometheus-operator.yaml示例
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus-k8s
spec:
  serviceAccountName: prometheus-k8s
  resources:
    requests:
      memory: 400Mi
  storage:
    volumeClaimTemplate:
      spec:
        storageClassName: gp2
        resources:
          requests:
            storage: 10Gi

2.2.3 告警规则示例

# alert-rules.yaml
groups:
- name: node-memory
  rules:
  - alert: NodeMemoryUsage
    expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 > 85
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Node {{ $labels.instance }} memory usage high"

2.3 监控指标分类

指标类型	示例指标	应用场景
资源指标	cpu_usage_seconds_total	容器资源配额调整
工作负载指标	kube_pod_status_ready	部署健康检查
自定义业务指标	order_create_total	业务量趋势分析

三、日志系统构建方案

3.1 日志收集架构

主流方案对比：
| 方案 | 优点 | 缺点 |
|———————|———————————————-|———————————————-|
| DaemonSet | 节点级日志收集，资源隔离 | 需处理日志轮转 |
| Sidecar | 业务容器强关联 | 增加Pod资源开销 |
| Fluent Bit | 轻量级，支持多种输出 | 插件配置复杂 |

3.2 EFK日志栈部署

3.2.1 Elasticsearch配置优化

# es-statefulset.yaml关键配置
resources:
  limits:
    memory: "2Gi"
  requests:
    memory: "1Gi"
jvm.options:
  -Xms1g
  -Xmx1g

3.2.2 Filebeat Sidecar模式

# pod-with-filebeat.yaml
apiVersion: v1
kind: Pod
metadata:
  name: webapp
spec:
  containers:
  - name: webapp
    image: nginx
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: filebeat
    image: docker.elastic.co/beats/filebeat:7.10.2
    args: ["-e", "-c", "/etc/filebeat.yml"]
    volumeMounts:
    - name: varlog
      mountPath: /var/log
    - name: filebeat-config
      mountPath: /etc/filebeat.yml
      subPath: filebeat.yml
  volumes:
  - name: varlog
    emptyDir: {}
  - name: filebeat-config
    configMap:
      name: filebeat-config

3.3 日志分析技巧

3.3.1 结构化日志处理

推荐使用JSON格式日志，示例：

{
  "timestamp": "2023-01-01T12:00:00Z",
  "level": "ERROR",
  "trace_id": "abc123",
  "message": "Database connection failed",
  "error": "Timeout"
}

3.3.2 Kibana查询语法

# 查找特定trace_id的错误日志
trace_id: "abc123" AND level: ERROR
# 按时间范围统计错误趋势
@timestamp: ["now-1h" TO "now"] AND level: ERROR | stats count by @timestamp

四、故障排查实战案例

4.1 案例1：Pod频繁重启

1. 监控发现：kube_pod_container_status_restarts_total指标突增
2. 日志分析：kubectl logs --previous <pod-name>发现OOMKilled错误
3. 解决方案：调整requests/limits配置，增加内存限制

4.2 案例2：API延迟升高

1. 监控定位：http_request_duration_seconds_bucket指标显示99%分位延迟超标
2. 链路追踪：通过Jaeger确认数据库查询耗时占比70%
3. 优化措施：添加Redis缓存层，减少数据库访问

五、进阶优化建议

5.1 监控存储优化

• 时序数据库压缩：Prometheus启用--storage.tsdb.retention.time=30d
• 冷热数据分离：使用Thanos组件实现历史数据归档

5.2 日志成本管控

• 采样策略：对DEBUG级别日志按10:1比例采样
• 生命周期管理：设置Elasticsearch索引生命周期策略，自动删除30天前数据

5.3 安全合规要求

• 日志脱敏：使用Fluentd的filter插件对信用卡号等敏感信息脱敏
• 审计日志：启用K8s Audit Log，记录所有API调用

六、工具选型建议

场景	推荐工具组合	替代方案
中小型集群	Prometheus + Grafana + Loki	InfluxDB + Chronograf
大型企业级	Thanos + Cortex + ELK	Splunk
云原生环境	AWS Managed Prometheus + CloudWatch Logs	Datadog

通过系统化的监控与日志体系建设，开发者可实现从”被动救火”到”主动预防”的运维模式转变。建议新手从Metrics Server+Grafana基础组合起步，逐步引入Prometheus Operator和EFK栈，最终构建符合业务需求的可观测性平台。