协调策略

借助声明式配置，您可以定义系统期望的状态。然后，系统会持续工作以尽可能保持接近此状态。如需了解详情，请参阅使用配置文件以声明方式管理 Kubernetes 对象。

借助 Config Connector，您可以按任意顺序创建和更新资源，而不管依赖关系如何。GKE 会将您声明的配置向与所需状态最终一致的方向移动。

例如，如果您在相应的 PubSubTopic 之前创建 PubSubSubscription，则 Config Connector 会等到主题创建之后再创建关联的订阅。

Config Connector 安装保持不一致的时长取决于它管理的资源的数量和类型。对 GKE 集群的更改通常会在几秒钟内执行。不过，创建Google Cloud 资源所需的时间可能会因资源类型而异。例如，创建单个 PubSubTopic 只需几秒钟。 Google Cloud资源在创建之前不会达到一致性。例如，在创建 SQLInstance 和 SQLDatabase 时，系统在创建数据库的几分钟内是不一致的。

GKE 和 Config Connector 会在每次更新后或在抖动期后（平均值基于预配置的默认间隔）协调每个资源。您可以在每个资源的参考页面中找到“Config Connector 默认平均协调间隔（以秒为单位）”中的默认间隔。如需查看每种资源的链接，请参阅资源概览。如果协调过程中出现错误，Config Connector 会使用指数退避算法进行重试，其中最大退避时间为 2 分钟。对于由直接控制器管理的资源，您可以使用 cnrm.cloud.google.com/backoff-max-delay-in-seconds 注解来配置此上限。您可以在给定资源的事件中查看任何错误。

配置协调间隔

从 Config Connector 1.102 开始，您可以使用 cnrm.cloud.google.com/reconcile-interval-in-seconds 注解为 Config Connector 管理的资源配置平均协调间隔。注解的值会覆盖资源参考页面中“Config Connector Default Average Reconcile Interval In Seconds”的默认值。注解的值应为非负整数，表示以秒为单位的时间。如果该值设置为 0，则 Config Connector 在资源达到 UpToDate 状态后会停止启动协调。此注解用于控制资源达到 UpToDate 状态后的定期协调。当协调失败时，该注解不会影响重试间隔。如需了解详情，请参阅为协调错误配置指数退避算法。

例如，如果您希望 Config Connector 降低资源协调频率，以避免遇到底层 Google Cloud API 配额问题，可以将平均协调间隔值设置为 1 小时。

cnrm.cloud.google.com/reconcile-interval-in-seconds: "3600"

如果您希望 Config Connector 更频繁地协调资源，以便更快地纠正偏差，可以将注解设置为较小的值。

您可以使用以下脚本为共享同一组版本种类 (GVK) 的特定类型的所有资源添加注解：

#!/bin/bash

KIND=RESOURCE_KIND
NAMESPACE=RESOURCE_NAMESPACE
ANNOTATION_KEY="cnrm.cloud.google.com/reconcile-interval-in-seconds"
ANNOTATION_VALUE=RECONCILE_INTERVAL

kubectl annotate --overwrite --all ${KIND} ${ANNOTATION_KEY}=${ANNOTATION_VALUE} -n ${NAMESPACE}
echo "Annotation added to all ${KIND} RESOURCE"

替换以下内容：

  • RESOURCE_KIND：要添加注解的资源种类。
  • RESOURCE_NAMESPACE：包含要添加注解的资源的命名空间。
  • RECONCILE_INTERVAL：协调间隔时间（以秒为单位）。

您可以将协调间隔设置为 0，以停用资源的偏移校正，但这不会停用资源执行。如果您对资源 Spec 进行更改，该资源将再次进行协调。

将对账间隔时间设置为 0 是不可逆的。这意味着，即使将该值改回非零数字，Config Connector 也不会再次协调该资源。

如果您想还原 0 协调间隔，可以采用以下方法：

  • 使用协调间隔值修改资源规范，以启用新的协调。
  • 通过设置注解 cnrm.cloud.google.com/deletion-policy: "abandon" 放弃该资源，然后重新创建该资源，并将协调间隔值设置为非 0 值。

为对账错误配置指数退避算法

当资源无法协调时，Config Connector 会使用指数退避算法重试协调。延迟时间从 250 毫秒开始，每次尝试失败后都会翻倍（例如，500 毫秒、1 秒、2 秒），默认上限为 2 分钟。

cnrm.cloud.google.com/reconcile-interval-in-seconds 注解用于控制资源达到 UpToDate 状态后的定期偏移校正。在 Config Connector 1.160.0 版及更高版本中，您可以使用 cnrm.cloud.google.com/backoff-max-delay-in-seconds 注解来控制协调失败时的重试行为。将注解设置为以下值之一：

  • 正整数（"1" 或更大值）：设置重试之间的最大延迟时间（以秒为单位）。例如，"600" 将重试间隔上限设为 10 分钟，"3600" 将重试间隔上限设为 1 小时。
  • "0": 在协调失败后停止自动重试。资源会一直处于失败状态，直到有更改触发协调，例如 spec、metadata.labels、metadata.annotations、被引用资源或 Secret 发生更新。

例如，如需将重试间隔上限设为 30 分钟，并减少失败资源的 Google Cloud API 配额消耗，请添加以下注解：

metadata:
  annotations:
    cnrm.cloud.google.com/backoff-max-delay-in-seconds: "1800"

如需在您更新资源之前停止在协调错误时自动重试，请添加以下注解：

metadata:
  annotations:
    cnrm.cloud.google.com/backoff-max-delay-in-seconds: "0"

可变但无法读取的字段仅在更改后生效

某些 API 会公开不可读但可变动的字段（例如 SQL 用户的密码）。由于无法查看这些字段是否已被修改，因此只有在修改自定义资源时，系统才会更新可变但不可读的字段。

修改不可变字段时，系统不会重新创建资源

资源中的某些字段是不可变的，如不删除然后重新创建目标资源，则无法进行协调。

在这些情况下，Config Connector 会为资源发出“UpdatedFailed”Kubernetes 事件，而不是执行此重新创建操作。然后，您必须删除并重新创建该资源。

事件示例

Warning  UpdateFailed  37m (x643 over 15d)    computeinstance-controller  Update call failed: the desired mutation for the following field(s) is invalid: [bootDisk.0.InitializeParams.0.Image networkInterface.0.NetworkIp]