Kubernetes 集群中的异常可能来自控制面、节点、网络、存储、工作负载或应用自身。生产环境需要建立覆盖控制面、数据面和业务系统的可观测体系，并综合使用 Metrics、Kubernetes Event 和 Logs 等信息了解系统运行状态。本文首先介绍 Kubernetes 可观测的基础知识以及 VKE 提供的可观测能力，然后分别介绍控制面、数据面和业务系统的观测最佳实践。 ## Kubernetes 可观测基础 Kubernetes 中的异常可能发生在不同层级。理解这些层级以及常用的观测信息，有助于明确不同观测能力分别解决什么问题。Kubernetes 集群中的观测不仅用于故障发生后的排查，也用于及时发现风险、辅助故障恢复，以及持续进行性能分析和容量优化。 ### 观测层级从可观测角度，Kubernetes 集群可以划分为控制面、数据面和业务系统三个层级。不同层级职责不同、信号各异，异常可能相互影响。例如：节点资源不足可能导致 Pod 无法调度，网络异常可能导致应用访问失败，而 Pod 正常运行也不代表最终业务一定正常。因此，完整的 Kubernetes 可观测需要同时关注控制面、数据面和业务系统，而不能只通过 CPU、内存等基础资源指标判断集群和业务是否健康。不同层级的主要观测对象和观测重点，如下表所示： |观测层级 |观测对象 |观测重点 | |---|---|---| |控制面 |kube\-apiserver、kube\-scheduler、kube\-controller\-manager、etcd 等控制面组件。 |集群 API、资源调度和状态协调等核心能力是否正常。 | |数据面 |节点、网络、存储、GPU / RDMA 以及部署在集群中的组件。 |集群中的资源是否足够，能否正常承载和支撑工作负载运行。 | |业务系统 |Workload、Pod、Container 以及业务应用。 |集群中的应用容器是否运行正常、业务服务是否正常。 | ### **观测数据类型** 分析 Kubernetes 集群和业务运行情况时，通常需要综合使用多类观测数据。不同类型的观测数据关注点不同，单独依赖某一类往往只能反映局部现象，难以判断影响范围和根因；将指标、日志与 Kubernetes 事件结合使用，才能在排障时形成完整的分析链路。 |观测对象 |主要用途 | |---|---| |指标 |持续观测集群资源、组件、Kubernetes 对象和业务运行情况，并用于看板和告警。

说明

指标既可以是 CPU、内存等基础资源指标，也可以是组件运行指标、Kubernetes 对象状态指标，以及请求量、错误率、延迟等业务指标。单独看到某一项指标异常，通常只能说明“现象”；要判断影响范围和根因，还需要结合其他观测信息交叉分析。

| |日志 |记录组件或应用运行过程中的详细信息。 | |Kubernetes 事件 |记录 Kubernetes 对象在调度、启动、挂载等生命周期过程中发生的事件。

