Config Sync 已知问题

本页面列出了受支持的 Config Sync 版本的已知问题。如需按产品版本或问题类别过滤已知问题，请从以下下拉菜单中选择过滤条件。

选择您的 Config Sync 版本：

选择您的问题类别：

或者，过滤已知问题：

类别 已识别的版本 已修复的版本 问题和临时解决方法
组件运行状况 1.15.0 1.17.0

AutoPilot 上的协调器容器 OOMKilled

在 Autopilot 集群上，Config Sync 组件容器针对 CPU 和内存设置了资源限制。在负载状态下，这些容器可能会因使用的内存过多而被 kubelet 或内核终止。

临时解决方法：

请升级到 1.17.0 或更高版本。在 Config Sync 1.17.0 版中，调整了默认的 CPU 和内存限制，以避免在大多数情况下出现内存不足错误。

如果无法升级，请使用资源替换指定更高的内存限制。

组件运行状况 1.15.0

协调器无法调度

Config Sync 协调器需要不同数量的资源，具体取决于 RootSync 或 RepoSync 的配置。某些配置需要的资源比其他配置更多。

如果协调器不可调度，则可能是因为请求的资源超过节点上可用的资源。

如果您使用的是标准模式 GKE 集群，则协调器资源请求设置会非常低。选择此设置是为了尝试允许调度，即使这样做会导致节流并降低性能，以使 Config Sync 适用于小型集群和小型节点。但是，在 GKE Autopilotcluster 上，协调器请求被设置得更高，以更真实地表示同步时的使用情况。

临时解决方法：

启用了节点自动预配功能的 GKE Autopilot 或 GKE Standard 应该能够看到请求的资源数量，并创建大小合适的节点以允许调度。但是，如果您要手动配置节点或节点实例大小，则可能需要调整这些设置，以适应协调器 Pod 资源要求。
KNV 错误 1.15.0 Kubernetes 1.27 版

即使成功应用配置，也会发生 KNV1067 错误

由于 OpenAPI v2 的问题，即使您已成功应用配置，也可能看到 KNV1067 错误。

临时解决方法：

如果您的集群运行的 Kubernetes 版本低于 1.27，即使您使用的是默认 TCP，也请确保在 spec: containers: ports: 下明确设置 protocol 字段。
KNV 错误 1.15.0 1.16.0

Config Sync 无法与 KNV2002 错误保持一致

如果 Config Sync 无法与 KNV2002 error 协调，则可能是由于 client-go 问题引起的已知问题。该问题会导致 external.metrics.k8s.io/v1beta1 API 组中的资源列表为空，并显示来自 RootSync 或 RepoSync 对象的错误消息，或者来自协调器日志：

KNV2002: API discovery failed: APIServer error: unable to retrieve the complete list of server APIs: external.metrics.k8s.io/v1beta1: received empty response for:
external.metrics.k8s.io/v1beta1

临时解决方法：

如需解决此问题，请将 GKE 集群升级到 GKE 1.28 或更高版本或将 Config Sync 升级到 1.16.0 或更高版本。这两个版本均包含对 client-go 问题的修复。
指标 1.15.0 1.17.2

导出失败：无法识别的指标标签

在 1.15.0 版中，Config Sync 向许多指标添加了 type 和 commit 标签。这些标签增加了指标基数，从而增加了导出的指标数量。此外，还添加了属性处理功能，以便在导出到 Cloud Monarch 时过滤这些标签，但此过滤配置错误，导致 otel-collector 日志中出现转换错误。

临时解决方法：

请升级到 1.17.2 或更高版本。
指标 1.15.0 1.16.1

高指标基数和转换错误

在 1.15.0 版中，Config Sync 向许多指标添加了 type 和 commit 标签。这些标签增加了指标基数，从而增加了导出的指标数量。此外，还添加了属性处理功能，以便在导出到 Cloud Monarch 时过滤这些标签，但此过滤配置错误，导致 otel-collector 日志中出现转换错误。

临时解决方法：

请升级到 1.16.1 版或更高版本。在 1.16.1 版中，移除了类型字段，修复了过滤功能，并且还从 Cloud Monitoring 中移除了提交字段。这修复了这些错误并减少了指标的基数。
指标 1.15.0

导出失败。权限遭拒

默认情况下，当 recontiler-manager 检测到应用默认凭据时，otel-collector 会配置为将指标导出到 Prometheus、Cloud Monitoring 和 Monarch。

临时解决方法：

如果您尚未配置 Cloud Monitoring 或停用 Cloud Monitoring 和 Cloud Monarch，则 otel-collector 会记录错误。
指标 1.15.0

使用自定义配置，otel-collector 会崩溃

如果您尝试修改或删除其中一个默认 ConfigMap（otel-collector 或 otel-collector-google-cloud），则 otel-collector 可能会因无法加载所需的 ConfigMap 而出现错误或崩溃。

