Config Sync 已知问题

AutoPilot 上的协调器容器因内存不足而终止

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

临时解决方法：

升级到 1.17.0 版或更高版本。在 Config Sync 1.17.0 版中，调整了默认的 CPU 和内存限制，可帮助避免在大多数应用场景中出现内存不足错误。

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

协调器无法调度

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

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

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

临时解决方法：

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

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

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

临时解决方法：

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

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

临时解决方法：

升级到 1.17.2 版或更高版本。

指标基数和转换错误率较高

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

临时解决方法：

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

导出失败。权限遭拒

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

临时解决方法：

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

otel-collector 因自定义配置崩溃

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

临时解决方法：

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

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 注解放弃并重新获取该资源。

定期无法评估来源链接

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

临时解决方法：

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

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

当 Cloud Source Repositories 的身份验证令牌到期时，Config Sync 可能会定期出现错误。导致此问题的原因是令牌刷新一直等到过期再刷新令牌。

临时解决方法：

将 Config Sync 更新到 1.18.0 版或更高版本。在这些版本中，令牌会在令牌过期后的五分钟内在第一个请求时刷新。这样可以防止出现无效身份验证凭据错误，除非凭据确实无效。

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

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

临时解决方法：

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

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

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

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

临时解决方法：

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.branch) 设置的值如何，您都可以将 Git 修订版本 (spec.git.revision) 设置为最新的提交 SHA。如需详细了解 Git 配置，请参阅 Git 代码库的配置。