收集和查看控制平面指标

本页面介绍了如何配置 Google Kubernetes Engine (GKE) 集群，以使用 Google Cloud Managed Service for Prometheus 将 Kubernetes API 服务器、调度器和控制器管理器发出的指标发送到 Cloud Monitoring。本页面还介绍了这些指标在写入 Monitoring 时如何设置其格式，以及如何查询指标。

准备工作

在开始之前，请确保您已执行以下任务：

  • 启用 Google Kubernetes Engine API。
    • 启用 Google Kubernetes Engine API
  • 如果您要使用 Google Cloud CLI 执行此任务，请安装并初始化 gcloud CLI。 如果您之前安装了 gcloud CLI，请运行 gcloud components update 以获取最新版本。

要求

如需将 Kubernetes 控制平面组件发出的指标发送到 Cloud Monitoring，需要满足以下要求：

配置控制平面指标的收集

您可以使用 Google Cloud 控制台、gcloud CLI 或 Terraform 在现有 GKE 集群中启用控制平面指标。

控制台

您可以通过集群的可观测性标签页或集群的详细信息标签页为集群启用控制平面指标。使用可观测性标签页时，您可以在启用指标软件包之前预览可用的图表和指标。

如需从集群的可观测性标签页启用控制平面指标，请执行以下操作：

  1. 在 Google Cloud 控制台中，转到 Kubernetes 集群页面：

    转到 Kubernetes 集群

    如果您使用搜索栏查找此页面，请选择子标题为 Kubernetes Engine 的结果。

  2. 点击集群的名称，然后选择可观测性标签页。

  3. 从功能列表中选择控制平面。

  4. 点击启用软件包。

    如果控制平面指标已经启用，您则会看到一组控制平面指标的图表。

如需从集群的详细信息标签页启用控制平面指标，请执行以下操作：

  1. 在 Google Cloud 控制台中，转到 Kubernetes 集群页面：

    转到 Kubernetes 集群

    如果您使用搜索栏查找此页面，请选择子标题为 Kubernetes Engine 的结果。

  2. 点击您的集群名称。

  3. 在标有 Cloud Monitoring 的功能行中，点击修改图标。

  4. 在出现的修改 Cloud Monitoring对话框中，确认选中启用 Cloud Monitoring。

  5. 在组件下拉菜单中，选择要从中收集指标的控制平面组件：API 服务器、调度器或控制器管理器。

  6. 点击确定。

  7. 点击保存更改。

gcloud

更新集群以收集 Kubernetes API 服务器、调度器和控制器管理器发出的指标：

gcloud container clusters update CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --monitoring=SYSTEM,API_SERVER,SCHEDULER,CONTROLLER_MANAGER

替换以下内容：

Terraform

如需使用 Terraform 配置 Kubernetes 控制平面指标的集合，请参阅 google_container_cluster 的 Terraform 注册表中的 monitoring_config 块。如需了解有关将 Google Cloud 与 Terraform 搭配使用的一般信息，请参阅将 Terraform 与 Google Cloud 搭配使用。

配额

控制平面指标使用 Cloud Monitoring API 的“每分钟的时序注入请求数”配额。在启用指标包之前，请检查该配额的最近峰值用量。如果您在同一项目中有多个集群，或者已经达到该配额上限，则可以申请增加配额，然后才能启用任一可观测性软件包。

价格

GKE 控制平面指标使用 Google Cloud Managed Service for Prometheus 将指标加载到 Cloud Monitoring 中。Cloud Monitoring 会根据注入的样本数量收取这些指标的注入费用。但是，对于属于已启用 GKE Enterprise 版本的项目的已注册集群，这些指标是免费的。

如需了解详情，请参阅 Cloud Monitoring 价格。

指标格式

