一、为什么K8s需要可观测性？

Kubernetes作为分布式容器编排系统，其动态性（Pod频繁启停、跨节点迁移）和复杂性（多层级资源对象）导致传统监控方式失效。可观测性通过指标（Metrics）、日志（Logging）、追踪（Tracing）三大支柱，帮助开发者：

• 快速定位容器崩溃、资源争抢等故障
• 优化资源配额，降低集群成本
• 验证服务SLA，提升系统可靠性

以电商场景为例，当促销期间订单处理延迟时，可观测性体系能快速区分是数据库连接池耗尽、API网关限流还是下游服务超时导致的问题。

二、监控体系搭建：从Metrics到告警

1. 核心监控对象

K8s监控需覆盖三个层级：

• 集群层：Node资源使用率（CPU/内存/磁盘）、API Server延迟、Etcd健康度
• 工作负载层：Deployment副本可用性、Pod重启次数、容器资源请求/限制比
• 应用层：自定义业务指标（如订单处理速率、缓存命中率）

2. 主流监控方案对比

方案	优点	缺点	适用场景
Heapster	Kubernetes原生集成	已弃用，功能有限	旧版本兼容
Metrics Server	轻量级，提供核心指标API	仅支持CPU/内存，无历史数据	水平扩展、HPA调度
Prometheus	开源标准，支持多维度查询	存储成本高，单机性能有限	生产环境主力方案
商业SaaS	开箱即用，无需维护	成本高，数据隐私风险	中小团队快速起步

3. Prometheus实战

安装配置

# prometheus-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      containers:
      - name: prometheus
        image: prom/prometheus:v2.47.0
        args:
          - "--config.file=/etc/prometheus/prometheus.yml"
        ports:
        - containerPort: 9090
        volumeMounts:
        - name: config-volume
          mountPath: /etc/prometheus
      volumes:
      - name: config-volume
        configMap:
          name: prometheus-config

关键配置项

# prometheus.yml 核心片段
scrape_configs:
  - job_name: 'kubernetes-nodes'
    static_configs:
      - targets: ['<node-ip>:9100']  # Node Exporter地址
  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true

告警规则示例

groups:
- name: k8s.rules
  rules:
  - alert: HighCPUUsage
    expr: sum(rate(container_cpu_usage_seconds_total{container!=""}[5m])) by (pod) > 0.8
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "Pod {{ $labels.pod }} CPU usage high"
      description: "CPU usage is above 80% for more than 10 minutes"

三、日志管理：从采集到分析

1. 日志架构设计

K8s日志存在三种形态：

• 节点日志：/var/log目录下的系统日志
• 容器日志：通过stdout/stderr输出的应用日志
• 审计日志：API Server的操作记录

推荐架构：

应用日志 → 容器内日志驱动 → 节点日志代理 → 日志后端（EFK/Loki）

2. EFK栈部署实践

Elasticsearch配置优化

# es-statefulset.yaml 关键配置
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: elasticsearch
spec:
  template:
    spec:
      initContainers:
      - name: increase-vm-max-map
        image: busybox
        command: ["sysctl", "-w", "vm.max_map_count=262144"]
      containers:
      - name: elasticsearch
        env:
        - name: ES_JAVA_OPTS
          value: "-Xms2g -Xmx2g"
        - name: discovery.type
          value: "single-node"

Fluentd采集配置

# fluentd-configmap.yml 核心片段
<match kubernetes.**>
  @type elasticsearch
  host "elasticsearch"
  port 9200
  logstash_format true
  <buffer>
    @type file
    path /var/log/fluentd-buffers/kubernetes.system.buffer
    timekey 1d
    timekey_wait 10m
  </buffer>
</match>

3. Loki轻量级方案

对于资源有限的集群，Loki+Promtail+Grafana组合更具优势：

• 存储成本低：按标签存储，压缩率高
• 查询效率高：基于LogQL的倒排索引
• 水平扩展：支持分片存储

Promtail配置示例：

# promtail-config.yaml
clients:
  - url: http://loki:3100/loki/api/v1/push
scrape_configs:
  - job_name: kubernetes-pods
    kubernetes_sd_configs:
      - role: pod
    pipeline_stages:
      - json:
          expressions:
            stream: stream
            logtag: logtag

四、最佳实践与避坑指南

1. 监控指标选择原则

• 黄金指标：延迟、流量、错误、饱和度
• 避免指标爆炸：禁用不必要的采集（如所有容器的进程数）
• 标签设计：保持标签维度稳定（如避免频繁变更的pod名称作为标签）

2. 日志处理优化

• 日志格式标准化：推荐JSON格式，便于结构化查询
• 日志轮转策略：设置合理的max-size和max-file（如100MB/3个文件）
• 敏感信息脱敏：通过Fluentd的filter插件过滤信用卡号等数据

3. 性能基准测试

对某电商平台的测试显示：

• Prometheus采集1000个Pod指标时，CPU占用增加15%
• Elasticsearch存储30天日志需要约2TB存储空间
• Loki处理相同日志量仅需200GB，查询延迟<2s

五、进阶方向

1. 服务网格集成：通过Istio/Linkerd自动生成服务间调用指标
2. AI运维：利用异常检测算法自动识别基线偏离
3. 多云观测：使用Thanos/Cortex构建全局可观测性平台

对于初学者，建议从Metrics Server+Kibana的轻量组合起步，逐步过渡到Prometheus+Loki的生产级方案。记住：可观测性不是一次性工程，而是需要持续优化的运维能力体系。