Kubernetes 排障实战：用 Prometheus 提升集群可用性和排障效率

腾讯云可观测平台

发布于 2025-02-11 14:20:46

12000

代码可运行

运行总次数：0

代码可运行

导语：本文主要探讨 Prometheus 在观测 Kubernetes 方面的独特优势和最佳实践，包括如何在 Kubernetes 不同层次和维度上实现全面的可观测性，如何排查最常见的 Kubernetes 故障，以及维护集群稳定高效运行的最佳实践。

雷畅

腾讯高级工程师/腾讯云可观测方案架构师。具有多年可观测领域研发经验，对业务端到端监控有深刻理解。

强大的工具，往往伴随着巨大的复杂性。与 Kubernetes 的分布式、动态性等硬核实力相伴而来的，是如何对其进行监控的挑战：

集群是否潜藏着性能瓶颈？
各项资源分配是否合理？
如何捕获影响稳定性的事件？

这些问题，不仅关乎系统的稳定性、高效性，还将直接影响业务质量和用户体验。

而 Prometheus 作为紧随 Kubernetes 之后的、CNCF 的“第二把交椅”，则凭借其与 Kubernetes 相伴而生、天然适配的独特优势，已然成为监控 Kubernetes 的首选。

接下来，围绕 Kubernetes 监控，本文将试着回答下列问题：

为何 Prometheus 是监控 Kubernetes 的“官配”？
“若覆盖不全面，则监控无意义”——此话怎讲？
Kubernetes 常见故障和最佳实践，展开说说？
既然有开源 Prometheus，又何需腾讯云 Prometheus？

Prometheus 的优势

对比其他监控方案，Prometheus 针对 Kubernetes 监控，具有不可替代的优势：

1.Prometheus 和 Kubernetes 彼此原生支持。

Prometheus 对 Kubernetes 的原生支持：Prometheus 可对 Kubernetes 中的目标进行动态发现，大幅简化了监控配置。
Kubernetes 对 Prometheus 的原生支持：Kubernetes 各组件内置 Prometheus 指标暴露，无需引入额外的导出工具。

2.Prometheus 针对云原生环境的独特设计。

针对架构复杂性：传统架构中只有主机和应用两个层面要监控；而 Kubernetes 不仅在两者之间引入了新的抽象层，并且这层 Kubernetes 自身组件也需要被监控。Prometheus 社区的活跃生态（多种 exporter、后端存储、语言 SDK），则能很好地承托 Kubernetes 的全面监控。
针对资源动态性：相比传统监控中的静态主机，Kubernetes 上的 pod 可能频繁被创建和销毁，传统的 Zabbix 等基础设施监控手段显然力不从心。而 Prometheus 可基于服务发现做指标拉取，自动更新监控目标，确保监控数据的实时性和准确性；此外，对于动态环境下的短生命周期任务，Prometheus 除了支持指标拉取，还支持各监控目标向 Prometheus 做指标推送。
针对指标高基数：云原生环境下大都是微服务架构，服务不仅数量多、维度也多，导致承载元数据的标签呈爆炸趋势。而 Prometheus 具备灵活标签的数据模型设计，则提供了很好的分类结构和检索方法，这样，对指标数据的组织将更加灵活、多维、适应变化、方便聚合：

针对查询精细化：强大的查询语言 PromQL，使用户能通过简洁的表达式，高效地检索和处理时间序列数据。PromQL 支持多种数学运算、聚合操作、趋势预测；还可用于绘制精细的可视化图表、管理精细的告警逻辑。

K8s 全栈监控

若覆盖不全面，则监控无意义。

乍一看，Kubernetes 指标似乎没啥特别，仍然跟其他系统类似，包括吞吐率、错误率、延迟和资源饱和度等。

然而，Kubernetes 监控的棘手之处在于：Kubernetes 不是“一个东西”，而是一个由控制平面、节点、Pod、键值存储等多个组件组成的系统。

