【30天精通Prometheus：一站式监控实战指南】第25天：微服务架构下的Prometheus实战，Kubernetes与Prometheus集成：集群监控实战

最新推荐文章于 2025-07-03 19:36:10 发布

喜提yBei冰美式

最新推荐文章于 2025-07-03 19:36:10 发布

阅读量528

点赞数 18

CC 4.0 BY-SA版权

分类专栏：【30天精通Prometheus：一站式监控实战指南】文章标签： prometheus 微服务监控运维 kubernetes 云原生服务器

本文链接：https://blog.csdn.net/qq_46001933/article/details/145250841

【30天精通Prometheus：一站式监控实战指南】专栏收录该内容

25 篇文章

订阅专栏

亲爱的读者们👋

欢迎加入【30天精通Prometheus】专栏！📚 在这里，我们将探索Prometheus的强大功能，并将其应用于实际监控中。这个专栏都将为你提供宝贵的实战经验。🚀

Prometheus是云原生和DevOps的核心监控工具，我们将从基础概念开始，逐步涵盖配置、查询、告警和可视化。💪

在接下来的30天里，我们将解锁Prometheus的实战技巧，通过案例和分享，助你深入理解其工作原理。📆

目标：30天后，你将熟练掌握Prometheus，为未来的项目挑战做好准备！💯

这是一段精彩旅程，期待你的加入！🎉

文章目录

一、引言
- 1.1 微服务架构的特点及其对监控的需求
- 1.2 Prometheus与Kubernetes结合的优势
二、微服务架构简介
三、Prometheus基础回顾
- 3.1 Prometheus架构简述
- 3.2 主要组件介绍
四、Kubernetes平台概览
五、Prometheus在Kubernetes中的部署方式
相关资料下载地址📚

一、引言

1.1 微服务架构的特点及其对监控的需求

微服务架构的核心特点
微服务架构通过将单体应用拆分为多个独立、松耦合的服务，提升了系统的灵活性、可维护性和可扩展性。其核心特点包括：
1. 分布式部署：服务分散在多个节点或容器中，跨网络通信。
2. 动态扩缩容：服务实例根据负载动态增减（如Kubernetes的自动扩缩）。
3. 技术异构性：不同服务可能使用不同编程语言、框架或中间件。
4. 服务依赖复杂：服务间通过API或消息队列交互，形成调用链依赖。

对监控的挑战与需求
微服务的分布式特性对监控提出了更高要求：
1. 实时性与细粒度：需快速发现服务实例故障、资源瓶颈或延迟突增。
2. 全链路追踪：跟踪请求跨服务的完整路径（如结合Jaeger/Zipkin）。
3. 动态感知能力：自动发现新增或销毁的服务实例（如Kubernetes Pod）。
4. 多维指标聚合：从服务、实例、版本等多维度聚合指标（如HTTP错误率、CPU使用率）。
5. 统一监控视图：整合基础设施（节点、容器）、服务层（API性能）、业务层（订单成功率）的监控数据。

1.2 Prometheus与Kubernetes结合的优势

Prometheus的核心能力

多维度数据模型：基于标签（Label）的时序数据，支持灵活查询（如rate(http_requests_total{status=“500”}[5m])）。
主动拉取（Pull）机制：适合动态环境，通过服务发现自动抓取目标。
强大的告警规则：支持复杂条件告警（如持续5分钟错误率>1%）。
丰富的Exporter生态：支持MySQL、Redis、Nginx等组件监控。

Kubernetes与Prometheus的协同优势

