在 EMR On VKE 场景中，合理规划集群容量、提前识别工作负载的稳定性、性能及成本风险，是保障业务持续运行与资源高效利用的核心。通过为 VKE 集群开启云原生基础观测服务，可实现对资源风险的快速感知与分析。本文介绍如何使用云原生可观测服务来分析集群资源的风险性。

前提条件

在使用云原生可观测服务前，需完成以下基础配置，确保监控数据可正常采集与分析：

1. 已开通托管 Prometheus（VMP）服务。
2. 已安装 prometheus-agent 组件，详细操作请参考：开启观测操作指南。

Kubernetes中Pod 的资源配置

Kubernetes 基于 Pod 的资源配置，定义了三种 QoS（Quality of Service，服务质量）类。这些类别决定 Pod 在资源竞争时的优先级及资源分配方式，当节点面临资源压力时，Kubernetes 会依据 QoS 类确定优先驱逐的 Pod。

Guaranteed（保障级）：关键业务首选

定义：​Pod 内所有容器必须同时配置requests（资源请求量）和limits（资源限制量），且两者数值完全相等；此配置下，Pod 的资源不会被其他 Pod 抢占。
核心优势：​资源分配最稳定，适合关键任务（如生产环境中的核心服务），在资源竞争场景中优先级最高，几乎不会被驱逐，可保障核心服务的持续稳定运行。
潜在不足：资源利用率较低，因limits严格限制资源使用上限，即使节点有空闲资源，Pod 也无法超额使用。
适用场景：生产环境中的关键任务服务，如数据库（MySQL、PostgreSQL）、核心业务 API 服务、消息队列（Kafka）等对稳定性要求极高的组件。
配置示例：

resources:
  requests:  # 资源请求量（集群承诺分配的最小资源）
    cpu: "500m"  # 500毫核（即0.5核）
    memory: "8Gi"  # 8GB内存
  limits:    # 资源限制量（Pod可使用的最大资源）
    cpu: "500m"  # 与requests相等
    memory: "8Gi"  # 与requests相等

Burstable（弹性级）：非核心业务平衡选择

定义：

• 至少一个容器设置了 requests 或 limits，但两者的值不相等，或者部分容器没有设置资源。
• Pod 可以使用超过 requests 的资源，但不能超过 limits。

核心优势：​资源利用率较高，支持动态弹性使用资源；未配置limits时，可使用节点剩余的全部空闲资源；资源竞争时优先级高于 BestEffort，低于 Guaranteed。
潜在不足：资源稳定性弱于 Guaranteed，当节点资源紧张时，若 Pod 使用资源超过requests，可能被优先驱逐。
适用场景：​适合非关键任务服务，如开发环境、测试环境，或需要一定资源保证但允许资源动态扩展的服务。
配置示例：

resources:
  requests:
    cpu: "500m"
    memory: "8Gi"
  limits:
    cpu: "1"  # 1核（超过requests的500m）
    memory: "16Gi"  # 16GB（超过requests的8Gi）