Kubernetes监控实战：快速搭建Prometheus+Grafana方案

markdown复制## 1. 项目概述：K8s监控体系快速搭建方案

去年在给某电商平台做容器化改造时，他们的运维负责人问我："能不能用最简单的方式把Prometheus监控体系跑起来？"这正是今天要分享的实战方案——基于Kubernetes原生YAML的"复制粘贴"式部署方案。这套方案经过3个生产环境验证，包含Prometheus主服务、Alertmanager告警组件、Grafana可视化以及Node-Exporter主机监控四大核心模块。

为什么推荐这种部署方式？相比Helm chart或Operator部署，直接使用原生YAML有三个显著优势：一是部署过程透明可控，所有配置参数可见；二是避免版本兼容性问题；三是方便后续自定义扩展。特别适合中小规模集群（50节点以内）的监控需求，从执行到出监控数据不超过15分钟。

## 2. 核心组件架构解析

### 2.1 监控体系拓扑设计

典型的K8s监控栈采用分层采集架构：

Prometheus Server ←→ Alertmanager
↑
Node-Exporter（节点指标）
↑
Kube-State-Metrics（资源对象状态）
↑
cAdvisor（容器指标）

code复制
这套架构中每个组件都有明确分工：
- Prometheus Server：指标抓取、存储与查询核心
- Alertmanager：告警去重、分组与路由
- Grafana：可视化仪表盘
- Node-Exporter：主机级指标（CPU/内存/磁盘等）
- Kube-State-Metrics：将K8s资源对象转为监控指标

### 2.2 关键配置参数说明

