Config Controller を設定する

このページでは、Config Controller の設定方法について説明します。

Config Controller は、Kubernetes ベースのマネージド コントロール プレーンを提供します。Config Controller インスタンスには、Policy Controller、Config Sync、Config Connector がプリインストールされています。これらのコンポーネントを使用すると、Kubernetes のツールとワークフローを活用して Google Cloud リソースを管理できます。また、GitOps ワークフローを使用して整合性を維持できます。詳細については、Config Controller の概要をご覧ください。

Config Controller インスタンスを初めて作成する場合は、クイックスタート: Config Controller でリソースを管理するをご覧ください。

制限事項

• Config Controller インスタンスはフルマネージドであるため、フリートで登録することはできません。

始める前に

Config Controller を設定する前に、次の手順を完了します。

1. Google Cloud CLI をインストールして初期化します。ここで説明する手順では Google Cloud CLI を使用します。Cloud Shell を使用する場合、Google Cloud CLI はすでにインストールされています。

2. kubectl をインストールします（デフォルトでは、Google Cloud CLI によってインストールされません）。

   gcloud components install kubectl
   

3. Config Controller をホストする Google Cloud プロジェクトを設定します。

   gcloud config set project PROJECT_ID
   

   PROJECT_ID は、Config Controller をホストする Google Cloud プロジェクトに置き換えます。

4. 必要な API を有効にします。

   gcloud services enable krmapihosting.googleapis.com \
       anthos.googleapis.com  \
       cloudresourcemanager.googleapis.com \
       serviceusage.googleapis.com
   

Config Controller インスタンスを作成する

Standard クラスタまたは Autopilot クラスタを基盤とする Config Controller インスタンスを作成できます。どちらのタイプのクラスタも非公開です。

多くのカスタマイズ オプションが必要な場合は、Standard クラスタを選択してください。高速インストール、水平 Pod と垂直 Pod の自動スケーリング、高度なセキュリティ機能（Container-Optimized OS、シールドされた GKE ノード、Workload Identity、セキュアブートなど）が必要な場合は、Autopilot クラスタを選択してください。

1. Config Controller インスタンスを作成します。

   Standard

   限定公開の GKE Standard クラスタを基盤とする Config Controller インスタンスを作成します。

   gcloud anthos config controller create CONFIG_CONTROLLER_NAME \
       --location=LOCATION
   

   次のように置き換えます。

   • CONFIG_CONTROLLER_NAME: Config Controller インスタンスに付ける名前。

   • LOCATION: 次のいずれかのリージョンを追加します。

     • us-central1
     • us-east1
     • us-east4
     • us-east5
     • us-west1
     • us-west2
     • us-west3
     • us-west4
     • us-south1
     • northamerica-northeast1
     • northamerica-northeast2
     • southamerica-west1
     • southamerica-east1
     • europe-north1
     • europe-west1
     • europe-west3
     • europe-west4
     • europe-west6
     • europe-west9
     • europe-west10
     • europe-west-12
     • europe-central2
     • europe-southwest1
     • australia-southeast1
     • australia-southeast2
     • asia-east1
     • asia-east2
     • asia-northeast1
     • asia-northeast2
     • asia-northeast3
     • asia-southeast1
     • asia-southeast2
     • asia-south1
     • asia-south2
     • africa-south1
     • me-west1
     • me-central1

     これは、Config Controller インスタンスが作成されるリージョンです。他のリージョンはサポートされていません。

   標準の Config Controller インスタンスを作成する場合は、複数のオプション パラメータを設定できます。オプションの完全なリストについては、gcloud anthos config controller create のドキュメントをご覧ください。

   Autopilot

   限定公開の GKE Autopilot クラスタを基盤とする Config Controller インスタンスを作成するには、次のコマンドを実行します。

   gcloud anthos config controller create CONFIG_CONTROLLER_NAME \
       --location=LOCATION \
       --full-management
   

   次のように置き換えます。

   • CONFIG_CONTROLLER_NAME: コントローラに付ける名前。

   • LOCATION: 次のいずれかのリージョンを追加します。

     • us-central1
     • us-east1
     • us-east4
     • us-east5
     • us-west2
     • northamerica-northeast1
     • northamerica-northeast2
     • europe-north1
     • europe-west1
     • europe-west3
     • europe-west6
     • australia-southeast1
     • australia-southeast2
     • asia-northeast1
     • asia-northeast2
     • asia-southeast1

     他のリージョンはサポートされていません。

   この操作は、完了まで最大で 15 分ほどかかります。作成中の進行状況は、Google Cloud コンソールのログ エクスプローラで確認できます。

   ログ エクスプローラに移動

   作成中にエラーが発生した場合は、Config Controller のトラブルシューティングで一般的な問題の解決に関するガイダンスをご覧ください。

