本文档提供了有关如何将 Config Controller 用量分片的建议。分片是将 Config Controller 管理的 Google Cloud 资源拆分到多个命名空间、集群或项目的过程。
分片具有以下优势：
- 降低更改的影响：如果单个分片停止运行，其他分片将不受影响。
- 帮助您管理安全性：每个分片都可以有专用的 IAM 和 RBAC 配置。入侵某个分片的恶意攻击者无法访问其他分片。一个分片中的配置错误不会影响其他分片。
- 更好的可伸缩性：单个分片可能有可伸缩性瓶颈，例如托管对象数或 API 配额。拥有多个分片可以提高 Config Controller 用量的整体可伸缩性。
将分片与 Config Controller 搭配使用
您可以通过几种不同的方式来实现分片。最佳方法取决于您的特定需求和要求。
分片模型
主要有两种分片模型：
- 按业务线或应用团队：当 Config Controller 由不同团队使用时，通常使用此模型。在此模型中，每个团队都有自己的分片。
- 按环境：当 Config Controller 用于不同的环境时，通常使用此模型。例如，您的开发环境中有一个分片，QA 环境有一个分片，生产环境中有一个分片。
尽量减少对跨分片引用的需求
将 Config Controller 用量分片时，您应尽量减少对跨分片引用的需求。跨分片引用会使您的配置更复杂且更难以管理。如需了解详情，请参阅跨实例的资源引用。
分片机制
主要有三种分片机制：
- 按命名空间：您可以创建其他命名空间并配置 Config Connector 以管理这些命名空间中的资源。
- 按 Config Controller 实例：您可以在一个 Google Cloud 项目中创建多个 Config Controller 实例。
- 按项目：您可以在多个 Google Cloud 项目中创建多个 Config Controller 实例。如果您遇到单个项目的配额瓶颈，此机制将有助于解决 API 配额问题。 如需了解详情，请参阅将资源拆分到多个项目中。
实现分片的注意事项
为 Config Controller 用量实现分片时，您应该了解一些潜在问题并计划缓解措施。
跨实例的资源引用
将 Config Controller 分片的一大难点在于如何处理跨实例的资源引用。例如，平台团队可能会在一个实例中创建项目，然后应用团队可能会在其他实例中创建引用这些项目的资源。这可能会导致出现以下问题：
- 复杂度提升：跨集群管理资源引用可能使配置更复杂且难以管理。
- 风险增加：如果在一个分片中删除某项资源，该资源仍可被其他分片中的资源引用。这可能会导致意外行为和数据丢失。
- 性能下降：跨集群的资源引用可能会导致更改配置时延迟时间延长。
您可以通过以下几种方法解决交叉引用难题：
- 分片而无需跨分片引用。这可以通过按环境或团队分片来完成。
- 使用外部引用。这意味着要引用的对象实际上并非由 Config Controller 管理。如果对象不经常更改，则这是一个不错的方案。
- 在所有分片中都提供相同的对象。这种方案更加复杂，但如果对象频繁更改，则它可能是最佳选择。
对象应该共享同一可靠来源，以避免不同分片中的这些对象发生协调冲突。您需要将这些对象的冲突预防政策设置为
none。
在选择每种方案之前，请务必仔细考虑每种方案的优缺点。
API 配额
分片可能会增加 API 配额。您应该了解这一点并相应地进行规划。如需了解有关如何管理 API 配额限制的最佳实践，请参阅管理 API 配额限制。