原生服务发现集成
- Prometheus通过Kubernetes API自动发现Pod、Service、Endpoint等资源，无需手动配置监控目标。
- 示例：使用kubernetes_sd_config配置自动监控所有带有prometheus.io/scrape=true注解的Pod。
容器化监控深度支持
- 结合cAdvisor监控容器资源（CPU、内存、IO），kube-state-metrics采集Kubernetes对象状态（如Deployment副本数）。
- 示例：通过container_memory_usage_bytes跟踪容器内存使用。
动态环境的无缝适配
- 当服务因HPA（水平扩缩容）或滚动更新导致实例变化时，Prometheus自动更新抓取目标，确保监控连续性。
声明式配置管理
- 通过Prometheus Operator以CRD（自定义资源）定义监控规则、告警策略，与Kubernetes的声明式理念一致。
- 示例：使用ServiceMonitor对象定义需要监控的服务端点。
云原生生态融合
- 作为CNCF毕业项目，Prometheus与Kubernetes、Grafana、Thanos等工具深度集成，形成完整的可观测性栈。

二、微服务架构简介

2.1 微服务架构的核心概念

定义与核心思想
微服务架构是一种将单一应用拆分为一组小型、独立服务的架构模式，每个服务围绕业务能力构建，通过轻量级通信机制协作。其核心思想包括：

服务拆分：按业务领域（如订单、支付、用户管理）垂直划分服务，确保单一职责。
独立部署：每个服务可独立编译、打包、发布，支持持续交付（CI/CD）。
去中心化治理：允许服务采用不同技术栈（如Java、Go、Python）、数据库（MySQL、MongoDB）及中间件。
自治性：服务拥有独立的代码库、数据存储和运维流程，降低团队间耦合。

关键设计原则

高内聚低耦合：服务内部功能紧密相关，对外暴露明确API接口。
容错与弹性：通过熔断（如Hystrix）、重试、降级机制应对依赖服务故障。
自动化运维：依赖容器化（Docker）、编排工具（Kubernetes）实现自动化部署与扩缩容。
可观测性：集成日志聚合（ELK）、指标监控（Prometheus）、分布式追踪（Jaeger）确保系统透明。

2.2 微服务之间的通信模式

同步通信

HTTP/REST
- 特点：基于文本的轻量级协议，易调试且跨语言支持广泛。
- 适用场景：面向外部API或对兼容性要求高的场景。
gRPC
- 特点：基于HTTP/2的高性能RPC框架，支持流式通信和Protocol Buffers序列化。
- 适用场景：内部服务间高频调用（如支付服务与风控服务）。

异步通信

消息队列（Message Queue）
- 特点：通过发布-订阅模型解耦服务，支持削峰填谷、最终一致性。
- 常用工具：Kafka（高吞吐）、RabbitMQ（灵活路由）、RocketMQ（事务消息）。
- 示例：订单创建后发布事件至Kafka，库存服务消费事件并扣减库存。
事件驱动架构（EDA）
- 特点：服务通过事件广播状态变更（如OrderCreated、PaymentCompleted），触发下游业务逻辑。
- 技术栈：Apache Pulsar、AWS EventBridge。
通信保障机制
- 服务发现：通过Consul、Eureka或Kubernetes Service动态解析服务实例地址。
- 负载均衡：客户端（Ribbon）或服务端（Nginx）均衡流量。
- 熔断与降级：使用Resilience4j或Sentinel防止级联故障。

2.3 常见的微服务框架和技术栈

开发框架

Spring Cloud
- 核心组件：
  - 服务注册与发现：Netflix Eureka、Consul。
  - API网关：Spring Cloud Gateway、Zuul。
  - 配置中心：Spring Cloud Config。
  - 分布式追踪：Sleuth + Zipkin。
- 适用场景：Java生态下的全栈微服务解决方案。
Dubbo
- 特点：高性能RPC框架，支持多协议（Dubbo、gRPC）、服务治理（限流、权重路由）。
- 生态扩展：与Nacos（注册中心）、Sentinel（流量控制）深度集成。

基础设施与编排工具

Kubernetes
- 核心功能：
  - 服务编排：Deployment管理Pod生命周期。
  - 服务暴露：Service和Ingress提供内外网访问。
  - 自动扩缩容：HPA基于CPU/内存或自定义指标扩缩实例。