分析具体 Kubernetes 对象时，还需要结合对象当前状态，确认实际运行情况是否符合预期。出现异常时，通常可以先通过指标发现问题，再结合 Kubernetes 事件、对象状态和日志逐步定位原因。指标、Kubernetes 事件、日志和 Kubernetes 对象状态关注的问题不同，实际分析过程中通常需要结合使用。 | ## VKE 可观测能力 VKE 提供覆盖集群全链路的可观测能力，包括指标监控、日志采集、Kubernetes 事件管理与告警，并与云监控、日志服务等可观测产品深度集成，帮助您及时发现异常、快速定位问题并持续优化集群性能。详情请参见 [可观测性概述](https://www.volcengine.com/docs/6460/1117848)。 ### 指标指标以时序数据的形式持续记录集群、组件、Kubernetes 对象和业务的运行状态，是搭建监控看板和配置告警的数据基础。通过持续采集和分析指标，可以及时发现资源瓶颈、组件异常和业务性能劣化，也可以基于历史数据进行容量规划和趋势分析。 VKE 集成 [托管 Prometheus（VMP）](https://docs.volcengine.com/docs/6731/106488?lang=zh)。开启云原生观测后，可以通过 VMP 完成 Kubernetes 相关指标的采集、存储和查询。VKE 在这些指标数据基础上，提供容器服务观测以及控制面、网络、存储、AI 等场景的观测能力。对于业务自身暴露的 Prometheus 格式指标，也可以通过 VKE 服务发现能力进行指标发现和采集。详情请参见如下文档： * [容器服务观测](https://www.volcengine.com/docs/6460/148257) * [服务发现](https://www.volcengine.com/docs/6460/1117851) ### 日志日志以文本形式完整记录 Kubernetes 组件和业务应用运行过程中的详细信息，是定位具体错误原因的核心依据。相比指标，日志携带更丰富的上下文，能够直接反映错误堆栈、请求参数和异常状态，适用于深入排查指标告警无法覆盖的问题。 VKE 集成 [日志服务（TLS）](https://docs.volcengine.com/docs/6470/73638?lang=zh)，由 TLS 提供日志的采集、存储、检索和分析能力。包括： * [容器日志](https://docs.volcengine.com/docs/6460/101018?lang=zh)：采集运行在集群中的容器产生的标准输出日志和文件日志。 * [控制面组件日志](https://docs.volcengine.com/docs/6460/195525?lang=zh)：采集 kube\-apiserver、kube\-scheduler、kube\-controller\-manager、etcd 等控制面组件日志。 ### Kubernetes 事件 Kubernetes 事件由 Kubernetes 控制面原生产生，记录集群中各类对象在调度、启动、扩缩容等生命周期过程中的状态变化和异常。与日志和指标不同，Kubernetes 事件直接来源于控制面，能够反映调度失败、资源不足、镜像拉取失败等底层基础设施层问题，是指标和日志的有效补充。 VKE 支持查看集群原生 Kubernetes 事件。由于事件默认仅短期保留，如需长期存储和历史查询，可通过事件持久化能力将事件数据同步至 [日志服务（TLS）](https://docs.volcengine.com/docs/6470/73638?lang=zh)。详情请参见 [配置和查看持久化事件](https://www.volcengine.com/docs/6460/108522)。 ### 告警在云原生体系中，告警是保障集群稳定运行的重要手段。不同于传统以 CPU、内存资源使用量为主的告警，云原生场景下的告警来源更多样：从基础设施层的资源监控指标，到应用层的日志内容，再到 Kubernetes 原生的集群事件，覆盖面更广、感知粒度更细。面向不同的观测数据类型，VKE 支持多种告警方式，以适应不同的监控需求和运维场景，如下表所示： |观测数据类型 |告警能力说明 |参考文档 | |---|---|---| |指标 |基于托管 Prometheus（VMP）提供指标告警能力，并针对 Kubernetes 场景提供告警配置和预置告警模板。 |* [配置告警](https://www.volcengine.com/docs/6460/2484281)

