配置 Config Controller 以实现高可用性

本页面介绍如何在多个 Google Cloud 区域中运行高可用性服务或管理资源时充分利用 Config Controller。

本页面适用于管理底层技术基础架构生命周期以及规划容量和基础架构需求的管理员、架构师和运维人员。如需详细了解我们在 Google Cloud 内容中提及的常见角色和示例任务，请参阅常见的 GKE Enterprise 用户角色和任务。

Config Controller 在单个区域中运行，因此它可以容忍可用区的故障，但如果整个区域发生故障，则 Config Controller 会失去可用性。有两种不同的策略可以处理区域性故障，您的选择取决于区域性故障时要执行的操作：

了解故障场景

Config Controller 使用区域性 GKE 集群。虽然区域级集群可以承受某一区域内单个可用区发生故障，但如果该区域内的多个可用区发生故障，则集群会变得不可用。

如果 Config Controller 实例失败，现有的 Google Cloud 资源会保持当前状态。但是，即使您的应用仍在运行，也无法在 Config Controller 不可用时更改其配置。这适用于同一区域中的资源，以及您通过不可用区域中的 Config Controller 管理的其他区域中的资源。

由于您无法重新配置同一区域中的资源，因此，如果区域性故障确实影响了 Config Controller 区域中的现有 Google Cloud 资源，则无法修复这些资源。

由于您也无法在其他区域中重新配置资源，因此一个区域中的故障现在会影响您在另一个区域中进行更改的能力。

其他故障场景也是可行的。 例如，如果将 Config Sync 配置为从外部 Git 提供商拉取，则应考虑该 Git 提供商的故障模式。您可能无法更改配置，因为您无法将更改推送到该 Git 提供商。或者，如果 Config Sync 无法从 Git 读取，则任何 Git 更改都不会应用于集群，因此 Config Connector 不会应用这些更改。但是，区域性故障通常是最重要的故障场景，因为其他故障场景通常与 Config Controller 故障无关。

使用单个集群来提高区域级可用性

在许多情况下，如果区域发生故障，您不会执行任何重新配置操作。在这种情况下，您可以选择接受区域性故障导致配置控制层面不可用。

例如，如果您仅在单个区域执行操作，则在该区域发生故障时，您可能无法执行任何有用的重新配置。同样，如果您在单个区域中具有单点故障数据库，则在该区域恢复之前，您可能无法恢复该数据库。对于不需要绝对最高可用性的应用，这种情况可在费用和复杂性之间进行合理的权衡。

在同一区域中查找 Config Controller 实例可为您提供共享操作：只要主要区域可用，Config Controller 即可用。将 Config Controller 实例放在不同地区也是一个不错的选择。但是，您现在必须考虑两个区域可能发生的故障，以免配置控制层面中因主要区域故障而发生关联故障。

或者，如果您使用的是多地区冗余配置，您的系统可能会自动远离故障地区。 同样，如果某个地区发生故障，您可能也不想重新配置。 在这种情况下，您可以选择单个 Config Controller 实例。

手动故障切换到第二个 Config Controller 实例

如果某个区域出现故障，您可能需要进行一些重新配置，以便修复故障。即使 Config Controller 实例位于故障区域中，您也可能需要继续配置其他区域中的资源。在这种情况下，我们建议在第二个区域中使用第二个 Config Controller 实例。

虽然不建议这样做，但两个 Config Controller 实例可以使用相同的配置运行。 两个实例都会从同一 Git 代码库读取数据，并将相同的更改应用于 Google Cloud。但是，很多边缘用例会使此配置变得不可靠。这两个 Config Controller 实例会观察 Git 代码库的时间可能会稍有不同；它们可能尝试应用略有差异的 Google Cloud 配置版本。如果有多个活跃写入者写入 Google Cloud，则更有可能遇到配额或速率限制。少数 Config Connector 资源也不是幂等的，并且需要特别注意本部分其余部分所述事项。因此，我们建议不要有两个 Config Controller 集群都进行主动协调。

相反，如果运行 Config Controller 的区域发生故障，则您可以在第二个区域中运行另一个 Config Controller。新的 Config Controller 实例应与第一个实例具有相同的配置，从同一 Git 代码库读取数据。 准备脚本以启动和配置 Config Controller 实例在这种情况下可能很有用。创建新的 Config Controller 实例时，Config Sync 会读取所需状态并将其从 Git 应用于 Kubernetes；Config Connector 会将所需状态同步到 Google Cloud。

在这种情况下，请注意两个事项：

  • 如果第一个 Config Controller 集群仍在运行，或者在第一个区域恢复时开始运行，则可能会尝试将旧状态应用于 Google Cloud。如果您可以在启动第二个 Config Controller 集群之前停止第一个区域中的 Config Controller 集群，则可以避免这种潜在的冲突。

  • 并非所有 Config Connector 资源都可以从 Git 无缝重新应用。如需查看需要特别注意的资源列表，请参阅存在流量获取限制的资源。请特别注意 Folder 资源，并避免使用 IAMServiceAccountKey 资源（例如，改用 Workload Identity Federation for GKE）。

每个区域一个 Config Controller 实例

如果要避免一个地区中的 Config Controller 实例影响另一个区域，还可以考虑为每个地区运行一个 Config Controller 实例，其中每个 Config Controller 实例都管理该地区中的资源。

此配置可行，但它不是我们推荐的选项之一，原因如下：

  • 某些资源跨多个区域（例如 Cloud DNS），导致此策略受到限制。

  • 通常，位于同一区域的 Config Controller 集群会遇到相关的故障问题：您希望在区域性故障影响该区域的 Config Controller 时重新配置资源。

  • 您必须按区域拆分 Config Connector 资源。

  • Config Controller 目前仅在部分地区提供。

直接配置 Google Cloud 资源

在异常情况下，您可以直接更改底层 Google Cloud 资源，而无需通过 Git 或 Config Connector。Config Connector 会尝试修复任何“偏移”，因此，如果您的 Config Controller 实例仍在运行，则 Config Connector 会将您手动所做的任何更改视为“偏移”，并尝试还原它们。

但是，如果您停止 Config Controller 实例，或者地区离线，则这是一种有用的临时措施。

当您的 Config Controller 实例恢复时，Config Connector 可能会尝试还原您的手动更改。 为避免这种情况，您可以在 Git 中为手动更改进行相应的更改。