临时解决方法：

如需自定义指标导出配置，请在 config-management-monitoring 命名空间中创建一个名为 otel-collector-custom 的 ConfigMap。
Nomos CLI 1.15.0 1.17.2

nomos status 和 nomos bugreport 在 Pod 中不起作用

在 nomos 1.17.2 版之前，nomos bugreport 和 nomos status 只有在 Kubernetes Pod 内运行时才能连接到本地集群。在 nomos 版本 1.17.2 中，授权方法已更改，以使其更像是 kubectl。由于此更改，默认情况下，本地集群是目标集群。您可以通过指定 KUBECONFIG 环境变量来替换配置。

临时解决方法：

升级到 nomos 版本 1.17.2。
修复

Config Sync 与自己战斗

Config Sync 可能看起来正在进行控制器争夺。。如果您在 Git 代码库中为资源的可选字段设置默认值，就会出现此问题。例如，为 RoleBinding 正文设置 apiGroup: "" 会触发此事件，因为 apiGroup 字段是可选字段且空字符串是默认值。字符串、布尔值和整数字段的默认值分别为 ""、false 和 0。

临时解决方法：

从资源声明中移除该字段。
修复

Config Sync 与 Config Connector 资源争夺

Config Sync 可能似乎在与 Config Connector 争夺某项资源（例如 StorageBucket）。 如果您未在可信来源中设置资源 spec.lifecycleRule.condition.withState 的可选字段的值，就会出现此问题。

临时解决方法：

您可以通过在资源声明中添加 withState=ANY 字段来避免此问题。或者，您也可以使用 cnrm.cloud.google.com/state-into-spec: absent 注解放弃并重新获取资源。

数据来源 1.16.1 1.16.2

定期无法评估来源链接

协调器在定期无法评估来源链接时启动，可能会导致 Config Sync 出现问题。出现此问题是因为 git-sync 尚未克隆源代码库。

临时解决方法：

将 Config Sync 更新到 1.16.2 或更高版本。在这些版本中，这是暂时性错误，因此系统会将其记录下来，但不会将其报告为错误。
数据来源 1.15.0 1.18.0

Cloud Source Repositories 的身份验证凭据定期失效

当 Cloud Source Repositories 的身份验证令牌到期时，Config Sync 可能会定期出错。此问题是由一直等到到期再刷新令牌的令牌刷新引起的。

临时解决方法：

将 Config Sync 更新到 1.18.0 或更高版本。在这些版本中，令牌在首次请求时会在令牌过期后的五分钟内刷新。这可以防止出现身份验证凭据无效的错误，除非凭据实际上无效。
数据来源 1.15.0 1.17.0

同步代码库时出错：已超出上下文截止时间

在 1.17.0 之前的版本中，Config Sync 默认签出了完整的 Git 代码库历史记录。这可能会导致包含多项提交的大型代码库的提取请求超时。

临时解决方法：

请升级到 1.17.0 或更高版本。在 1.17.0 版及更高版本中，Git 提取使用 --depth=1 执行，该方法仅提取最新提交。这样可以加快源代码提取速度，避免大多数超时问题，并减少 Git 服务器负载。

如果您在升级后仍然遇到此问题，则可能是因为您的可信来源有许多文件，您的 Git 服务器响应缓慢，或者存在一些其他网络问题。
同步 1.15.0

审核日志中大量无效 PATCH 请求

Config Sync 修复程序使用试运行来检测偏移。即使 PATCH 未持久保留，这也可能导致 PATCH 请求显示在审核日志中，因为审核日志不区分试运行和正常请求。

临时解决方法：

由于审核日志无法区分试运行和非试运行请求，因此您可以忽略 PATCH 请求。
同步 1.17.0

Config Sync 无法从分支拉取最新提交

在 Config Sync 1.17.0 版及更高版本中，您可能会遇到以下问题：如果多个遥控器引用了同一分支，并且它们不同步，则 Config Sync 无法从特定分支的 HEAD 拉取最新提交。例如，远程代码库 origin 的 main 分支可能在远程代码库 upstream 中的同一分支之前，但 Config Sync 仅从最后一行中提取提交 SHA，这可能不是最新的提交。

此问题可能如下所示：

git ls-remote -q [GIT_REPOSITORY_URL] main  main^{}
244999b795d4a7890f237ef3c8035d68ad56515d    refs/heads/main               # the latest commit
be2c0aec052e300028d9c6d919787624290505b6    refs/remotes/upstream/main    # the commit Config Sync pulls from

临时解决方法：

如需缓解此问题，您可以将 Git 修订版本 (spec.git.revision) 设置为最新的提交 SHA，而不考虑为 Git 分支 (spec.git.branch) 设置的值。如需详细了解 Git 配置，请参阅 Git 代码库的配置。

返回页首

后续步骤