所以针对 Kubernetes，若缺乏全栈视角和数据关联，又怎能实现故障的快速定位和根因分析呢？

例如：当一个容器 CrashLoopBackoff，它的可能原因有很多、影响范围也不同（如下图所示）。其中，若是底层的宿主机导致，则其影响范围可能不仅限于该特定容器，同宿主机上的其他 Pod 和容器也会受到影响，可能出现性能下降等问题。

为了全面打造 Kubernetes 的指标监控体系，自下而上，我们可以将 Kubernetes 从底层资源到顶层应用，分为 5 个不同的层面，用不同的方法和组件分别采集。接下来，我们将逐层击破，探讨每层监控对象的侧重点、所使用的监控手段、需关注的核心指标，以及如何通过构建可观测性，来保障系统的稳定运行。

宿主机层

宿主机是指用于运行 Kubernetes 节点的底层机器（物理机或 VM）。对其进行监控的核心，在于系统级别的性能指标，包括 CPU 使用率、内存使用情况、磁盘 I/O、网络流量和文件系统使用情况。

对于宿主机指标的导出和暴露，我们可借助 Prometheus 社区提供的开源 exporter 工具来实现，例如：

node-exporter（监控 *NIX 系统）
windows_exporter（监控 Windows 系统）
dcgm-exporter（监控 GPU）
process-exporter（监控进程）

以 node-exporter 为例，它是以二进制的形式被提供的，下载、安装、运行后，即可在其下述端点观察到暴露的指标：curl http://<宿主机IP>:9100/metrics。在 Prometheus 将其配置为采集目标后，宿主机指标即可以一定时间间隔，被 Prometheus 定期采集。

在机器资源层面，毫无疑问，我们最关心的指标肯定是：CPU 和内存的利用率、网络出入带宽，等等。

使用 Grafana 可视化 node-exporter 指标，便可以直观展示指标数据、实时监控系统状态。以 Prometheus 为 node-exporter 预设的 Grafana 大盘为例：

而通过 Prometheus 的 AlertManager 组件，基于核心指标配置告警，则可以及时通知运维人员系统异常，确保快速响应和问题解决。

以腾讯云 Prometheus 为 node-exporter 预设的一条 alert 为例：我们可以用 PromQL语句(1-node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) > 0.85，表达当内存使用率超过 85% 时，发送告警消息。

K8s 组件层

Kubernetes 自身系统组件暴露的指标，可以让我们更好地了解组件内部的情况。关于 Kubernetes 有哪些系统组件有待监控，我们可以先观察 Kubernetes 架构图：

（在上图中，用户交互的部分 UI 和 CLI 不需要监控；容器引擎 Docker 一般不会出问题；pod 和 container 的监控我们会在后续层次介绍。）

系统组件层面监控的关键，在于 Control Plane（控制面）和 Worker Node（工作负载节点）。

控制面（Control Plane）是集群的大脑，负责管理和调度，若出现问题，将无法向 Kubernetes 下发指令。为了确保其正常运行，需要关注以下关键组件：

kube-apiserver: 负责 Kubernetes 中组件之间的通信。监控其延迟、请求量和错误率可以发现潜在的性能问题。
etcd: 保存所有集群数据的键值存储。监控其磁盘 I/O 和延迟，有助于维护一致性并防止数据瓶颈。
kube-scheduler: 用于将 pod 分配到 node。它跟踪调度延迟和 pod 绑定失败，以确保成功分配工作负载。
kube-controller-manager: 负责管理集群中的控制循环，确保集群的实际状态与用户期望的状态保持一致。

工作负载节点则运行容器及其管理工具，如 Docker、kubelet 和 kube-proxy，若这些节点出现故障，可能直接影响业务流量。

大多数 Kubernetes 组件的指标，都已通过 HTTP /metrics 端点默认暴露。相关组件及其关键指标的示例如下：