写入 Cloud Monitoring 的所有 Kubernetes 控制平面指标都使用资源类型 prometheus_target。每个指标名称都以 prometheus.googleapis.com/ 为前缀，并带有表示 Prometheus 指标类型的后缀，例如 /gauge、/histogram 或 /counter。否则，每个指标名称都与开源 Kubernetes 公开的指标名称相同。

从 Cloud Monitoring 导出

您可以使用 Cloud Monitoring API 从 Cloud Monitoring 导出 Kubernetes 控制平面指标。由于所有 Kubernetes 控制平面指标均使用 Google Cloud Managed Service for Prometheus 注入，因此可以使用 Prometheus 查询语言 (PromQL) 查询 Kubernetes 控制平面指标。您还可以使用 Monitoring Query Language (MQL) 查询它们。

查询指标

查询 Kubernetes 控制平面指标时，您使用的名称取决于您使用的是 PromQL 还是基于 Cloud Monitoring 的功能，例如 MQL 或 Metrics Explorer 菜单驱动的界面。

以下 Kubernetes 控制平面指标表展示了每个指标名称的两个版本：

  • PromQL 指标名称：在 Google Cloud 控制台的 Cloud Monitoring 页面中或 Cloud Monitoring API 的 PromQL 字段中使用 PromQL 时，请使用 PromQL 字段名称。
  • Cloud Monitoring 指标名称：使用其他 Cloud Monitoring 功能时，请使用下表中的 Cloud Monitoring 指标名称。此名称必须以 prometheus.googleapis.com/ 为前缀，表中的条目省略了该前缀。

API 服务器指标

本部分提供了 API 服务器指标的列表以及有关如何解读和使用指标的其他信息。

API 服务器指标列表

启用 API 服务器指标时，GKE 集群所在项目中的所有下列指标都会导出到 Cloud Monitoring。

此表中的 Cloud Monitoring 指标名称必须以 prometheus.googleapis.com/ 为前缀。表中的条目已省略该前缀。

PromQL 指标名称发布阶段
Cloud Monitoring 指标名称
种类、类型、单位
受监控的资源
所需的 GKE 版本		 说明
标签
apiserver_current_inflight_requests GA
apiserver_current_inflight_requests/gauge
Gauge、Double、1
prometheus_target
1.22.13+ 		上一秒每个请求种类的此 apiserver 当前使用的运行中请求数上限。

request_kind
apiserver_flowcontrol_current_executing_seats Beta 版
apiserver_flowcontrol_current_executing_seats/gauge
Gauge、Double、1
prometheus_target
1.28.3+ 		API 优先级和公平性子系统中当前正在执行的（WATCH 的初始阶段，否则是任何阶段）请求占用的并发（席位数）。

flow_schema
priority_level
apiserver_flowcontrol_current_inqueue_requests Beta 版
apiserver_flowcontrol_current_inqueue_requests/gauge
Gauge、Double、1
prometheus_target
1.28.3+（对于之前的次要版本，则为 1.25.16-gke.1360000+、1.26.11+、1.27.8+） 		当前正在等待排入 API 优先级和公平性子系统队列的请求数。

flow_schema
priority_level
apiserver_flowcontrol_nominal_limit_seats Beta 版
apiserver_flowcontrol_nominal_limit_seats/gauge
Gauge、Double、1
prometheus_target
1.28.3+（对于之前的次要版本，则为 1.26.11+、1.27.8+） 		为每个优先级配置的执行席位标称数。

priority_level
apiserver_flowcontrol_rejected_requests_total Beta 版
apiserver_flowcontrol_rejected_requests_total/counter
Cumulative、Double、1
prometheus_target
1.28.3+（对于之前的次要版本，则为 1.25.16-gke.1360000+、1.26.11+、1.27.8+） 		API 优先级和公平性子系统拒绝的请求数。

flow_schema
priority_level
reason
apiserver_flowcontrol_request_wait_duration_seconds Beta 版
apiserver_flowcontrol_request_wait_duration_seconds/histogram
Cumulative、Distribution、s
prometheus_target
1.28.3+（对于之前的次要版本，则为 1.25.16-gke.1360000+、1.26.11+、1.27.8+） 		请求在其队列中等待的时长。