* [预置告警模板](https://www.volcengine.com/docs/6460/2484282) | |日志/事件 |基于日志服务（TLS）提供日志/事件告警能力，根据日志检索分析结果配置告警策略。 |* [快速设置日志告警](https://www.volcengine.com/docs/6470/1218714)

* [创建告警策略](https://www.volcengine.com/docs/6470/103027) | ## 可观测最佳实践在生产环境中搭建 Kubernetes 可观测体系时，建议遵循以下原则： * **覆盖关键层级**：同时关注控制面、数据面和业务系统，避免只关注单一组件或基础资源指标。 * **按实际使用范围建设**：根据集群实际使用的网络、存储、AI 资源以及部署的 VKE 组件，按需建立对应的观测能力，避免无效投入。 * **关注最终业务状态**：除 Kubernetes 对象和基础设施运行状态外，核心业务还需要建立能够反映服务质量的业务指标和告警。 * **综合使用多种观测信号**：出现异常时，结合指标、Kubernetes 对象状态、事件和日志进行交叉分析，而不是依赖单一信号判断。 ### 控制面 Kubernetes 控制面负责集群 API、资源调度、状态协调、云资源相关控制和元数据存储等核心功能，主要组件包括 kube\-apiserver、kube\-scheduler、kube\-controller\-manager、cloud\-controller\-manager、etcd 等组件。控制面异常可能影响资源创建、扩缩容、调度以及状态更新等操作。在日常观测中，建议重点关注控制面组件的运行状态、API 请求延迟与错误率，以及 etcd 的读写性能和存储容量。详情请参见 [控制面服务观测](https://www.volcengine.com/docs/6460/1214007)。如果需要进一步分析控制面组件日志，可以将控制面组件日志接入日志服务进行分析和告警。详情请参见 [采集控制面组件日志](https://www.volcengine.com/docs/6460/195525)。 ### 数据面数据面负责实际承载业务工作负载。根据集群实际使用情况，需要建立节点、网络、存储、AI 资源以及部署在用户集群中的 VKE 组件等领域的观测能力。 #### 节点节点异常可能导致节点上的 Pod 不可用，也可能影响新的 Pod 正常运行。除了 CPU、内存和磁盘使用率，还需要关注节点是否处于 Ready 状态，以及是否存在磁盘压力、内存压力等异常状态。通过 [容器服务观测](https://www.volcengine.com/docs/6460/148257)，您可以查看节点运行状态以及 CPU、内存、磁盘等资源使用情况。包括： * 节点是否正常运行。 * CPU、内存、磁盘等资源是否存在异常或容量风险。除基础状态和资源使用情况外，您还需要关注节点关键组件的状态。对于 Kubelet、Runtime 和 GPU 等节点故障，可以使用 VKE 提供的检查自愈观测能力。详情请参见 [检查自愈观测](https://www.volcengine.com/docs/6460/1336077)。 #### 网络 Kubernetes 网络涉及服务发现、业务入口和 Pod 网络等不同链路，可以分别从 DNS、Ingress 和 CNI 等场景建立观测能力。网络问题往往表现为访问超时、连接失败或解析异常，因此观测时既要看网络组件自身状态，也要结合业务请求结果判断实际影响。详情如下表所示。 |观测对象 |场景说明 |参考文档 | |---|---|---| |DNS |DNS 异常可能影响 Service 访问和域名解析。如果业务依赖集群 DNS，可以通过 DNS 服务观测查看 DNS 相关运行情况。 |[DNS 服务观测](https://www.volcengine.com/docs/6460/1214008) | |Ingress |对于通过 Ingress 对外提供服务的应用，除了后端 Workload 和 Pod，还需要关注 Ingress 自身的运行情况。 |* [Ingress 服务观测](https://www.volcengine.com/docs/6460/1214009)

* [自定义 Nginx Ingress Controller 观测最佳实践](https://www.volcengine.com/docs/6460/1131234) | |CNI |CNI 网络异常可能影响 Pod 间通信以及 Pod 对其他服务的访问。 |[CNI 网络观测](https://www.volcengine.com/docs/6460/1221485) | #### 存储存储场景可以分别关注 CSI 组件和存储链路，以及容器自身的存储使用情况。存储问题既可能表现为挂载失败、卷不可用，也可能表现为容器文件系统或临时存储空间不足，因此需要同时关注组件状态和实际使用情况。 |观测对象 |场景说明 |参考文档 | |---|---|---| |CSI 存储 |CSI 组件及相关存储链路。 |[CSI 存储观测](https://www.volcengine.com/docs/6460/1224025) | |容器存储 |容器文件系统和 Pod 临时存储使用情况。 |[容器存储观测](https://www.volcengine.com/docs/6460/2359555) | #### AI 资源对于使用 GPU、RDMA 等 AI 基础资源的业务，除了 Kubernetes 对象状态，还需要关注底层加速资源自身的状态和使用情况。包括： * [AI 资源观测](https://docs.volcengine.com/docs/6460/1214011?lang=zh)：允许监控集群中的 AI 基础资源，包括 GPU、RDMA 等。 * [AI 训练任务监控](https://docs.volcengine.com/docs/6460/1140994?lang=zh)：支持基于 AI 训练任务维度，监控集群中 AI 任务的运行和资源使用情况。 ### 业务系统在生产环境中搭建业务系统的观测系统时，需要同时关注以下几个方面： * **运行状态**：Workload、Pod 和 Container 是否正常运行。 * **业务状态**：应用是否能够正常提供服务，业务指标是否符合预期。 Kubernetes 对象运行正常，并不代表最终业务和服务一定正常。因此，业务系统观测不能只停留在 Workload、Pod 和 Container 是否存活，还需要关注请求成功率、延迟以及关键依赖是否正常。 #### Workload、Pod 和 Container Workload、Pod 和 Container 反映业务在 Kubernetes 中的运行状态。通过 [容器服务观测](https://www.volcengine.com/docs/6460/148257)，可以从工作负载、Pod 和 Container 等层级查看运行状态和资源使用情况。包括： * 工作负载是否正常运行。 * Pod 和 Container 是否处于预期状态。 * CPU、内存等资源使用是否存在异常。当 Pod 或 Container 出现`Pending`、`CrashLoopBackOff`、`ImagePullBackOff`、`OOMKilled`等异常时，可以进一步结合 Kubernetes 对象状态、Event 和日志分析具体原因。这类异常通常反映的是调度、启动、镜像拉取、资源限制或进程运行等不同阶段的问题，分析时需要结合异常发生阶段判断排查方向。 #### 业务应用对于核心业务，除了 Kubernetes 对象运行状态，还需要从业务视角观察最终服务质量。包括： * 请求量。 * 请求错误率。 * 请求延迟。 * 业务成功率。 * 关键下游依赖。这些指标需要根据具体业务自行定义。应优先通过业务指标判断最终业务服务是否正常，再结合 Kubernetes 和基础设施相关信息分析原因。对于有明确服务等级目标（SLO）的核心业务，可以进一步基于 SLO 建立监控和告警。如果业务已经暴露 Prometheus 格式的指标，可以通过集群的 [服务发现](https://www.volcengine.com/docs/6460/1117851) 能力完成指标发现和采集。其中，ServiceMonitor、PodMonitor 解决的是 Prometheus 指标发现和采集问题，并不等同于完整的应用可观测体系。如果需要进一步观察应用层、网络层等信息，可以使用全栈观测能力。详情请参见如下文档： * [全栈观测概述](https://www.volcengine.com/docs/6460/1314296) * [开启全栈观测](https://www.volcengine.com/docs/6460/1214012)