kubelet: kubelet_running_pod_count 用于监控正在运行的 pod，kubelet_container_cpu_usage_seconds_total 用于监控容器 CPU 使用率，等等。
kube-proxy: kubeproxy_sync_proxy_rules_duration_seconds 用于监控同步代理规则的延迟时间， kubeproxy_connections 用于监控当前活跃的连接数，等等。
kube-apiserver: apiserver_request_duration_seconds 用于监控请求延迟、apiserver_request_total 用于监控 API 请求的总数，等等。
kube-scheduler: scheduler_binding_duration_seconds 用于监控绑定延迟，scheduler_e2e_scheduling_duration_seconds 用于监控端到端调度延迟，等等。
kube-controller-manager: workqueue_adds_total 用于计算项目添加到工作队列的次数，workqueue_queue_duration_seconds用于计算队列持续时间，等等。
etcd: etcd_server_has_leader用于监控领导者是否存在，etcd_disk_wal_fsync_duration_seconds 用于监控预写日志同步持续时间。

同样地，拿到上述指标后，我们可为其配置大盘和告警。

以 Prometheus 为 kube-apiserver 预设的 Grafana 大盘为例：

以腾讯云 Prometheus 为 kubelet 预设的监控客户端证书过期的 alert 为例：

K8s 资源层

对于 Kubernetes 资源层，我们可以安装和使用 kube-state-metrics 这一组件，来监控 Kubernetes 的各类对象的状态（如 Service、Deployment、StatefulSet、Node 等）。

kube-state-metrics 是一个简单的服务，它通过监听 kube-apiserver ，订阅各类资源对象的变更，由此获取它们的状态（例如：某个 Deployment 期望的副本数、实际运行的 Pod 数量，等等），并对外暴露为指标。

由于 kube-state-metrics 并未被 Kubernetes 默认集成，因此在使用它之前我们需要先自行部署在 Kubernetes 集群中，以对集群中的资源状态进行监控。

kube-state-metrics 提供的常用指标示例如下：

kube_node_status_condition：node 节点的状态，可用来监控节点不正常或存在磁盘压力等问题。
kube_pod_container_status_last_terminated_reason：容器停止的原因。
kube_pod_container_status_waiting_reason：容器处于等待状态的原因，如 CrashLoopBackoff 等。
kube_pod_container_status_restarts_total：容器的重启次数。
kube_deployment_spec_replicas：deployment 配置中期望的副本数。
kube_deployment_status_replicas_available：deployment 实际可用的副本数。

有了上述指标，我们可以为所关心的 Kubernetes 资源（如 Pod、Deployment、Statefulset 等）配置相应的 Grafana 大盘。

以腾讯云 Prometheus 为 Pod 预设的 Grafana 大盘为例：

也可为各类 Kubernetes 资源配置告警规则，以腾讯云 Prometheus 预设的监控 pod 状态的 alert 为例，其表达式如下，代表某 pod 若处于 NotReady 状态超过15分钟，则发出告警通知：

sum by (cluster,namespace, pod) (
  max by(cluster,namespace, pod) (
    kube_pod_status_phase{job="kube-state-metrics", phase=~"Pending|Unknown"}
  ) * on(cluster,namespace, pod) group_left(owner_kind) topk by(cluster,namespace, pod) (
    1, max by(cluster,namespace, pod, owner_kind) (kube_pod_owner{owner_kind!="Job"})
  )
) > 0

K8s 容器层

在 Kubernetes 容器层，我们可以利用 cAdvisor 这一监控工具，实时监测节点上容器的资源使用情况，包括 CPU、内存、磁盘和网络等。

cAdvisor（Container Advisor）是 Google 开源的工具，专注于监测容器的资源使用和性能表现。由于其强大的监控功能，Kubernetes 已默认将 cAdvisor 与 Kubelet 集成，因此无需单独部署 cAdvisor 组件，我们就可通过 kubelet 为其暴露的指标采集地址（/metrics/cadvisor），来获取容器运行信息。