2. Config Controller インスタンスが作成されたことを確認するには、Config Controller インスタンスのリストを表示します。

   gcloud anthos config controller list --location=LOCATION
   

   ステータス列に RUNNING の値が表示されているはずです。ステータスが CREATING の場合は、Config Controller インスタンスがまだ作成中のため、しばらく待つ必要があります。ERROR が表示された場合は、自力で解決できない問題が発生しています。詳しくは Google Cloud サポートにお問い合わせください。

3. Config Controller エンドポイントと通信するために、適切な認証情報とエンドポイント情報を取得します。

   gcloud anthos config controller get-credentials CONFIG_CONTROLLER_NAME \
       --location LOCATION
   

Config Controller インスタンスを使用する

Config Controller インスタンスが作成されたので、インストールされたコンポーネントを使って次のタスクを行います。

• Config Connector を使用して、Google Cloud リソースを作成します。Config Controller で使用する Google Cloud リソースがすでに存在する場合は、既存のリソースの取得をご覧ください。

• Policy Controller を使用して、規制遵守と Kubernetes 標準を実施する制約を適用します。

• Config Sync を構成したら、次のセクションで、Config Controller インスタンスを構成ファイル（Policy Controller の制約と Config Connector リソースなどを含む）と同期します。この構成ファイルは、信頼できる情報源に保存されます。

Config Controller でこれらのタスクを行う方法については、クイックスタート: Config Controller でリソースを管理するをご覧ください。

Config Controller インスタンスを構成する

以降のセクションでは、Config Controller インスタンスのコンポーネントを構成する方法について説明します。

警告: Config Controller インスタンスが破損する可能性があるため、Config Controller インスタンスの Google Kubernetes Engine クラスタを編集、更新、削除しないでください。詳細については、Config Controller に対するサポートされていない変更をご覧ください。

Config Connector を構成する

Config Connector の設定を管理する必要はありません。ただし、Google Cloud リソースを管理する権限を Config Controller に付与する必要があります。

1. サービス アカウントのメールアドレスを格納する環境変数を設定します。

   export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \
       -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"
   

2. ポリシー バインディングを作成します。

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member "serviceAccount:${SA_EMAIL}" \
       --role "ROLE" \
       --project PROJECT_ID
   

   次のように置き換えます。

   • PROJECT_ID: プロジェクト ID
   • ROLE: ニーズを満たす一連の事前定義ロールまたはカスタムロール。本番環境以外では、roles/owner を使用することもできます。Config Controller の IAM 権限の詳細については、Config Controller の IAM 権限をご覧ください。

   オペレーションが失敗した場合は、コントローラが準備完了状態になっているかどうかを確認します。

   kubectl wait pod --all --all-namespaces --for=condition=Ready
   

これらの権限を付与したら、Google Cloud リソースの作成を開始できます。

Policy Controller を構成する

Policy Controller の構成は任意ですが、デフォルトのインストールは必要に応じて変更できます。