服务网格（Service Mesh）
- 代表工具：Istio、Linkerd。
  - 核心能力：
  - 流量管理：A/B测试、金丝雀发布。
  - 安全通信：mTLS加密、服务间身份认证。
  - 可观测性：自动生成服务依赖拓扑图。

三、Prometheus基础回顾

3.1 Prometheus架构简述

核心架构设计
Prometheus 是一个开源的监控与告警系统，其架构围绕拉取（Pull）模型和多维时间序列数据构建，专为动态云原生环境（如 Kubernetes）设计。核心架构组件包括：

Prometheus Server
- 抓取（Scrape）：主动从配置的目标（如Exporter、应用端点）拉取指标数据。
- 存储（Storage）：将数据存储在本地时序数据库（TSDB）中，支持高效查询与压缩。
- 存告警评估（Alert Evaluation）：根据预定义规则触发告警并推送至Alertmanager。
服务发现（Service Discovery）
- 动态识别监控目标（如Kubernetes Pod、Consul服务），无需手动维护目标列表。
客户端库与Exporter
- 客户端库（Client Libraries）：集成到应用中暴露自定义指标（如Go、Java、Python SDK）。
- Exporter：将第三方系统（如MySQL、Node）的指标转换为Prometheus格式。

工作流程示例
1. Prometheus Server 通过 Kubernetes API 发现所有带有注解 prometheus.io/scrape=true 的 Pod。
2. 定期（如每15秒）从这些 Pod 的 /metrics 端点拉取指标数据。
3. 存储数据到 TSDB，并通过 PromQL 查询分析指标（如计算错误率）。
4. 触发告警规则后，将告警信息发送至 Alertmanager 进行路由与通知。

3.2 主要组件介绍

组件	功能	典型应用场景
Prometheus Server	数据抓取、存储、告警评估的核心组件。	监控Kubernetes集群中的容器资源与微服务性能
Exporters	将非Proemtheus原生系统的指标转换为兼容格式。	Node Exporter：监控主机资源（CPU、内存）。 cAdvisor：监控容器指标。
Pushgateway	缓存短暂任务（如CronJob）的指标，供Prometheus拉取。	监控批处理任务的执行状态（如每日报表生成）。
Alertmanager	接收Prometheus的告警，进行去重、分组、静默，并通过邮件/Slack等渠道通知。	聚合微服务的高延迟或错误率告警，避免通知风暴。
Grafa	可视化工具，通过PromQL查询并展示监控仪表盘。	构建统一的微服务健康状态视图（如API成功率、资源水位）。

组件协作示例
1. 微服务应用通过 Prometheus Client 暴露 /metrics 端点。
2. Prometheus Server 通过 Kubernetes 服务发现自动抓取这些端点。
3. Alertmanager 接收 HighErrorRate 告警，并配置邮件通知。
4. Grafana 通过查询 sum(rate(http_requests_total{status=“500”}[5m])) 展示错误请求趋势。

四、Kubernetes平台概览

4.1 Kubernets核心概览

定义与核心思想
Kubernetes（K8s）是开源的容器编排平台，用于自动化部署、扩缩和管理容器化应用。其核心设计围绕以下目标：
1. 自动化运维：自动调度容器、修复故障（如重启崩溃的Pod）、滚动更新。
2. 声明式配置：通过YAML/JSON定义应用期望状态（如副本数、资源限制）。
3. 可扩展性：支持自定义资源（CRD）、控制器（Operator）和插件（CNI、CSI）。

核心架构组件