cAdvisor 的常用指标多与 CP内存、IO 等资源相关，例如：container_cpu_load_average_10s（过去十秒内容器 CPU 负载平均的值）、container_memory_usage_bytes（容器内存使用情况）……等等。

有了这些指标，我们即可为容器维度的 CPU、内存等资源状况构建 Grafana 大盘。

以腾讯云 Prometheus 预设的容器维度的大盘为例：

以腾讯云 Prometheus 预设的告警模板为例，可使用下述 PromQL 表达式，规定当容器的 CPU 使用率超过 80% 时，触发告警：

sum(rate(container_cpu_usage_seconds_total{job=~"cadvisor|eks-network", image!="", container!="POD"}[1m])) by (cluster, namespace, pod, container) / sum(kube_pod_container_resource_limits_cpu_cores>0) by (cluster, namespace, pod, container) > 0.8

业务应用层

对于业务监控（例如订单数、在线用户数等）和应用监控（例如延迟、吞吐量、错误率），由于都需要从应用程序侧来实现，所以本文将这两个层面的监控统称为”业务应用层“。这类指标不仅可以帮助了解系统的健康状况，还可以为业务决策提供数据支持。

在监控业务和应用层指标时，可通过三种方式来实现指标暴露：

通过 Prometheus SDK 埋点：
- 使用 Prometheus 提供的 SDK 进行指标埋点，既可以在应用程序的业务逻辑中进行埋点，也可以通过框架层进行自动化埋点。
- 优点：性能更好、灵活性高，能够实时反映应用的状态和性能。
- 缺点：对应用程序有侵入性，需要修改代码。
通过 Exporter 暴露指标：
- 借助 Prometheus 生态的 exporter，将应用程序的指标导出。例如，使用 jmx_exporter 为 Java 程序暴露 JVM 指标和 Java 应用指标。
- 优点：对应用程序的侵入性较低。
- 缺点：需要额外的 exporter，可能引入运维开销和性能开销。
从日志中提取指标：
- 通过分析应用程序生成的日志文件，从中提取出有价值的指标，通常依赖于日志分析工具来处理和提取指标。
- 优点：对应用程序无侵入性，不需要修改代码。
- 缺点：链路较长，性能较差；依赖日志，对日志数据的规范性要求高。

得到上述指标后，便可灵活定义自己的业务和应用监控大盘：

我们也可以使用 PromQL，灵活定义告警规则，例如我们可以定义一个关于订单支付延时的告警：

K8s 排障实践

接下来，我们将一起探讨常见的 Kubernetes 故障及其根因，并从具体案例出发，分析如何借助 Prometheus，对 K8s 进行全面排障。

K8s 常见故障

常见的 Kubernetes 故障，从来源划分，可分为三个大类：Workload 故障、Network 故障和 K8s core 故障。

Workload 故障 是指运行在 Kubernetes 集群中的应用程序或服务出现的问题。这些故障可能影响应用的可用性、性能或功能。

常见原因:

Pod 崩溃: 应用程序崩溃或异常退出，导致 Pod 不可用。
资源不足: CPU、内存等资源不足，导致应用无法正常运行。
配置错误: 配置文件或环境变量错误，导致应用无法启动或运行不正常。
依赖服务故障: 应用依赖的外部服务（如数据库、API）出现故障，影响应用的正常运行。

Network 故障 是指 Kubernetes 集群中网络层面的问题，影响 Pod 之间、Pod 与外部服务之间的通信。

常见原因:

网络插件故障: 使用的网络插件（如 Calico、Flannel）出现问题，导致网络不通。
DNS 解析失败: Kubernetes 的 DNS 服务出现故障，导致 Pod 无法解析其他服务的名称。
网络策略限制: 网络策略配置错误，导致 Pod 之间的通信被阻止。
负载均衡器故障: 外部负载均衡器或 Ingress 控制器出现问题，影响外部流量的路由。

K8s Core 故障 是指 Kubernetes 集群的核心组件（如 API 服务器、调度器、控制器管理器等）出现的问题，影响整个集群的管理和调度能力。常见原因:

