Config Connector のベストプラクティス

このページでは、Config Connector を使用する際に考慮すべきベストプラクティスについて説明します。

API の割り当て上限を管理する

API 割り当ての上限を超えていることを示すエラーが発生した場合は、同じ割り当てプロジェクトで作成した同じ種類の Config Connector リソースが多すぎる可能性があります。多くのリソースを作成すると、Config Connector が使用する調整戦略により、これらのリソースで同じ API エンドポイントに対して非常に多くの API リクエストが生成される可能性があります。

この問題を解決する方法の 1 つは、割り当ての増加をリクエストすることです。割り当て増加のほかに、Config Connector リソースで管理されている Google Cloud リソースに対する GET リクエストによって割り当てエラーが発生していることを確認した場合は、次のいずれかのオプションをご検討ください。

Config Connector リソースの調整間隔を長くする
複数のプロジェクトにリソースを分割する
Config Connector を Namespace が指定されたモード

調整間隔を長くする

Config Connector がリソースを調整する間隔を長くすることで、API 割り当て上限への到達を回避できます。調整間隔は 1 時間に設定することをおすすめします。

調整間隔を長くするには、調整間隔の構成の手順に沿って操作します。

複数のプロジェクトにリソースを分割する

このアプローチでは、Config Connector リソースを各プロジェクトに分散します。このアプローチは、新しいリソースを追加する場合には有効ですが、既存のリソースを削除して別のプロジェクトで再作成する必要があるため、既存のリソースを分割するにはリスクが伴います。リソースを削除すると、SpannerInstance リソースや BigtableTable リソースなど、一部のリソースタイプでデータが失われる可能性があります。データが削除される前にバックアップしておいてください。

既存の Config Connector リソースを複数のプロジェクトに分割するには、次の手順を行います。

別のプロジェクトに移行する Config Connector リソースを決定します。
Config Connector リソースを削除します。cnrm.cloud.google.com/deletion-policy アノテーションが abandon に設定されていないことを確認します。
新しいプロジェクトに移動する Config Connector リソースの YAML 構成で、spec.projectRef フィールドまたは cnrm.cloud.google.com/project-id アノテーションを更新します。
Config Connector で使用される IAM サービスアカウントに、新しいプロジェクトに対する適切な権限を付与します。
更新された YAML 構成を適用して、Config Connector リソースを作成します。

Namespace が指定されたモードに切り替える

Config Connector が Namespace が指定されたモードでインストールされているさまざまな Namespace に、異なる Google Cloud プロジェクトが所有する複数の IAM サービスアカウントをバインドし、リソースを複数の Namespace に分割できます。こちらの手順は次のとおりです。

Namespace が指定されたモードで実行するように Config Connector を構成します。異なるプロジェクトから新しい IAM サービスアカウントを作成し、プロジェクトごとに Config Connector を構成する手順に沿って、別の Namespace にバインドします。
新しい IAM サービスアカウントに、リソースを含むプロジェクトに対する適切な権限を付与します。
別の Namespace に移動する Config Connector リソースを決定します。
Config Connector リソースの YAML 構成を更新し、cnrm.cloud.google.com/deletion-policy アノテーションを abandon に設定します。
更新された YAML 構成を適用して Config Connector リソースの削除ポリシーを更新します。
Config Connector リソースを破棄します。
別の Namespace に移動する Config Connector リソースの YAML 構成で metadata.namespace フィールドを更新します。
更新された 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" を指定する必要があります。このアノテーションは、クラスタの作成時に構築されるデフォルトのノードプールを削除します。次に、個別のノードプールを作成するために、ContainerCluster ではなく ContainerNodePool に 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

Config Connector のベスト プラクティス