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

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

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

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

この問題を解決するには、割り当ての増加をリクエストします。割り当て増加のほかに、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 のベスト プラクティス