execute
flow_schema
priority_level
apiserver_request_duration_seconds GA
apiserver_request_duration_seconds/histogram
Cumulative、Distribution、s
prometheus_target
1.23.6+ 		每个动词、试运行值、组、版本、资源、子资源、范围和组件的响应延迟时间分布（以秒为单位）。

component
dry_run
group
resource
scope
subresource
verb
version
apiserver_request_total GA
apiserver_request_total/counter
Cumulative、Double、1
prometheus_target
1.22.13+ 		按每个动词、试运行值、组、版本、资源、范围、组件和 HTTP 响应代码细分的 apiserver 请求计数器。

code
component
dry_run
group
resource
scope
subresource
verb
version
apiserver_response_sizes GA
apiserver_response_sizes/histogram
Cumulative、Distribution、1
prometheus_target
1.22.13+ 		每个组、版本、动词、资源、子资源、范围和组件的响应大小分布（以字节为单位）。

component
group
resource
scope
subresource
verb
version
apiserver_storage_objects GA
apiserver_storage_objects/gauge
Gauge、Double、1
prometheus_target
1.22.13+ 		上一次检查拆分时存储的对象的数量（按种类）。

resource
apiserver_admission_controller_admission_duration_seconds GA
apiserver_admission_controller_admission_duration_seconds/histogram
Cumulative、Distribution、s
prometheus_target
1.23.6+ 		准入控制器延迟时间直方图（以秒为单位），通过名称进行标识并按每个操作和 API 资源和类型（验证或允许）细分。

name
operation
rejected
type
apiserver_admission_step_admission_duration_seconds GA
apiserver_admission_step_admission_duration_seconds/histogram
Cumulative、Distribution、s
prometheus_target
1.22.13+ 		准入子步骤延迟时间直方图（以秒为单位），按每个操作和 API 资源和步骤类型（验证或允许）细分。

operation
rejected
type
apiserver_admission_webhook_admission_duration_seconds GA
apiserver_admission_webhook_admission_duration_seconds/histogram
Cumulative、Distribution、s
prometheus_target
1.22.13+ 		准入网络钩子延迟时间直方图（以秒为单位），按每个操作和 API 资源和类型（验证或允许）细分。

name
operation
rejected
type

以下部分提供了有关 API 服务器指标的更多信息。

apiserver_request_duration_seconds

使用此指标可监控 API 服务器中的延迟时间。此指标记录的请求时长包括请求处理的所有阶段（从收到请求开始到服务器完成对客户端的响应）。具体而言，该时长包括在以下方面花费的时间：

  • 请求的身份验证和授权。
  • 调用与请求关联的第三方和系统 webhook。
  • 从内存缓存（对于指定 resourceVersion 网址参数的请求）或 etcd（对于所有其他请求）中提取请求的对象。
  • 您可以使用 group、version、resource 和 subresource 标签来唯一标识缓慢的请求，以进一步调查。
  • 将响应写入客户端并接收客户端的响应。

如需详细了解如何使用此指标，请参阅延迟时间。

此指标的基数非常高。使用此指标时，您必须使用过滤条件或分组来查找延迟时间的具体来源。

apiserver_admission_controller_admission_duration_seconds

此指标衡量内置准入网络钩子（而非第三方网络钩子）中的延迟时间。如需诊断第三方 webook 的延迟时间问题，请使用 apiserver_admission_webhook_admission_duration_seconds 指标。

apiserver_admission_webhook_admission_duration_seconds 和
apiserver_admission_step_admission_duration_seconds

这些指标衡量外部第三方准入 webook 中的延迟时间。apiserver_admission_webhook_admission_duration_seconds 指标通常是更有用的指标。如需详细了解如何使用此指标，请参阅延迟时间。

apiserver_request_total