在正式部署前需要确认以下参数：
1. **存储规划**：生产环境建议配置PVC持久化存储，测试环境可使用emptyDir
   - 示例PVC配置（需提前创建StorageClass）：
   ```yaml
   resources:
     requests:
       storage: 50Gi
   accessModes: [ "ReadWriteOnce" ]

2. 资源限制：根据集群规模调整内存限制

   • 中小规模集群推荐配置：

   yaml复制resources:
     limits:
       cpu: 2
       memory: 4Gi
     requests:
       cpu: 1
       memory: 2Gi
   

3. 抓取间隔：scrape_interval建议设置为15s-30s

   yaml复制scrape_configs:
     - job_name: 'kubernetes-nodes'
       scrape_interval: 15s
   

3. 分步部署实操指南

3.1 创建监控专用Namespace

首先建立独立的监控命名空间：

bash复制kubectl create ns monitoring

3.2 部署Prometheus Server

使用以下YAML创建prometheus-deployment.yaml：

yaml复制apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus-server
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      containers:
      - name: prometheus
        image: prom/prometheus:v2.47.0
        ports:
        - containerPort: 9090
        volumeMounts:
        - mountPath: /etc/prometheus
          name: config-volume
        - mountPath: /prometheus
          name: storage-volume
      volumes:
      - name: config-volume
        configMap:
          name: prometheus-config
      - name: storage-volume
        persistentVolumeClaim:
          claimName: prometheus-pvc

配套的ConfigMap配置（prometheus-config.yaml）：

yaml复制apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: monitoring
data:
  prometheus.yml: |
    global:
      scrape_interval: 15s
    scrape_configs:
      - job_name: 'kubernetes-nodes'
        kubernetes_sd_configs:
        - role: node

关键提示：ConfigMap更新后需要重启Pod才能生效，建议使用以下命令滚动更新：

bash复制kubectl rollout restart deployment/prometheus-server -n monitoring

3.3 部署Node-Exporter

DaemonSet确保每个节点都有采集器：

yaml复制apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      containers:
      - name: node-exporter
        image: prom/node-exporter:v1.6.1
        ports:
        - containerPort: 9100

3.4 部署Grafana可视化

包含预置的K8s监控仪表盘：

yaml复制apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      labels:
        app: grafana
    spec:
      containers:
      - name: grafana
        image: grafana/grafana:10.2.0
        ports:
        - containerPort: 3000
        volumeMounts:
        - mountPath: /var/lib/grafana
          name: grafana-storage
      volumes:
      - name: grafana-storage
        persistentVolumeClaim:
          claimName: grafana-pvc

4. 服务暴露与访问配置

4.1 创建Ingress路由（以Nginx Ingress为例）

yaml复制apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: monitor-ingress
  namespace: monitoring
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: monitor.example.com
    http:
      paths:
      - path: /prometheus
        pathType: Prefix
        backend:
          service:
            name: prometheus-service
            port:
              number: 9090
      - path: /grafana
        pathType: Prefix
        backend:
          service:
            name: grafana-service
            port:
              number: 3000

4.2 配置Grafana数据源

1. 访问Grafana控制台（默认账号admin/admin）
2. 进入Configuration → Data Sources
3. 添加Prometheus类型数据源：
   • URL: http://prometheus-service.monitoring.svc:9090
   • 其他参数保持默认

实测技巧：建议导入官方仪表盘ID为3119的Kubernetes集群监控模板，包含完整的资源监控视图。

5. 常见问题排查手册

5.1 指标采集失败排查流程

1. 检查Target状态：

   bash复制kubectl port-forward svc/prometheus-service 9090 -n monitoring
   

   访问localhost:9090/targets查看采集目标状态

2. 典型错误处理：

   • Connection refused：检查Service的selector是否匹配Pod标签
   • 403 Forbidden：检查RBAC权限配置
   • no such host：检查DNS解析是否正常

5.2 资源占用优化方案

当监控数据量增大时，可能出现内存不足问题：

• 调整Prometheus启动参数：

  yaml复制args:
    - '--storage.tsdb.retention.time=7d'  # 缩短数据保留周期
    - '--storage.tsdb.wal-compression'    # 启用WAL压缩
  

• 启用分片部署：

  yaml复制args:
    - '--storage.tsdb.max-block-duration=2h'
    - '--storage.tsdb.min-block-duration=2h'
  

5.3 权限问题处理

遇到permission denied错误时：

1. 检查ServiceAccount绑定：

   yaml复制apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: prometheus-role-binding
   subjects:
   - kind: ServiceAccount
     name: prometheus-service-account
     namespace: monitoring
   roleRef:
     kind: ClusterRole
     name: prometheus-cluster-role
     apiGroup: rbac.authorization.k8s.io
   

2. 验证权限：

   bash复制kubectl auth can-i list nodes --as=system:serviceaccount:monitoring:prometheus-service-account
   

6. 生产环境增强建议

6.1 高可用部署方案

对于关键业务集群，建议采用以下高可用架构：

• Prometheus：部署2个副本+Thanos组件
• Alertmanager：部署3节点集群模式
• Grafana：配置数据库后端（非sqlite）

6.2 监控数据长期存储

当需要历史数据分析时：

1. 配置远程写入到VictoriaMetrics或Mimir

   yaml复制remote_write:
   - url: http://victoriametrics:8428/api/v1/write
   

2. 使用Thanos实现全局视图

6.3 自定义指标采集

扩展监控维度的方法：

1. 通过ServiceMonitor自定义采集：

   yaml复制apiVersion: monitoring.coreos.com/v1
   kind: ServiceMonitor
   metadata:
     name: custom-app-monitor
   spec:
     endpoints:
     - port: web
     selector:
       matchLabels:
         app: my-app
   

2. 使用Prometheus Client SDK暴露业务指标

这套方案在多个生产环境稳定运行超过2年，最大的优势在于部署过程完全透明。所有配置都可以根据实际需求灵活调整，不像Helm chart那样存在黑盒操作。对于刚开始接触K8s监控的团队，建议先按本文方案部署基础监控，等熟悉各组件后再逐步引入Operator等高级管理方式。