组件	功能
控制平面（Control Plane）	集群的“大脑”，负责全局决策与状态管理。
API Server	提供REST API入口，接收并验证所有操作请求（如kubectl命令）。
etcd	分布式键值存储，持久化集群状态（如节点、Pod、Service配置）。
Scheduler	决定Pod在哪个节点运行（基于资源需求、亲和性规则等）。
Controller Manager	运行核心控制器（如Deployment、Node控制器），确保实际状态与期望状态一致。
工作节点（Worker Node）	执行容器化应用的实际计算节点。
kubelet	与API Server通信，管理节点上的Pod生命周期（创建、监控、销毁）。
kube-proxy	维护节点网络规则（如Service的IPVS/iptables流量转发）。
容器运行时	负责运行容器（如Docker、containerd）。

典型工作流程示例

用户通过kubectl apply -f deployment.yaml提交一个Deployment配置。
API Server将配置写入etcd，并触发Deployment控制器。
Deployment控制器创建ReplicaSet，ReplicaSet控制器生成指定数量的Pod。
Scheduler为每个Pod分配节点，kubelet拉取镜像并启动容器。

4.2 Kubernetes网络模型

Kubernetes网络模型遵循以下核心原则：

Pod间直接通信：每个Pod拥有唯一IP（IP-per-Pod），无需NAT即可跨节点通信。
Service抽象：通过ClusterIP、NodePort或LoadBalancer暴露服务，解耦Pod IP的动态变化。
网络插件化：由CNI（Container Network Interface）插件实现具体网络方案（如Calico、Flannel）。

组件	功能
Pod Network	Pod内容器共享网络命名空间，通过localhost直接通信。
Service	虚拟IP（VIP）和DNS名称，提供负载均衡与服务发现（如my-service.namespace.svc.cluster.local）。
Ingress	HTTP/HTTPS路由规则，暴露外部访问路径（如按域名分流到不同服务）。
Network Policy	定义Pod间通信规则（如允许前端Pod访问后端数据库），需CNI插件支持（如Calico）。

通信模式示例
1. Pod-to-Pod通信：Pod A（IP 10.1.1.2）直接发送请求至Pod B（IP 10.1.2.3），由CNI插件处理跨节点路由。
2. Service流量转发：用户访问ClusterIP:80，kube-proxy通过iptables/IPVS将流量转发至后端Pod（如10.1.1.2:8080）。
3. Ingress外部访问：用户通过域名app.example.com访问，Ingress控制器（如Nginx）将请求路由至对应的Service。

4.3 Kubernetes存储机制

核心概念
Kubernetes通过抽象层管理存储，解耦应用与底层存储基础设施：

Persistent Volume（PV）：集群级别的存储资源（如NFS卷、云磁盘）。
Persistent Volume Claim（PVC）：用户对存储的请求（如“需要10GiB的SSD卷”）。
Storage Class（SC）：动态创建PV的模板（如按需创建AWS EBS卷）。

存储生命周期

静态配置：管理员手动创建PV，PVC绑定到现有PV。
动态配置：用户提交PVC时，Storage Class自动创建匹配的PV。

常用存储类型

类型	特点	适用场景
EmptyDir	临时卷，随Pod删除而销毁。	缓存或临时数据处理（如排序中间结果）。
HostPath	挂载节点本地目录（慎用，可能引发节点依赖）。	单节点调试或访问宿主机设备（如GPU）。
NFS/GlusterFS	网络文件系统，支持多节点读写。	共享配置文件或日志存储。
云存储（如EBS）	云厂商提供的块存储，支持动态扩缩。	数据库持久化数据（如MySQL数据卷）。

五、Prometheus在Kubernetes中的部署方式

5.1 使用Helm Chart简化部署

Helm的作用与优势
Helm是Kubernetes的包管理工具，通过预定义的Chart（模板）简化Prometheus及其生态组件（Alertmanager、Grafana等）的部署流程，优势包括：

一键部署：自动配置核心组件与依赖项（如RBAC、ServiceMonitor）。
参数化配置：通过values.yaml文件覆盖默认参数（如存储类型、资源限制）。
版本管理：支持回滚到历史版本，确保部署可追溯。

适用场景