使用此指标可监控 API 服务器上的请求流量。您还可以使用它来确定请求的成功和失败率。如需详细了解如何使用此指标，请参阅流量和错误率。

此指标的基数非常高。使用此指标时，您必须使用过滤条件或分组来确定错误来源。

apiserver_storage_objects

使用此指标可以检测系统饱和度并找出可能的资源泄露。如需了解详情，请参阅饱和度。

apiserver_current_inflight_requests

此指标用于记录过去一秒时间范围内主动处理的请求数量上限。如需了解详情，请参阅饱和度。

该指标不包括长时间运行的请求（例如“监视”）。

监控 API 服务器

通过 API 服务器指标，您可以深入了解系统运行状况的主要信号：

本部分介绍如何使用 API 服务器指标来监控 API 服务器的运行状况。

延迟时间

当 API 服务器过载时，请求延迟时间会增加。如需测量对 API 服务器的请求的延迟时间，请使用 apiserver_request_duration_seconds 指标。如需更精确地确定延迟时间的来源，您可以按 verb 或 resource 标签对指标进行分组。

GET、POST 或 PATCH 等单资源调用的建议上限为 1 秒。命名空间和集群范围的 LIST 调用的建议上限为 30 秒。上限由开源 Kubernetes 社区定义的 SLO 设置：如需了解详情，请参阅 API 调用延迟时间 SLI/SLO 详细信息。

如果 apiserver_request_duration_seconds 指标的值超出预期时长，请调查以下可能的原因：

  • Kubernetes 控制平面可能过载。如需进行检查，请查看 apiserver_request_total 和 apiserver_storage_objects 指标。
    • 使用 code 标签确定请求是否已成功处理。如需了解可能的值，请参阅 HTTP 状态代码。
    • 使用 group、version、resource 和 subresource 标签来唯一标识请求。

  • 第三方准入 webhook 运行缓慢或无响应。 如果 apiserver_admission_webhook_admission_duration_seconds 指标的值不断增加，则表示您的某些第三方或用户定义的准入 webhook 速度缓慢或无响应。准入网络钩子延迟可能会导致作业调度延迟。

    • 如需查询 Kubernetes 控制平面每个实例的第 99 百分位的 webhook 延迟时间，请使用以下 PromQL 查询：

      sum by (instance) (histogram_quantile(0.99, rate(apiserver_admission_webhook_admission_duration_seconds_bucket{cluster="CLUSTER_NAME"}[1m])))

      我们还建议您查看第 50、第 90、第 95 和第 99.9 百分位；您可以通过修改 0.99 值来调整此查询。

    • 外部 webhook 的超时限制约为 10 秒。您可以针对 apiserver_admission_webhook_admission_duration_seconds 指标设置提醒政策，以便在接近 webhook 超时时收到提醒。

    • 您还可以将 name 标签的 apiserver_admission_webhook_admission_duration_seconds 指标分组，以诊断特定网络钩子可能出现的问题。

  • 您正在列出大量对象。预计 LIST 调用的延迟时间会随着给定类型（响应大小）的数量增加而增加。

  • 客户端问题：

    • 客户端可能没有足够的资源来及时接收响应。如需检查，请查看客户端 pod 的 CPU 用量指标。
    • 客户端的网络连接速度较慢。当客户端在手机等设备上运行时，可能会发生这种情况，但客户端在 Compute Engine 网络上运行的可能性不大。
    • 客户端意外退出，但 TCP 连接有几十秒的超时期限。在连接超时之前，服务器的资源会被屏蔽，这可能会增加延迟时间。

如需了解详情，请参阅 Kubernetes 文档中的使用 API 优先级和公平性的良好实践。

流量和错误率

如需衡量 API 服务器上的流量以及成功请求和失败请求的数量，请使用 apiserver_request_total 指标。例如，如需衡量 Kubernetes 控制平面每个实例的 API 服务器流量，请使用以下 PromQL 查询：

sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME"}[1m]))

  • 如需查询失败的请求，请使用以下 PromQL 查询过滤 code 标签以查找 4xx 和 5xx 值：

    sum(rate(apiserver_request_total{code=~"[45].."}[5m]))

  • 如需查询成功的请求，请使用以下 PromQL 查询过滤 code 标签以查找 2xx 值：

    sum(rate(apiserver_request_total{code=~"2.."}[5m]))

  • 如需查询 Kubernetes 控制平面的每个实例的 API 服务器拒绝的请求，请使用以下 PromQL 查询过滤 code 标签以查找值 429 (http.StatusTooManyRequests)：

    sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME", code="429"}[1m]))

饱和度

您可以使用 apiserver_current_inflight_requests 和 apiserver_storage_objects 指标衡量系统中的饱和度。

如果 apiserver_storage_objects 指标的值不断增加，您可能会遇到创建对象但不删除它们的自定义控制器的问题。您可以按 resource 标签过滤或分组指标，以识别不断增加的资源。

根据您的 API 优先级和公平性设置评估 apiserver_current_inflight_requests 指标；这些设置会影响请求的优先级，因此您无法仅根据指标值得出结论。如需了解详情，请参阅 API 优先级和公平性。

调度器指标

本部分提供了调度器指标列表，以及有关解读和使用指标的其他信息。

调度器指标列表

启用调度器指标时，GKE 集群所在项目中的所有下列指标都会导出到 Cloud Monitoring。

此表中的 Cloud Monitoring 指标名称必须以 prometheus.googleapis.com/ 为前缀。表中的条目已省略该前缀。

PromQL 指标名称发布阶段
Cloud Monitoring 指标名称
种类、类型、单位
受监控的资源
所需的 GKE 版本		 说明
标签
scheduler_pending_pods GA
scheduler_pending_pods/gauge
Gauge、Double、1
prometheus_target
1.22.13+ 		待处理 Pod 的数量（按队列类型划分）。“active”表示 activeQ 中的 Pod 数量，“backoff”表示 backoffQ 中的 Pod 数量；“unschedulable”表示 unschedulablePods 中的 Pod 数量。

queue
scheduler_pod_scheduling_duration_seconds 已弃用
scheduler_pod_scheduling_duration_seconds/histogram
Cumulative、Distribution、1
prometheus_target
1.25.1 至 1.29（对于之前的次要版本，则为 1.22.17-gke.3100+、1.23.11+ 和 1.24.5+） 		[在 v. 1.29 中已弃用；在 v. 1.30 中已移除，并由 scheduler_pod_scheduling_sli_duration_seconds 替换]。正在调度的 pod 的 E2e 延迟时间，其中可能包括多次调度尝试。

attempts
scheduler_pod_scheduling_sli_duration_seconds Beta 版
scheduler_pod_scheduling_sli_duration_seconds/histogram
Cumulative、Distribution、1
prometheus_target
1.30+ 		正在调度的 pod 的 E2e 延迟时间，从 pod 进入调度队列时开始，其中可能包括多次调度尝试。

attempts
scheduler_preemption_attempts_total GA
scheduler_preemption_attempts_total/counter
Cumulative、Double、1
prometheus_target
1.22.13+ 		目前为止集群中的总抢占尝试次数
scheduler_preemption_victims GA
scheduler_preemption_victims/histogram
Cumulative、Distribution、1
prometheus_target
1.22.13+ 		所选抢占受害者的数量
scheduler_scheduling_attempt_duration_seconds GA
scheduler_scheduling_attempt_duration_seconds/histogram
Cumulative、Distribution、1
prometheus_target
1.23.6+ 		调度尝试的延迟秒数（调度算法 + 绑定）。

profile
result
scheduler_schedule_attempts_total GA
scheduler_schedule_attempts_total/counter
Cumulative、Double、1
prometheus_target
1.22.13+ 		调度 Pod 的尝试次数（按结果划分）。“unschedulable”表示无法调度 Pod，“error”表示内部调度器问题。

