容器服务
容器服务
文档指南
请输入
- 文档首页
容器服务容器服务 VKE最佳实践可观测性容器场景可观测最佳实践
复制全文
下载 pdf容器场景可观测最佳实践
文档反馈
问问助手Kubernetes 集群中的异常可能来自控制面、节点、网络、存储、工作负载或应用自身。生产环境需要建立覆盖控制面、数据面和业务系统的可观测体系，并综合使用 Metrics、Kubernetes Event 和 Logs 等信息了解系统运行状态。本文首先介绍 Kubernetes 可观测的基础知识以及 VKE 提供的可观测能力，然后分别介绍控制面、数据面和业务系统的观测最佳实践。
Kubernetes 可观测基础
Kubernetes 中的异常可能发生在不同层级。理解这些层级以及常用的观测信息，有助于明确不同观测能力分别解决什么问题。Kubernetes 集群中的观测不仅用于故障发生后的排查，也用于及时发现风险、辅助故障恢复，以及持续进行性能分析和容量优化。
观测层级
从可观测角度，Kubernetes 集群可以划分为控制面、数据面和业务系统三个层级。不同层级职责不同、信号各异，异常可能相互影响。例如：节点资源不足可能导致 Pod 无法调度，网络异常可能导致应用访问失败，而 Pod 正常运行也不代表最终业务一定正常。因此，完整的 Kubernetes 可观测需要同时关注控制面、数据面和业务系统，而不能只通过 CPU、内存等基础资源指标判断集群和业务是否健康。
不同层级的主要观测对象和观测重点，如下表所示：
观测数据类型
分析 Kubernetes 集群和业务运行情况时，通常需要综合使用多类观测数据。不同类型的观测数据关注点不同，单独依赖某一类往往只能反映局部现象，难以判断影响范围和根因；将指标、日志与 Kubernetes 事件结合使用，才能在排障时形成完整的分析链路。
VKE 可观测能力
VKE 提供覆盖集群全链路的可观测能力，包括指标监控、日志采集、Kubernetes 事件管理与告警，并与云监控、日志服务等可观测产品深度集成，帮助您及时发现异常、快速定位问题并持续优化集群性能。详情请参见 可观测性概述。
指标
指标以时序数据的形式持续记录集群、组件、Kubernetes 对象和业务的运行状态，是搭建监控看板和配置告警的数据基础。通过持续采集和分析指标，可以及时发现资源瓶颈、组件异常和业务性能劣化，也可以基于历史数据进行容量规划和趋势分析。
VKE 集成 托管 Prometheus（VMP）。开启云原生观测后，可以通过 VMP 完成 Kubernetes 相关指标的采集、存储和查询。VKE 在这些指标数据基础上，提供容器服务观测以及控制面、网络、存储、AI 等场景的观测能力。对于业务自身暴露的 Prometheus 格式指标，也可以通过 VKE 服务发现能力进行指标发现和采集。详情请参见如下文档：
- 服务发现
日志
日志以文本形式完整记录 Kubernetes 组件和业务应用运行过程中的详细信息，是定位具体错误原因的核心依据。相比指标，日志携带更丰富的上下文，能够直接反映错误堆栈、请求参数和异常状态，适用于深入排查指标告警无法覆盖的问题。
- 容器日志：采集运行在集群中的容器产生的标准输出日志和文件日志。
- 控制面组件日志：采集 kube-apiserver、kube-scheduler、kube-controller-manager、etcd 等控制面组件日志。
Kubernetes 事件
Kubernetes 事件由 Kubernetes 控制面原生产生，记录集群中各类对象在调度、启动、扩缩容等生命周期过程中的状态变化和异常。与日志和指标不同，Kubernetes 事件直接来源于控制面，能够反映调度失败、资源不足、镜像拉取失败等底层基础设施层问题，是指标和日志的有效补充。
告警
在云原生体系中，告警是保障集群稳定运行的重要手段。不同于传统以 CPU、内存资源使用量为主的告警，云原生场景下的告警来源更多样：从基础设施层的资源监控指标，到应用层的日志内容，再到 Kubernetes 原生的集群事件，覆盖面更广、感知粒度更细。面向不同的观测数据类型，VKE 支持多种告警方式，以适应不同的监控需求和运维场景，如下表所示：
可观测最佳实践
在生产环境中搭建 Kubernetes 可观测体系时，建议遵循以下原则：
- 覆盖关键层级：同时关注控制面、数据面和业务系统，避免只关注单一组件或基础资源指标。
- 按实际使用范围建设：根据集群实际使用的网络、存储、AI 资源以及部署的 VKE 组件，按需建立对应的观测能力，避免无效投入。
- 关注最终业务状态：除 Kubernetes 对象和基础设施运行状态外，核心业务还需要建立能够反映服务质量的业务指标和告警。
- 综合使用多种观测信号：出现异常时，结合指标、Kubernetes 对象状态、事件和日志进行交叉分析，而不是依赖单一信号判断。
控制面
Kubernetes 控制面负责集群 API、资源调度、状态协调、云资源相关控制和元数据存储等核心功能，主要组件包括 kube-apiserver、kube-scheduler、kube-controller-manager、cloud-controller-manager、etcd 等组件。控制面异常可能影响资源创建、扩缩容、调度以及状态更新等操作。
在日常观测中，建议重点关注控制面组件的运行状态、API 请求延迟与错误率，以及 etcd 的读写性能和存储容量。详情请参见 控制面服务观测。如果需要进一步分析控制面组件日志，可以将控制面组件日志接入日志服务进行分析和告警。详情请参见 采集控制面组件日志。
数据面
数据面负责实际承载业务工作负载。根据集群实际使用情况，需要建立节点、网络、存储、AI 资源以及部署在用户集群中的 VKE 组件等领域的观测能力。
节点
节点异常可能导致节点上的 Pod 不可用，也可能影响新的 Pod 正常运行。除了 CPU、内存和磁盘使用率，还需要关注节点是否处于 Ready 状态，以及是否存在磁盘压力、内存压力等异常状态。
- 节点是否正常运行。
- CPU、内存、磁盘等资源是否存在异常或容量风险。
网络
Kubernetes 网络涉及服务发现、业务入口和 Pod 网络等不同链路，可以分别从 DNS、Ingress 和 CNI 等场景建立观测能力。网络问题往往表现为访问超时、连接失败或解析异常，因此观测时既要看网络组件自身状态，也要结合业务请求结果判断实际影响。详情如下表所示。
存储
存储场景可以分别关注 CSI 组件和存储链路，以及容器自身的存储使用情况。存储问题既可能表现为挂载失败、卷不可用，也可能表现为容器文件系统或临时存储空间不足，因此需要同时关注组件状态和实际使用情况。
AI 资源
对于使用 GPU、RDMA 等 AI 基础资源的业务，除了 Kubernetes 对象状态，还需要关注底层加速资源自身的状态和使用情况。包括：
- AI 资源观测：允许监控集群中的 AI 基础资源，包括 GPU、RDMA 等。
- AI 训练任务监控：支持基于 AI 训练任务维度，监控集群中 AI 任务的运行和资源使用情况。
业务系统
在生产环境中搭建业务系统的观测系统时，需要同时关注以下几个方面：
- 运行状态：Workload、Pod 和 Container 是否正常运行。
- 业务状态：应用是否能够正常提供服务，业务指标是否符合预期。
Kubernetes 对象运行正常，并不代表最终业务和服务一定正常。因此，业务系统观测不能只停留在 Workload、Pod 和 Container 是否存活，还需要关注请求成功率、延迟以及关键依赖是否正常。
Workload、Pod 和 Container
Workload、Pod 和 Container 反映业务在 Kubernetes 中的运行状态。通过 容器服务观测，可以从工作负载、Pod 和 Container 等层级查看运行状态和资源使用情况。包括：
- 工作负载是否正常运行。
- Pod 和 Container 是否处于预期状态。
- CPU、内存等资源使用是否存在异常。
当 Pod 或 Container 出现Pending、CrashLoopBackOff、ImagePullBackOff、OOMKilled等异常时，可以进一步结合 Kubernetes 对象状态、Event 和日志分析具体原因。这类异常通常反映的是调度、启动、镜像拉取、资源限制或进程运行等不同阶段的问题，分析时需要结合异常发生阶段判断排查方向。
业务应用
对于核心业务，除了 Kubernetes 对象运行状态，还需要从业务视角观察最终服务质量。包括：
- 请求量。
- 请求错误率。
- 请求延迟。
- 业务成功率。
- 关键下游依赖。
这些指标需要根据具体业务自行定义。应优先通过业务指标判断最终业务服务是否正常，再结合 Kubernetes 和基础设施相关信息分析原因。对于有明确服务等级目标（SLO）的核心业务，可以进一步基于 SLO 建立监控和告警。
如果业务已经暴露 Prometheus 格式的指标，可以通过集群的 服务发现 能力完成指标发现和采集。其中，ServiceMonitor、PodMonitor 解决的是 Prometheus 指标发现和采集问题，并不等同于完整的应用可观测体系。如果需要进一步观察应用层、网络层等信息，可以使用全栈观测能力。详情请参见如下文档：
最近更新时间：2026.08.21 15:51:19
这个页面对您有帮助吗？
有用
有用
无用
无用