排查 GKE on VMware 可观测性问题

本文档可帮助您排查 GKE on VMware 中的可观测性问题。如果您遇到任何这些问题，请查看建议的修复和解决方法。

如果您需要其他帮助，请与 Google 支持团队联系。

不收集 Cloud Audit Logs 日志

在集群配置的 cloudAuditLogging 部分中检查 Cloud Audit Logs 是否已启用。验证项目 ID、位置和服务账号密钥配置正确。项目 ID 必须与 gkeConnect 下的项目 ID 相同。

如果启用了 Cloud Audit Logs，则权限是不收集日志的最常见原因。在这种情况下，Cloud Audit Logs 代理容器中会显示权限遭拒的错误消息。

Cloud Audit Logs 代理容器以以下方式运行：

  • 管理员集群或独立集群中的静态 Pod。
  • kube-apiserver Pod 中的边车容器。

如果您看到权限错误，请遵循排查和解决权限问题的步骤。

不会收集 kube-state-metrics 指标

kube-state-metrics (KSM) 作为集群中的单个副本 Deployment 运行，并为集群中的几乎所有资源生成指标。当 KSM 和 gke-metrics-agent 在同一节点上运行时，所有节点上的指标代理发生服务中断的风险会提高。

KSM 指标的名称遵循 kube_<ResourceKind> 格式，例如 kube_pod_container_info。以 kube_onpremusercluster_ 开头的指标来自本地集群控制器，而不是 KSM。

如果缺少 KSM 指标，请查看以下问题排查步骤：

  • 在 Cloud Monitoring 中，使用 kubernetes.io/anthos/container/... 等摘要 API 指标检查 KSM 的 CPU、内存和重启数量。这是具有 KSM 的单独流水线。确认 KSM Pod 不受资源不足的限制。
    • 如果这些摘要 API 指标不适用于 KSM，则同一节点上的 gke-metrics-agent 可能也存在相同的问题。
  • 在集群中，检查 KSM Pod 以及同一节点上具有 KSM 的 gke-metrics-agent Pod 的状态和日志。

kube-state-metrics 崩溃循环

症状

Cloud Monitoring 不提供 kube-state-metrics (KSM) 的指标。

原因

大型集群或具有大量资源的集群更有可能发生这种情况。KSM 作为单个副本 Deployment 运行，并列出集群中几乎所有资源，例如 Pod、Deployment、DaemonSet、ConfigMap、Secret 和 PersistentVolume。并为每个资源对象生成指标。如果任何资源具有许多对象（例如具有超过 10,000 个 Pod 的集群），则 KSM 可能会耗尽内存。

受影响的版本

在任何版本的 GKE on VMware 中都可能会遇到此问题。

在最近几个 GKE on VMware 版本中，默认的 CPU 和内存上限有所提高，因此这些资源问题应该不太常见。

修复和解决方法

如需检查您的问题是否是由内存不足引起的，请遵循以下步骤：

  • 使用 kubectl describe pod 或 kubectl get pod -o yaml，并查看错误状态消息。
  • 在重启之前，检查 KSM 的内存消耗和利用率指标，并确认其是否达到限制。

如果确认问题在于内存不足，请使用以下任一解决方案：

  • 提高 KSM 的内存请求和限制。

    如需调整 KSM 的 CPU 和内存，请执行以下步骤：

    1. 对于 GKE on VMware 版本 1.9 及更早版本、1.10.6 或更低版本、1.11.2 及更低版本，以及 1.12.1 或更低版本：

      1. 没有适合的长期解决方案。如果您修改 KSM 相关资源，monitoring-operator 会自动还原更改。

      2. 您可以将 monitoring-operator 缩减到 0 个副本，然后修改 KSM 部署以调整其资源限制。但是，集群将不会收到使用 monitoring-operator 的新补丁版本提供的漏洞补丁。

        请记得在集群升级到包含修复的更高版本后恢复 monitoring-operator 的副本数量。

    2. 对于 GKE on VMware 版本 1.10.7 或更高版本、1.11.3 或更高版本、1.12.2 或更高版本以及 1.13 及更高版本，请使用以下定义在 kube-system 命名空间（gke-managed-metrics-server 适用于 1.13 或更高版本）中创建一个名为 kube-state-metrics-resizer-config 的 ConfigMap。根据需要调整 CPU 和内存数量：

      apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-state-metrics-resizer-config
  namespace: kube-system