API 服务器不可用: API 服务器故障导致无法与集群进行交互，无法创建、更新或删除资源。
调度器故障: 调度器出现问题，导致新创建的 Pod 无法被调度到合适的节点上。
etcd 故障: etcd 是 Kubernetes 的数据存储，如果 etcd 出现故障，可能导致集群状态丢失或无法访问。
控制器管理器故障: 控制器管理器出现问题，可能导致集群中的资源无法正常管理和维护。

排障案例

如果我们采访 K8s 运维工程师，问他们最常见、最头疼的 K8s 故障是啥，那么遥遥领先的必然是这俩：

Pod 处于 pending 状态。
容器处于 CrashLoopBackOff 状态。

接下来，我们就以上述故障为例，说明我们如何用 Prometheus 对 K8s 进行全面监控，来及时识别和分析这类故障的根因及影响范围。

Pod Pending

一个 Pod 生命周期的不同阶段如下图所示：

如果一切顺利的话：

当 Pod 被创建时，它处于 Pending 阶段。
一旦 Pod 被调度并且容器已启动，Pod 会转变为 Running 阶段。

大多数 Pod 从 Pending 到 Running 的过程只需几秒钟，表示该 Pod 已被成功调度到集群节点，并启动容器。

而不幸的是，有些 Pod 无法从 Pending 转为 Running 状态，而是一直卡在了 Pending，正如我们经常碰到的那样：

$ kubectl -n test get pods
NAME                                           READY   STATUS    RESTARTS   AGE
test-1c6sbc7b9e-d5sch                        0/1     Pending   0          18s

Pod 卡在 Pending 状态，最常见的原因是它无法被正常调度到节点，其次是镜像下载问题，此外还可能是依赖问题（volume、configmap 等）。

就拿最为常见的，由于 Pod 无法被正常调度而卡在 Pending 状态的案例来说，它的常见原因如下：

资源限制：如果集群缺乏足够的资源（CPU 或内存），调度器无法将 Pod 放置在任何节点上，导致 Pod 处于 Pending 状态。
污点和容忍度：带有污点的节点会排斥 Pod，除非 Pod 具有匹配的容忍度。
亲和性/反亲和性规则：严格的 Pod 亲和性或反亲和性规则，可能会限制 Pod 可以调度到的节点。
节点选择器标签：Pod 可能被配置为仅在具有特定标签的节点上调度。如果没有节点匹配，Pod 将保持未调度状态。
存储要求：需要特定 PersistentVolumeClaims（PVCs）的 Pod，如果无法满足这些要求，也可能会处于 Pending 状态。

为了主动得知 Pod Pending 状态，我们在使用 Prometheus 监控 K8s 集群时，可以设置相应的告警规则。例如：

groups:
- name: pod-alerts
  rules:
  - alert: PodInPendingStatus
    expr: kube_pod_status_phase{phase="Pending"} > 0
    for: 15m
    labels:
      severity: critical
    annotations:
      summary: "Pod {{ $labels.pod }} Pending"
      description: "集群 {{ $labels.cluster }}/namespace {{ $labels.namespace }}/Pod {{ $labels.pod }}处于NotReady状态超过15分钟"

容器 CrashLoopBackOff

CrashLoopBackOff 代表了 Pod 中的 container 的异常状态：它正在发生永无止境的崩溃循环。

当 Pod 中的容器崩溃，且 Pod 的重启策略设置为 Always 时，Kubernetes 将继续尝试重启容器；但如果容器继续崩溃，它就会 CrashLoopBackOff，不断陷入启动-崩溃-启动-崩溃的循环，只不过在重启之间等待越来越长的 backoff 时间。

关于 CrashLoopBackOff 的根因，几个主要原因包括：

