Config Connector 最佳实践

本页面介绍了使用 Config Connector 时应考虑的最佳实践。

管理 API 配额限制

如果您看到指明已超出 API 配额限制的错误，可能是因为您在同一配额项目下创建了过多同一种类的 Config Connector 资源。当您创建大量资源时，由于 Config Connector 使用的协调策略，这些资源可能会为同一 API 端点生成过多的 API 请求。

解决此问题的一种方法是申请增加配额。除了增加配额之外，如果您确认配额错误是由针对 Config Connector 资源管理的 Google Cloud 资源的 GET 请求导致的，您可以考虑以下选项之一：

增加对账间隔

您可以增加 Config Connector 协调资源之间的间隔时间，以免达到 API 配额。建议将对账间隔设置为 1 小时。

如需增加对账间隔，请按照配置对账间隔中的步骤操作。

将资源拆分为多个项目

此方法会将您的 Config Connector 资源分布到不同的项目。此方法在添加新资源时非常有效，但拆分现有资源存在风险，因为您需要删除现有资源并在不同项目中重新创建这些资源。删除资源可能会导致某些类型的资源（例如 SpannerInstance 或 BigtableTable 资源）的数据丢失。您应该先备份数据，然后再将其删除。

如需将现有的 Config Connector 资源拆分到不同的项目中，请完成以下步骤：

  1. 确定您计划将哪些 Config Connector 资源移至不同项目。
  2. 删除 Config Connector 资源。 确保 cnrm.cloud.google.com/deletion-policy 注解未设置为 abandon。
  3. 更新您计划迁移到新项目的 Config Connector 资源的 YAML 配置中的 spec.projectRef 字段或 cnrm.cloud.google.com/project-id 注解。
  4. 向 Config Connector 使用的 IAM 服务帐号授予对新项目的适当权限。
  5. 应用更新后的 YAML 配置以创建 Config Connector 资源。

切换到命名空间模式

您可以将不同 Google Cloud 项目拥有的不同 IAM 服务帐号绑定到以命名空间模式安装 Config Connector 的不同命名空间，并将资源拆分到不同的命名空间中。为此，请完成以下步骤：

  1. 将 Config Connector 配置为在命名空间模式下运行。按照为每个项目配置 Config Connector 的说明，从不同项目创建新的 IAM 服务帐号，并将这些帐号绑定到不同的命名空间。

  2. 向新的 IAM 服务帐号授予对包含资源的项目的适当权限。

  3. 确定您计划将哪些 Config Connector 资源迁移到不同命名空间。

  4. 更新 Config Connector 资源的 YAML 配置，并设置 cnrm.cloud.google.com/deletion-policy 注解 abandon。

  5. 应用更新后的 YAML 配置以更新 Config Connector 资源的删除政策。

  6. 放弃 Config Connector 资源。

  7. 更新您计划迁移到不同命名空间的 Config Connector 资源的 YAML 配置中的 metadata.namespace 字段。

  8. 应用更新后的 YAML 配置以获取放弃的资源。

管理 GKE 集群中的节点池

如果您通过在 Config Connector 中应用 ContainerCluster 资源来创建集群，然后尝试通过应用更新后的 ContainerCluster 配置来更新 nodeConfig 或其他节点相关字段，则可能会遇到错误。这些错误是由 nodeConfig、nodeConfig.labels、nodeConfig.taint 等不可变字段导致的，这是底层 Google Cloud API 的技术限制。

如果您需要更新这些字段，可以使用 ContainerNodePool 资源来管理这些字段不可更改的节点池。如需使用 ContainerNodePool 资源管理节点池，您必须指定注解 cnrm.cloud.google.com/remove-default-node-pool: "true"。此注解可移除在集群创建期间创建的默认节点池。然后，如需创建单独的节点池，请在 ContainerNodePool（而不是 ContainerCluster）中指定 nodeConfig 字段。如需参考信息，请参阅 ContainerNodePool 资源示例。

您应该为 ContainerCluster 和 ContainerNodePool 资源设置注解 cnrm.cloud.google.com/state-into-spec: absent。此注解可以避免 Config Connector 控制器与底层 API 之间的交互期间潜在的协调错误。

以下示例展示了包含这些注解的 ContainerCluster 和 ContainerNodePool 配置：

apiVersion: container.cnrm.cloud.google.com/v1beta1
kind: ContainerCluster
metadata:
  name: containercluster-sample
  annotations:
    cnrm.cloud.google.com/remove-default-node-pool: "true"
    cnrm.cloud.google.com/state-into-spec: absent
spec:
  description: A sample cluster.
  location: us-west1
  initialNodeCount: 1

apiVersion: container.cnrm.cloud.google.com/v1beta1
kind: ContainerNodePool
metadata:
  labels:
    label-one: "value-one"
  name: containernodepool-sample
  annotations:
    cnrm.cloud.google.com/state-into-spec: absent
spec:
  location: us-west1
  autoscaling:
    minNodeCount: 1
    maxNodeCount: 3
  nodeConfig:
    machineType: n1-standard-1
    preemptible: false
    oauthScopes:
      - "https://www.googleapis.com/auth/logging.write"
      - "https://www.googleapis.com/auth/monitoring"
  clusterRef:
    name: containercluster-sample