data:
  NannyConfiguration: |-
  apiVersion: nannyconfig/v1alpha1
  kind: NannyConfiguration
  baseCPU: 200m
  baseMemory: 1Gi
  cpuPerNode: 3m
  memoryPerNode: 20Mi

      1. 创建 ConfigMap 后，请使用以下命令删除 KSM Pod，以重启 KSM Deployment：

          kubectl -n kube-system rollout restart deployment kube-state-metrics
  ```

  • 减少 KSM 中的指标数量。

    对于 GKE on VMware 1.13，默认情况下，KSM 仅公开少数几个指标，称为“核心指标”。此行为意味着资源用量低于以前的版本，但您可以遵循相同的过程进一步减少 KSM 指标的数量。

    对于低于 1.13 的 GKE on VMware 版本，KSM 会使用默认标志。此配置公开了大量指标。

gke-metrics-agent 崩溃循环

如果 gke-metrics-agent 仅在存在 kube-state-metrics 的节点上遇到内存不足问题，则原因在于大量 kube-state-metrics 指标。如需缓解此问题，请缩减 stackdriver-operator 并修改 KSM 以公开一小部分所需的指标，如上一部分所述。请记得在集群升级到 GKE on VMware 1.13 后对 stackdriver-operator 进行纵向扩容，其中 KSM 默认公开较少的核心指标。

对于与内存不足事件无关的问题，请检查 gke-metric-agent 的 Pod 日志。您可以通过向 Stackdriver 自定义资源添加 resourceAttrOverride 字段来调整所有 gke-metrics-agent Pod 的 CPU 和内存。

stackdriver-metadata-agent 崩溃循环

症状

在 Cloud Monitoring 中过滤指标时，没有可用的系统元数据标签。

原因

stackdriver-metadata-agent 崩溃循环的最常见原因是内存不足事件。此事件与 kube-state-metrics 类似。尽管 stackdriver-metadata-agent 未列出所有资源，但它仍会列出相关资源类型的所有对象，如 Pod、Deployment 和 NetworkPolicy。代理作为单个副本 Deployment 运行，如果对象数量过大，这会增加内存不足事件的风险。

受影响的版本

在任何版本的 GKE on VMware 中都可能会遇到此问题。

在最近几个 GKE on VMware 版本中，默认的 CPU 和内存上限有所提高，因此这些资源问题应该不太常见。

修复和解决方法

如需检查您的问题是否是由内存不足引起的，请遵循以下步骤：

  • 使用 kubectl describe pod 或 kubectl get pod -o yaml，并查看错误状态消息。
  • 在重启之前，检查 stackdriver-metadata-agent 的内存消耗和利用率指标，并确认其是否达到限制。
如果您确认内存不足导致了问题，请提高 Stackdriver 自定义资源 resourceAttrOverride 字段中的内存限制。

metrics-server 崩溃循环

症状

Pod 横向自动扩缩器和 kubectl top 无法在集群中运行。

原因和受影响的版本

此问题不常见，但会因为大型集群或 Pod 密度较高的集群内存不足错误而出现。

在任何版本的 GKE on VMware 中都可能会遇到此问题。

修复和解决方法

提高指标服务器资源限制。在 GKE on VMware 1.13 版及更高版本中，metrics-server 的命名空间及其配置已从 kube-system 移至 gke-managed-metrics-server。

后续步骤

如果您需要其他帮助，请与 Google 支持团队联系。