Policy Controller を構成するには、config-management という名前の ConfigManagement オブジェクトの spec.policyController フィールドを編集します。この ConfigManagement オブジェクトは、インストール時に Config Controller によって自動的に作成されます。ConfigManagement オブジェクトを編集する際に、spec.policyController.enabled を false に設定しないでください。Config Controller はこの変更を自動的にオーバーライドします。モニタリングを行うには、Policy Controller に指標の送信を許可する必要があります。

次のコマンドを実行して、Policy Controller に指標の送信を許可します。

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:PROJECT_ID.svc.id.goog[gatekeeper-system/gatekeeper-admin]" \
  --role=roles/monitoring.metricWriter

PROJECT_ID は、クラスタの Google Cloud プロジェクト ID に置き換えます。

Config Sync を構成する

信頼できる情報源に保存されている構成ファイルから Config Controller インスタンスを同期する場合は、Config Sync を構成する必要があります。

Config Sync を使用して Config Connector リソースを作成する場合は、リソースの管理権限が Config Controller に付与されていることを確認してください。

Config Sync を構成するには、RootSync オブジェクトを作成して編集します。

1. 外部リポジトリ（GitHub など）から同期するには、GKE で Cloud NAT を設定します。限定公開クラスタノードには外部へのインターネット アクセスがないため、このような処理を行う必要があります。