profile
result

以下部分提供了有关 API 服务器指标的更多信息。

scheduler_pending_pods

您可以使用 scheduler_pending_pods 指标来监控调度器上的负载。增加该指标的值可指示资源问题。调度器有三个队列，此指标按队列报告待处理请求的数量。支持以下队列：

  • active 队列
    • 调度器尝试调度的 pod 集：优先级最高的 pod 位于队列开头。
  • backoff 队列
    • 上次调度程序尝试时无法调度该 pod 集合，但下次可以调度。
    • 此队列中的 Pod 必须等待一个退避期（最多 10 秒），此后 Pod 会移回 active 队列以尝试再次调度。如需详细了解 backoff 队列的管理，请参阅实现请求 Kubernetes 问题 75417。

  • unschedulable 集合

    • 调度程序尝试调度但确定无法调度的 pod 集。此队列中的展示位置可能指示了节点的就绪性或兼容性问题，或节点选择器的配置。

      当资源限制条件阻止调度 Pod 时，Pod 将不受退避处理。相反，如果集群已满，则系统无法调度新 pod，并将其置于 unscheduled 队列中。

    • 存在未安排的 Pod 可能表示资源不足，或您具有节点配置问题。在更改集群状态的事件后，Pod 会移至 backoff 或 active 队列。此队列中的 Pod 表示集群中没有发生能够使 Pod 可调度的变化。

    • 亲和性定义了 pod 如何分配给节点的规则。使用亲和性或反亲和性规则可能会导致未调度的 Pod 增加。

    • 某些事件（例如 PVC/Service ADD/UPDATE、pod 终止或新节点注册）将部分或全部未安排的 pod 移动到 backoff 或 active 队列。 如需了解详情，请参阅 Kubernetes 问题 81214。

如需了解详情，请参阅调度器延迟时间和资源问题。

scheduler_scheduling_attempt_duration_seconds

此指标衡量调度器本身内的单次调度尝试的时长，并按结果细分：已调度、无法调度或错误。该时长从调度器提取 Pod 开始，直到调度器找到节点并将 Pod 放置在该节点上，确定 Pod 无法调度或遇到错误。调度时长包括调度过程中的时间以及绑定时间。绑定是调度器将其节点分配传达给 API 服务器的过程。如需了解详情，请参阅调度器延迟时间。

此指标不会捕获 pod 在准入控制或验证上花费的时间。

如需详细了解调度情况，请参阅调度 Pod。

scheduler_schedule_attempts_total

该指标衡量安排尝试的次数；每次尝试调度 pod 都会增加该值。您可以使用此指标来确定调度器是否可用：如果值正在增加，则调度器运行正常。您可以使用 result 标签确定成功与否；pod 为 scheduled 或 unschedulable。

此指标与 scheduler_pending_pods 指标密切相关：当有许多待处理 pod 时，您应该会看到许多安排 pod 的尝试。如需了解详情，请参阅资源问题。

如果调度器没有可调度的 pod，则此指标不会增加（如果您有自定义辅助调度器，则可能会发生这种情况）。

scheduler_preemption_attempts_total 和 scheduler_preemptions_victims

您可以使用抢占指标来确定是否需要添加资源。

您可能有无法调度的较高优先级 pod，因为没有空间。在这种情况下，调度器会抢占节点上一个或多个正在运行的 Pod 以释放资源。scheduler_preemption_attempts_total 指标会跟踪调度器尝试抢占 pod 的次数。

scheduler_preemptions_victims 指标用于计算选择抢占的 Pod。

当 result 标签的值为 unschedulable 时，抢占尝试次数与 scheduler_schedule_attempts_total 指标的值密切相关。这两个值不等效：例如，如果集群有 0 个节点，则没有抢占尝试，但可能存在失败的调度尝试。

如需了解详情，请参阅资源问题。

