排查 Google Distributed Cloud 可观测性问题

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

如果您需要其他帮助，请与 Cloud Customer Care 联系。

不收集 Cloud Audit Logs 日志

Cloud Audit Logs 默认启用，除非在集群配置的 clusterOperations 部分下设置了 disableCloudAuditLogging 标志。

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

Cloud Audit Logs 代理容器在所有 Google Distributed Cloud 集群中作为 DaemonSet 运行。

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

另一个可能的原因是您的项目可能已达到支持的服务账号上限，请参阅Cloud Audit Logs 服务账号泄露。

不会收集 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 可能会耗尽内存。

受影响的版本

任何版本的 Google Distributed Cloud 都可能遇到此问题。

在最近的几个 Google Distributed Cloud 版本中，默认 CPU 和内存限制已提高，因此这些资源问题应该不常见。

修复和解决方法

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

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

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

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

  注意：即使 KSM 在资源增加后变得稳定，同一节点上的 gke-metrics-agent 也可能会成为从 KSM 爬取大量指标的瓶颈。

  • 对于 Google Distributed Cloud 1.16.0 版或更高版本，Google Cloud Observability 会管理 KSM。如需更新 KSM，请参阅替换 Stackdriver 组件的默认 CPU 及内存请求和限制。

  • 对于 1.16.0 之前的版本，如需调整 KSM 的 CPU 和内存，请对 kube-state-metrics 使用 Stackdriver 自定义资源的 resourceOverride。

• 减少 KSM 中的指标数量。

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

  对于比 1.13 低的 Google Distributed Cloud 版本，KSM 使用默认标志。此配置公开了大量指标。

gke-metrics-agent 崩溃循环

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

对于与内存不足事件无关的问题，请检查 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 运行，如果对象数量过大，这会增加内存不足事件的风险。

受影响的版本

任何版本的 Google Distributed Cloud 都可能遇到此问题。

在最近的几个 Google Distributed Cloud 版本中，默认 CPU 和内存限制已提高，因此这些资源问题应该不常见。

修复和解决方法

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

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

如果您确认内存不足导致了问题，请提高 Stackdriver 自定义资源的 resourceAttrOverride 字段中的内存限制。

metrics-server 崩溃循环

症状

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

原因和受影响的版本

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

任何版本的 Google Distributed Cloud 都可能遇到此问题。

修复和解决方法

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

对于 Google Distributed Cloud，如果集群更新或升级，则 nanny 配置的修改将会还原。您将需要重新应用配置更改。如需避免此限制，请缩减 metrics-server-operator 并手动更改 metrics-server Pod。

删除 Cloud Audit Logs 服务账号时，并非所有资源都会被移除

删除用于 Cloud Audit Logs 的服务账号后，并非所有 Google Cloud资源都会被删除。如果您定期删除并重新创建用于 Cloud Audit Logs 的服务账号，审核日志记录最终会开始失败。

症状

权限遭拒的错误消息会显示在 Cloud Audit Logs 代理容器中。

如需确认审核日志失败是由此问题导致的，请运行以下命令：

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/global/features/cloudauditlogging

将 PROJECT_NUMBER 替换为您的项目编号。

响应会返回项目中用于 Cloud Audit Logs 的所有服务账号，包括已删除的服务账号。

原因和受影响的版本

删除用于 Cloud Audit Logs 的服务账号后，并非所有 Google Cloud 资源都会被移除，最终项目的服务账号数量会达到 1000 个的限制。

任何版本的 Google Distributed Cloud 都可能遇到此问题。

修复和解决方法

1. 创建一个环境变量，其中包含要保留的所有服务账号的逗号分隔列表。使用英文单引号括起每个服务账号电子邮件地址，并使用英文双引号括起整个列表。您可以将以下内容作为起点：

   SERVICE_ACCOUNT_EMAILS="'SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com'"
   

   替换以下内容：

   • PROJECT_ID：您的项目 ID。
   • SERVICE_ACCOUNT_NAME：服务账号名称。

   完成后的列表应类似于以下示例：

   "'[e-mail]','[e-mail]','[e-mail]'"
   

2. 运行以下命令，从项目中移除 Cloud Audit Logs 功能：

   curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Content-Type: application/json" \
   https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION /features/cloudauditlogging
   

   替换以下内容：

   • PROJECT_NUMBER：项目编号。
   • FLEET_REGION：集群的舰队成员资格位置。这可以是特定区域，例如 us-central1 或 global。您可以运行 gcloud container fleet memberships list 命令来获取成员资格位置。

   此命令会完全删除所有服务账号。

3. 仅使用您要保留的服务账号重新创建 Cloud Audit Logs 功能：

   curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
       -H "Content-Type: application/json" \
       https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION/features?feature_id=cloudauditlogging \
       -d '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":[$SERVICE_ACCOUNT_EMAILS]}}}'
   

后续步骤

如果您需要其他帮助，请与 Cloud Customer Care 联系。