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

作者：腾讯云可观测平台

2025-01-02
广东
本文字数：10097 字
阅读完需：约 33 分钟

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

强大的工具，往往伴随着巨大的复杂性。与 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 podsNAME                                           READY   STATUS    RESTARTS   AGEtest-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 能力，为用户提供免搭建的高效运维能力，减少开发及运维成本。