2. 次のいずれかのマニフェストを root-sync.yaml として保存します。構成ファイルのソースタイプに対応するマニフェスト バージョンを使用します。

   Git

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: git
     sourceFormat: ROOT_FORMAT
     git:
       repo: ROOT_REPOSITORY
       revision: ROOT_REVISION
       branch: ROOT_BRANCH
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       secretRef:
         name: ROOT_SECRET_NAME
       noSSLVerify: ROOT_NO_SSL_VERIFY
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • ROOT_SYNC_NAME: RootSync オブジェクトの名前を追加します。
   • ROOT_FORMAT: 非構造化リポジトリを使用するには unstructured を追加し、階層型リポジトリを使用するには hierarchy を追加します。この値では大文字と小文字が区別されます。このフィールドは省略可能で、デフォルト値は hierarchy です。unstructured を追加することをおすすめします。この形式では自分にとって最も便利な方法で構成ファイルを整理できます。
   • ROOT_REPOSITORY: ルート リポジトリとして使用する Git リポジトリの URL を記述します。HTTPS または SSH プロトコルを使用する URL を入力できます。たとえば、https://github.com/GoogleCloudPlatform/anthos-config-management-samples では HTTPS プロトコルを使用します。このフィールドは必須です。
   • ROOT_REVISION: 同期元となる Git リビジョン（タグまたはハッシュ）を追加します。このフィールドは省略可能で、デフォルト値は HEAD です。Config Sync バージョン 1.17.0 以降では、revision フィールドにブランチ名を指定することもできます。バージョン 1.17.0 以降のハッシュを使用する場合、省略形ではなく、完全なハッシュにする必要があります。
   • ROOT_BRANCH: 同期元となるリポジトリのブランチを追加します。このフィールドは省略可能で、デフォルト値は master です。Config Sync バージョン 1.17.0 以降では、わかりやすくするため、revision フィールドを使用してブランチ名を指定することをおすすめします。revision フィールドと branch フィールドの両方が指定されている場合、revision が branch よりも優先されます。
   • ROOT_DIRECTORY: 同期先への構成を含むルート ディレクトリへの Git リポジトリのパスを記述します。このフィールドは省略可能で、デフォルトはリポジトリのルート ディレクトリ（/）です。

   • ROOT_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • ssh: SSH 認証鍵ペアを使用
     • cookiefile: cookiefile を使用
     • token: トークンを使用
     • gcpserviceaccount: Google サービス アカウントを使用して Cloud Source Repositories にアクセス
     • gcenode: Google サービス アカウントを使用して Cloud Source Repositories にアクセス。このオプションは、Workload Identity がクラスタで有効になっていない場合にのみ、選択してください。

     この認証の種類の詳細については、Config Sync に Git の読み取り専用アクセス権を付与するをご覧ください。

     このフィールドは必須です。

   • ROOT_EMAIL: ROOT_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com

   • ROOT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合は、Secret の公開鍵を Git プロバイダに追加する必要があります。このフィールドは省略可能です。

   • ROOT_NO_SSL_VERIFY: SSL 証明書の検証を無効にするには、このフィールドを true に設定します。デフォルト値は false です。

   • ROOT_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を Git プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

     CA 証明書の Secret オブジェクトの構成方法については、認証局の ConfigManagement Operator の構成をご覧ください。

   フィールドの説明と spec フィールドに追加できる項目の全一覧については、RootSync フィールドをご覧ください。

   このマニフェストは、Git をソースとして使用する RootSync オブジェクトを作成します。

   OCI

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: oci
     sourceFormat: ROOT_FORMAT
     oci:
       image: ROOT_IMAGE
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • ROOT_SYNC_NAME: RootSync オブジェクトの名前を追加します。
   • ROOT_FORMAT: 非構造化リポジトリを使用するには unstructured を追加し、階層型リポジトリを使用するには hierarchy を追加します。この値では大文字と小文字が区別されます。このフィールドは省略可能で、デフォルト値は hierarchy です。unstructured を追加することをおすすめします。この形式では自分にとって最も便利な方法で構成ファイルを整理できます。
   • ROOT_IMAGE: ルート リポジトリとして使用する OCI イメージの URL（例: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME）。デフォルトでは、イメージは latest タグから取得されますが、TAG または DIGEST を使用してイメージを pull することもできます。PACKAGE_NAME で TAG または DIGEST を指定します。
     • TAG で pull するには: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • DIGEST で pull するには: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

   注意: Config Sync では、OCI レイヤを tar または tar+gzip で圧縮する必要があります。他の形式（tar+bz2 など）は Config Sync で認識されません。有効な REPO からサポートされていない形式の OCI イメージに切り替えると、マネージド リソースがエラーなしでプルーニングされます。

   • ROOT_DIRECTORY: 同期先への構成を含むルート ディレクトリへのリポジトリのパスを記述します。このフィールドは省略可能で、デフォルトはリポジトリのルート ディレクトリ（/）です。

   • ROOT_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • gcenode: Compute Engine のデフォルト サービス アカウントを使用して、Artifact Registry のイメージにアクセスします。このオプションは、Workload Identity がクラスタで有効になっていない場合にのみ選択してください。
     • gcpserviceaccount: Google サービス アカウントを使用してイメージにアクセスします。

     このフィールドは必須です。

   • ROOT_EMAIL: ROOT_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com

   • ROOT_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を OCI プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

   CA 証明書の Secret オブジェクトの構成方法については、認証局の ConfigManagement Operator の構成をご覧ください。

   フィールドの説明と spec フィールドに追加できる項目の全一覧については、RootSync フィールドをご覧ください。

   このマニフェストは、OCI イメージをソースとして使用する RootSync オブジェクトを作成します。

   Helm

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: helm
     sourceFormat: ROOT_FORMAT
     helm:
       repo: ROOT_HELM_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: ROOT_AUTH_TYPE
         gcpServiceAccountEmail: ROOT_EMAIL
         secretRef:
           name: ROOT_SECRET_NAME
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • ROOT_SYNC_NAME: RootSync オブジェクトの名前を追加します。
   • ROOT_FORMAT: 非構造化リポジトリを使用するには unstructured を追加し、階層型リポジトリを使用するには hierarchy を追加します。この値では大文字と小文字が区別されます。このフィールドは省略可能で、デフォルト値は hierarchy です。unstructured を追加することをおすすめします。この形式では自分にとって最も便利な方法で構成ファイルを整理できます。
   • ROOT_HELM_REPOSITORY: ルート リポジトリとして使用する Helm リポジトリの URL。HTTPS または SSH プロトコルを使用する URL を入力できます。たとえば、https://github.com/GoogleCloudPlatform/anthos-config-management-samples では HTTPS プロトコルを使用します。このフィールドは必須です。
   • HELM_CHART_NAME: Helm チャートの名前を追加します。このフィールドは必須です。
   • HELM_CHART_VERSION: チャートのバージョン。このフィールドは省略可能です。値が指定されていない場合は、最新バージョンが使用されます。
   • HELM_RELEASE_NAME: Helm リリースの名前。このフィールドは省略可能です。
   • HELM_RELEASE_NAMESPACE: リリースのターゲット Namespace。テンプレートに namespace: {{ .Release.Namespace }} を含むリソースの Namespace のみが設定されます。このフィールドは省略可能です。値が指定されていない場合は、デフォルトの Namespace config-management-system が使用されます。
   • HELM_INCLUDE_CRDS: Helm テンプレートでも CustomResourceDefinition を生成する場合は、true に設定します。このフィールドは省略可能です。値が指定されていない場合、デフォルトは false であり、CRD は生成されません。
   • VALUE: Helm チャートのデフォルト値の代わりに使用する値。このフィールドを Helm チャートの values.yaml ファイルと同じ方法でフォーマットします。このフィールドは省略可能です。

   • ROOT_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • token: 非公開 Helm リポジトリへのアクセスにユーザー名とパスワードを使用します。
     • gcenode: Compute Engine のデフォルト サービス アカウントを使用して、Artifact Registry のイメージにアクセスします。このオプションは、Workload Identity がクラスタで有効になっていない場合にのみ選択してください。
     • gcpserviceaccount: Google サービス アカウントを使用してイメージにアクセスします。

     このフィールドは必須です。

   • ROOT_EMAIL: ROOT_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com

   • ROOT_SECRET_NAME: token が ROOT_AUTH_TYPE の場合は、Secret の名前を追加します。このフィールドは省略可能です。

   • ROOT_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を Helm プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

   CA 証明書の Secret オブジェクトの構成方法については、認証局の ConfigManagement Operator の構成をご覧ください。

   フィールドの説明と spec フィールドに追加できる項目の全一覧については、RootSync フィールドをご覧ください。

   このマニフェストは、Helm を情報源として使用する RootSync オブジェクトを作成します。