监控调度器

通过调度器指标，您可以深入了解调度器的性能：

本部分介绍如何使用调度器指标监控调度器。

调度器延迟时间

调度程序的任务是确保您的 pod 运行，因此您想要了解调度程序何时卡住或运行缓慢。

  • 如需验证调度器正在运行并调度 pod，请使用 scheduler_schedule_attempts_total 指标。

  • 如果调度器运行缓慢，请调查以下可能的原因：

    • 待处理 Pod 的数量不断增加。使用 scheduler_pending_pods 指标监控待处理 Pod 的数量。以下 PromQL 查询会返回集群中每个队列的待处理 pod 数量：

      sum by (queue)
(delta(scheduler_pending_pods{cluster="CLUSTER_NAME"}[2m]))

    • 单次调度 pod 的速度较慢。使用 scheduler_scheduling_attempt_duration_seconds 指标监控调度尝试的延迟时间。

      我们建议您至少观察第 50 百分位和第 95 百分位的此指标。以下 PromQL 查询会检索第 95 百分位值，但可以调整：

      sum by (instance) (histogram_quantile(0.95, rate(
scheduler_scheduling_attempt_duration_seconds_bucket{cluster="CLUSTER_NAME"}[5m])))

资源问题

调度器指标还可以帮助您评估是否有足够的资源。如果 scheduler_preemption_attempts_total 指标的值不断增加，请使用以下 PromQL 查询检查 scheduler_preemption_victims 的值：

scheduler_preemption_victims_sum{cluster="CLUSTER_NAME"}

当需要调度优先级更高的 pod 时，抢占尝试次数和抢占受影响者数量都会增加。抢占指标无法告诉您是否调度了触发抢占的高优先级 pod，因此当您看到抢占指标值增大时，还可以监控 scheduler_pending_pods 指标的值。如果待处理 pod 的数量也在增加，则可能没有足够的资源来处理优先级较高的 pod；您可能需要纵向扩容可用资源、使用减少的资源声明创建新的 pod，或更改节点选择器。

  • 如果抢占受影响者的数量没有增加，则表示没有可以移除的剩余低优先级 pod。在这种情况下，请考虑添加更多节点以便分配新的 Pod。

  • 如果抢占受影响者的数量不断增加，则表示有较高优先级的 pod 等待安排，因此调度程序会抢占一些正在运行的 pod。抢占指标无法告诉您高优先级 pod 是否已成功调度。

    如需确定优先级较高的 pod 是否已调度，请查找 scheduler_pending_pods 指标的递减值。如果此指标的值不断增加，您可能需要添加更多节点。

预计当集群中将要安排工作负载时（例如，更新或扩缩等事件期间），scheduler_pending_pods 指标值会出现暂时性峰值。如果您的集群中有足够的资源，则这些峰值是暂时性的。如果待处理 Pod 的数量没有下降，请执行以下操作：

  • 检查节点是否未封锁；封锁节点不接受新的 Pod。
  • 检查以下调度指令，这些指令可能存在配置错误并且可能会使 pod 无法调度：
    • 节点亲和性和选择器。
    • 污点和容忍。
    • Pod 拓扑分布限制。

如果由于资源不足而无法调度 pod，请考虑释放一些现有节点或增加节点数。

控制器管理器指标

启用控制器管理器指标时，GKE 集群所在项目中的所有下列指标都会导出到 Cloud Monitoring。

此表中的 Cloud Monitoring 指标名称必须以 prometheus.googleapis.com/ 为前缀。表中的条目已省略该前缀。

PromQL 指标名称发布阶段
Cloud Monitoring 指标名称
种类、类型、单位
受监控的资源
所需的 GKE 版本		 说明
标签
node_collector_evictions_total GA
node_collector_evictions_total/counter
Cumulative、Double、1
prometheus_target
1.24+ 		自当前 NodeController 实例启动以来发生的节点逐出次数。

zone