Pod 内存不足：每个 Pod 都有指定的内存空间。当 Pod 被分配的内存少于它实际运行所需的内存时，可能会导致内存不足的情况。此外，如果 Pod 中存在错误，导致在运行过程中不断消耗内存空间（例如，内存泄漏），也会使得可用内存逐渐减少，最终导致容器崩溃，从而触发 CrashLoopBackOff。
探针检查失败：Kubelet 使用探针来检查容器的状态，包括存活探针和启动探针。如果这些探针的检查失败，Kubelet 会认为容器不健康并进行重启。频繁的重启会导致容器进入 CrashLoopBackOff 状态，尤其是在探针配置不当或应用程序未能及时响应时。
应用程序自身的问题：容器内的应用程序可能由于代码错误、配置不当、依赖项缺失或其他运行时异常而不断崩溃。这种情况会导致容器无法稳定运行，从而引发 CrashLoopBackOff。开发人员需要仔细检查应用程序的日志，以识别和修复导致崩溃的根本原因。

若要主动获知容器的 CrashLoopBackoff 状态，可通过 Prometheus 指标 kube_pod_container_status_waiting_reason{reason="CrashLoopBackOff"} ，设置告警规则，例如：

groups:
  - name: pod-alerts
    rules:
      - alert: PodContainerWaiting
        expr: sum by (namespace, pod, container, cluster) (kube_pod_container_status_waiting_reason{job="kube-state-metrics"}) > 0
        for: 1h
        labels:
          severity: critical
        annotations:
          summary: "pod {{ $labels.pod }} container Waiting"
          description: "集群 {{ $labels.cluster }}/namespace {{ $labels.namespace }}/pod {{ $labels.pod }}/container {{ $labels.container}} 处于Waiting状态超过1小时"

最佳实践

通过以下最佳实践，可以帮助我们有效地监控和管理 Kubernetes 集群，确保其稳定高效运行：

全面的可观测工具：如前文所述，我们可以使用 Prometheus 作为主要工具，针对 Kubernetes 的各个层次，进行全栈指标监控。除此之外，围绕可观测性三大支柱——指标、日志和链路追踪——所搭建的全面可观测性，能进一步帮助及时发现和解决集群中的问题。

像腾讯云可观测平台这样的统一平台，即可用于全面收集和分析可观测数据，并形成可视化和告警，以最大限度地维护 Kubernetes 环境的稳定高效运行。

合理设置告警：针对需要及时采取行动的关键指标的异常表现，合理配置告警规则，以便及时响应 Kubernetes 集群中的异常变化。例如：通过密切跟踪节点和 Pod 的指标，及早发现性能问题并采取措施，以防止更大范围的系统故障。

统一可视化大盘：借助 Grafana 等可视化工具，将监控数据收拢到统一的大盘，以进行直观的展示和分析。实时跟踪资源水位和性能指标，能及时发现资源分配不当导致的性能下降或不必要的成本；观察指标时序变化趋势，能快速识别潜在的瓶颈和异常；一目了然的全栈多维数据，还能为资源优化和扩展决策提供有力支持。

自动扩缩容：利用 Kubernetes 的水平 Pod 自动扩展器 (HPA) 和集群自动扩展器，我们能根据实时工作负载需求，自动调整 Pod 和节点的数量，以减少异常事件且合理利用资源。HPA 通常基于 CPU 和内存等内置指标进行扩展。若引入 Prometheus Adapter，则可将 Prometheus 中的自定义指标也整合进 HPA，使其能够基于更丰富的指标进行决策。

优化 Pod 配置：基于实际应用需求配置 Pod 模板中的 CPU 和内存请求/限制，以避免过度分配；合理使用节点和 Pod 的亲和性/反亲和性规则，以平衡工作负载，避免限制调度的灵活性。

腾讯云 Prometheus

腾讯云 Prometheus 是基于开源 Prometheus 构建的高可用、全托管的服务，与腾讯云容器服务（TKE）高度集成，兼容开源生态丰富多样的应用组件，结合腾讯云可观测平台的告警功能和 Prometheus Alertmanager 能力，为用户提供免搭建的高效运维能力，减少开发及运维成本。