3. Config Sync の構成を作成するには、マニフェストを適用して RootSync オブジェクトを作成します。

   kubectl apply -f root-sync.yaml
   

4. 変更が適用されたことを確認するには、RootSync オブジェクトを表示します。

   kubectl describe rootsync ROOT_SYNC_NAME -n config-management-system
   

Config Controller をアップグレードする

Config Controller はマネージド サービスであるため、Google が自動的にアップグレードします。新機能の詳細と、Config Controller で使用される Config Sync、Policy Controller、Config Connector のバージョンについては、Config Controller のリリースノートをご覧ください。

Config Controller インスタンスを削除する

Config Controller インスタンスの使用を停止する場合は、Config Controller クラスタ自体を削除する前に、作成したすべての Config Connector リソースをクリーンアップします。

プロビジョニングされたリソースを削除せず Config Controller インスタンスを削除すると、リソースは放棄された状態で残ります。このようなリソースは Google Cloud 内に存在し続けます（課金もされます）が、宣言型の構成では管理されません。

すべてのリソースが削除されてから Config Controller クラスタを削除します。

gcloud anthos config controller delete \
    --location=LOCATION CONFIG_CONTROLLER_NAME

本番環境に関する考慮事項

本番環境に移行する前に、Config Controller の高可用性に関する考慮事項を確認してください。

次のステップ

• Config Controller のスケーラビリティに関するベスト プラクティスを確認する。
• Config Controller のトラブルシューティング。
• サポートを利用する。
• Config Sync を使用した構成とポリシーの同期の詳細を確認する。
• Policy Controller によるポリシーの適用の詳細を確認する。
• Config Connector のリソースの詳細を確認する。