快速搭建监控环境，适合中小规模集群或测试环境。
需结合values.yaml自定义告警规则、Exporter配置。

注意事项

helm版本要在3.7以上。

部署步骤示例
1. 添加Prometheus社区仓库：

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts  
helm repo update

2. 安装Prometheus Stack（含Grafana、Alertmanager）：

kubectl create ns prometheus 

helm install prometheus prometheus-community/kube-prometheus-stack -n prometheus

在这里插入图片描述

3.验证部署

kubectl --namespace prometheus get pods -l "release=prometheus"

在这里插入图片描述

4.访问 Prometheus UI
默认情况下，Prometheus UI 不会暴露在外网中。你可以通过端口转发来访问它：

kubectl -n prometheus edit svc prometheus-kube-prometheus-prometheus

在这里插入图片描述

kubectl -n prometheus get svc prometheus-kube-prometheus-prometheus

在这里插入图片描述

5.2 通过Prometheus Operator自动化管理

Operator的核心能力
Prometheus Operator基于Kubernetes的Operator模式，通过自定义资源（CRD）自动化管理Prometheus实例，核心功能包括：

声明式配置：使用Prometheus、Alertmanager等CRD定义监控规则、存储策略。
动态适配：自动生成Prometheus配置（如prometheus.yml），响应集群变化（如Pod扩缩容）。
生命周期管理：自动处理Prometheus版本升级、配置重载。

使用ServiceMonitor和PodMonitor发现服务

资源类型	作用	示例场景
ServiceMonitor	通过关联Service，监控其背后所有Pod的指标（需Service指向Pod的端口）。	监控Deployment暴露的HTTP服务（如Nginx）。
PodMonitor	直接监控Pod的指标，无需依赖Service（适用于无Service的StatefulSet或DaemonSet）。	监控日志采集器（如Fluentd DaemonSet）。

Servicemonitor 定义实例

mkdir k8s/prometheus -p

vi k8s/prometheus/ServiceMonitor-kube-controller-manager.yaml

apiVersion: monitoring.coreos.com/v1  
kind: ServiceMonitor  
metadata:  
  name: kube-controller-manager
  namespace: prometheus 
spec:  
  selector:  
    matchLabels:  
      app: kube-prometheus-stack-kube-controller-manager  # 匹配目标Service的标签  
  endpoints:  
    - port: metrics    # Service中定义的端口名称  
      interval: 30s  
      path: /metrics  
  namespaceSelector:  
    any: true          # 允许跨Namespace监控

PodMonitor 定义实例

kubectl label -n prometheus svc prometheus-prometheus-node-exporter app=node-exporter

vi k8s/prometheus/ServiceMonitor-node-exporter.yaml

apiVersion: monitoring.coreos.com/v1  
kind: PodMonitor  
metadata:  
  name: node-exporter  
  namespace: prometheus
spec:  
  selector:  
    matchLabels:  
      app: node-exporter  
  podMetricsEndpoints:  
    - port: metrics    # Pod中定义的端口名称  
      path: /metrics

5.3 自定义资源定义(CRD)的作用

CRD的核心价值

扩展Kubernetes API：允许定义新的资源类型（如PrometheusRule、AlertmanagerConfig），将监控配置融入Kubernetes原生体系。
声明式管理：通过YAML文件版本化告警规则、数据抓取策略，实现GitOps流程。
自动化协调：Operator监听CRD变化，自动更新Prometheus配置并重载服务。

常用CRD类型
1. PrometheusRule：定义告警规则与记录规则。

vi k8s/prometheus/PrometheusRule-high-error-rate.yaml

apiVersion: monitoring.coreos.com/v1  
kind: PrometheusRule  
metadata:  
  name: high-error-rate  
  namespace: prometheus
spec:  
  groups:  
    - name: error-rules  
      rules:  
        - alert: HighHTTPErrorRate  
          expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01  
          for: 10m