Config Sync 已知问题

本页面列出了受支持的 Config Sync 版本的已知问题。

此处列出的许多问题已得到解决。已修复的版本列指出引入了修复的版本。如需收到此修复，请升级到列出的版本或更高版本。

如需按产品版本或问题类别过滤已知问题，请从以下下拉菜单中选择过滤条件。

选择 Config Sync 版本：

选择问题类别：

或者，过滤已知问题：

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

已修复：AutoPilot 上的协调器容器因内存不足而终止

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

临时解决方法：

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

在 1.17.0 版中，调整了默认的 CPU 和内存限制，可帮助避免在大多数应用场景中出现内存不足错误。
组件健康状况 1.15.0

协调器无法调度

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

如果协调器无法调度，则可能是因为请求的资源多于节点上的可用资源。

如果您使用的是标准模式 GKE 集群，则协调器资源请求设置得非常低。选择此设置是为了允许进行调度（即使这会导致节流和性能下降），以便 Config Sync 可在小型集群和小型节点上运行。但是，在 GKE Autopilot 集群上，协调器请求设置得较高，以更实际地表示同步时的使用情况。

临时解决方法：

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

已修复：即使成功应用配置，也出现 KNV1067 错误。

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

临时解决方法：

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

KNV 错误 1.15.0 1.16.0，Kubernetes 1.28 版

已修复：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
指标 1.15.0 1.17.2

已修复：导出失败：指标标签无法识别

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

已修复：高指标基数和转换错误

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

在 1.16.1 版中，移除了类型字段，修复了过滤功能，并且还从 Cloud Monitoring 中过滤了提交字段。 这修复了错误并降低了指标的基数。
指标 1.15.0

导出失败。权限遭拒

默认情况下，当 reconciler-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 环境变量来替换配置。
修复

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.17.3

GitHub 的 Git SSH 身份验证失败

git-sync v4.2.1 存在一个 bug，该 bug 在使用 SSH 时会从代码库网址中移除用户名，导致连接到 GitHub 时身份验证失败，这要求用户为 git。

git 返回的错误消息为：git-sync@github.com: Permission denied (publickey).\r\nfatal: Could not read from remote repository.

临时解决方法：

降级到 1.17.2 版或使用其他身份验证方法。
可信来源 1.16.1 1.16.2

已修复：定期无法评估来源链接

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

在 1.16.2 版及更高版本中，这是一个暂时性错误，因此系统会记录该错误，但不会报告为错误。
可信来源 1.15.0 1.18.0

已修复：Cloud Source Repositories 的身份验证凭据定期无效

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

在 1.18.0 版及更高版本中，令牌会在令牌过期后的五分钟内在第一个请求时刷新。这可以防止出现无效的身份验证凭据错误，除非凭据实际上无效。
可信来源 1.15.0 1.17.0

已修复：同步代码库时出错：已超出上下文截止期限

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

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

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

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

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

临时解决方法：

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

已修复：Config Sync 无法从分支中拉取最新提交

在 Config Sync 1.17.0、1.17.1 和 1.17.2 版中，您可能会遇到以下问题：当多个远程代码库中引用了同一分支且不同步时，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

在 1.17.3 及更高版本中，系统会使用不同的提取机制更新 git-sync 依赖项。

如果您无法升级，则可以将 Git 修订版本 (spec.git.revision) 设置为最新的提交 SHA，而不考虑为 Git 分支 (spec.git.branch) 设置的值。如需详细了解 Git 配置，请参阅 Git 代码库的配置。
私有注册表

Config Sync 不使用私有注册表进行协调器 Deployment

如果配置了私有注册表，则 Config Sync 应替换所有 Deployment 的映像。但是，Config Sync 不会替换协调器 Deployment 中映像的映像注册表。

临时解决方法：

此问题的解决方法是配置 containerd 中的映像注册表镜像。

返回页首

后续步骤