クイックスタート: Config Controller でリソースを管理する

Config Connector、Policy Controller、Config Sync がプリインストールされた Config Controller インスタンスを作成する方法について説明します。また、次の作業を行ってインスタンスの利用方法を学びます。

• Config Connector で Google Cloud リソースを作成し、管理する。
• デプロイする前に Policy Controller の制約を作成してポリシーを適用し、ポリシー違反を検出する。
• Google Cloud リソースを含むサンプル リポジトリと同期するように Config Sync を構成して、GitOps を設定する。

始める前に

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
2. Install the Google Cloud CLI.

3. To initialize the gcloud CLI, run the following command:

   gcloud init

4. Create or select a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   • Create a Google Cloud project:

     gcloud projects create PROJECT_ID

     Replace PROJECT_ID with a name for the Google Cloud project you are creating.

   • Select the Google Cloud project that you created:

     gcloud config set project PROJECT_ID

     Replace PROJECT_ID with your Google Cloud project name.

5. Make sure that billing is enabled for your Google Cloud project.

6. Enable the KRM, GKE, GKE Enterprise, Resource Manager, and Service Usage APIs:

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

7. Install the Google Cloud CLI.

8. To initialize the gcloud CLI, run the following command:

   gcloud init

9. Create or select a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   • Create a Google Cloud project:

     gcloud projects create PROJECT_ID

     Replace PROJECT_ID with a name for the Google Cloud project you are creating.

   • Select the Google Cloud project that you created:

     gcloud config set project PROJECT_ID

     Replace PROJECT_ID with your Google Cloud project name.

10. Make sure that billing is enabled for your Google Cloud project.

11. Enable the KRM, GKE, GKE Enterprise, Resource Manager, and Service Usage APIs:

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

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

1. ターミナルで Autopilot Config Controller インスタンスを作成します。

   gcloud anthos config controller create cc-example \
       --location=us-central1 \
       --full-management
   

   この操作は、完了まで最大で 15 分ほどかかります。

   次のような出力が表示されます。

   Created instance [cc-example].
   Fetching cluster endpoint and auth data.
   kubeconfig entry generated for krmapihost-cc-example.
   

2. Config Controller エンドポイントと通信するように kubectl を構成するため、必要な認証情報とエンドポイント情報を取得します。

   gcloud anthos config controller get-credentials cc-example \
       --location us-central1
   

3. Config Controller インスタンスの一覧を表示して、インスタンスが作成されたことを確認します。

   gcloud anthos config controller list --location=us-central1
   

   次のような出力が表示されます。

   NAME                 LOCATION                 STATE
   cc-example           us-central1              RUNNING
   

成功: Config Sync、Policy Controller、Config Management コンポーネントを活用してクラスタの管理を簡素化できる Config Controller インスタンスが作成されました。

Config Controller に必要な権限を付与する

このセクションでは、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 "roles/owner" \
       --project PROJECT_ID
   

   PROJECT_ID は、実際のプロジェクト ID に置き換えます。

   出力は次のようになります。

   Updated IAM policy for project [PROJECT_ID].
   auditConfigs:
   - auditLogConfigs:
     - logType: ADMIN_READ
     - logType: DATA_READ
     - logType: DATA_WRITE
     service: gkehub.googleapis.com
   # Remainder of output omitted
   

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

以降のセクションでは、Config Controller インスタンスの使用方法について説明します。

Config Connector で Google Cloud リソースを作成する

Config Controller インスタンスでは、Config Connector を活用して、Kubernetes ツールと API を使用する多くの Google Cloud サービスとリソースを管理できます。このセクションでは、Config Controller を使用して PubSubTopic リソースを作成します。

Config Connector で Pub/Sub トピックを作成手順は次のとおりです。

1. Config Connector を使用して Pub/Sub API を有効にします。

   1. 任意のテキスト エディタで enable-pubsub.yaml という名前のファイルを作成し、そのファイルに次の YAML をコピーします。

      # enable-pubsub.yaml
      apiVersion: serviceusage.cnrm.cloud.google.com/v1beta1
      kind: Service
      metadata:
        name: pubsub.googleapis.com
        namespace: config-control
      spec:
        projectRef:
          external: projects/PROJECT_ID
      

      PROJECT_ID は、実際のプロジェクト ID に置き換えます。

   2. Pub/Sub API を有効にするには、マニフェストをクラスタに適用します。

      kubectl apply -f enable-pubsub.yaml
      

      この API の有効化には数分かかることがあります。

2. Config Connector を使用して Pub/Sub トピックを作成します。

   1. pubsub-topic.yaml という名前のファイルを作成して、次の YAML をコピーします。

      # pubsub-topic.yaml
      apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
      kind: PubSubTopic
      metadata:
        annotations:
          cnrm.cloud.google.com/project-id: PROJECT_ID
        labels:
          label-one: "value-one"
        name: example-topic
        namespace: config-control
      

   2. Pub/Sub トピックを作成します。

      kubectl apply -f pubsub-topic.yaml
      

3. Pub/Sub トピックの一覧を表示して、Config Controller によって Google Cloud にリソースが作成されていることを確認します。

   gcloud pubsub topics list
   

   出力は次のようになります。

   ---
   name: projects/PROJECT_ID/topics/start-instance-event
   ---
   labels:
     label-one: value-one
     managed-by-cnrm: 'true'
   name: projects/PROJECT_ID/topics/example-topic
   

成功: Config Controller によって Pub/Sub トピックが作成されました。同じプロセスで別のタイプの Google Cloud リソースも作成できます。詳細なリストについては、Config Connector のリソースをご覧ください。

Policy Controller でポリシーを適用する

Config Controller インスタンスでは、Policy Controller と Policy Controller の制約を使用できます。Policy Controller の一部として、Config Controller は制約テンプレート ライブラリを自動的にインストールします。このライブラリのテンプレートを使用して、Config Controller インスタンスに共通のセキュリティ管理とコンプライアンス管理を適用できます。

このセクションでは、GCPStorageLocationConstraintV1 制約テンプレートを使用して制約を作成します。このテンプレートを使用すると、Cloud Storage バケットが作成されるロケーションを制限できます。このテンプレートを使用して作成する制約では、ロケーションを us-central1 に制限します。この制約を使用して、優れた費用対効果を提供するリージョンにバケットが作成されるようにします。

制約を作成するには:

1. bucket-constraint.yaml という名前のファイルを作成して、次の YAML をコピーします。

   # bucket-constraint.yaml
   apiVersion: constraints.gatekeeper.sh/v1beta1
   kind: GCPStorageLocationConstraintV1
   metadata:
     name: storage-only-in-us-central1
   spec:
     match:
       kinds:
       - apiGroups:
         - storage.cnrm.cloud.google.com
         kinds:
         - StorageBucket
     parameters:
       locations:
       - us-central1
   

2. 制約を作成します。

   kubectl apply -f bucket-constraint.yaml
   

   次のような出力が表示されます。

   gcpstoragelocationconstraintv1.constraints.gatekeeper.sh/storage-only-in-us-central1 created`
   

3. 制約が機能していることを確認するには、Config Connector を使用して asia-southeast1 に StorageBucket リソースを作成します。

   1. asia-storage-bucket.yaml という名前のファイルを作成して、次の YAML をコピーします。

      # asia-storage-bucket.yaml
      apiVersion: storage.cnrm.cloud.google.com/v1beta1
      kind: StorageBucket
      metadata:
        name: bucket-in-disallowed-location
        namespace: config-control
      spec:
        location: asia-southeast1
      

   2. Cloud Storage バケットを作成してみましょう。

      kubectl apply -f asia-storage-bucket.yaml
      

      次のような出力が表示されます。

      Error from server (Forbidden): error when creating "STDIN": admission webhook "validation.gatekeeper.sh" denied the request: [storage-only-in-us-central1] Cloud Storage bucket <bucket-in-disallowed-location> uses a disallowed location <asia-southeast1>, allowed locations are ["us-central1"]
      

成功: Policy Controller によって制約が適用されています。これで、us-central1 にのみ Cloud Storage バケットが作成されるようになりました。制約の使用に関する詳細は、制約テンプレート ライブラリを使用するをご覧ください。

Config Sync で GitOps を設定する

Config Sync は、Git リポジトリ、OCI イメージ、Helm リポジトリに保存されている構成ファイル、ポリシー、Google Cloud リソースに Config Controller インスタンスを同期できる GitOps サービスです。Config Sync は Config Controller の状態をソースの構成ファイルに合わせて継続的に調整するため、一貫性のあるインスタンス構成を実現できます。

このセクションでは、Config Controller インスタンスを公開 GitHub リポジトリに同期させます。このリポジトリには別の PubSubTopic リソースが含まれています。このリポジトリからインスタンスを同期すると、リソースが自動的に作成され、インスタンスに適用されます。GitOps ワークフローを使用する場合は、リソースを直接適用するのではなく、Config Sync を使用してリソースを作成することすることもできます。

注: 本番環境では、安全な限定公開のリポジトリを使用します。

1. GitHub と同期するには Cloud NAT を設定します。これは、Config Controller インスタンスが限定公開 Google Kubernetes Engine（GKE）Enterprise エディション クラスタによってバックアップされ、限定公開クラスタノードにアウトバウンド インターネット アクセスがないため、必要になります。

   1. Cloud NAT ルーターを作成します。このルーターは、NAT ゲートウェイを設定するために必要です。

      gcloud compute routers create cc-nat-router \
          --network default \
          --region us-central1
      

      出力は次のようになります。

      Creating router [cc-nat-router]...done.
      NAME           REGION       NETWORK
      cc-nat-router  us-central1  default
      

   2. 前の手順で作成したルーターに NAT ゲートウェイを設定します。

      gcloud compute routers nats create cc-nat-config \
          --router-region us-central1 \
          --router cc-nat-router \
          --nat-all-subnet-ip-ranges \
          --auto-allocate-nat-external-ips
      

      次のような出力が表示されます。

      Creating NAT [cc-nat-config] in router [cc-nat-router]...done.
      

2. サンプル リポジトリと同期するように Config Controller インスタンスを構成するには、cc-rootsync.yaml という名前のファイルを作成して、そのファイルに次の YAML をコピーします。

   # cc-rootsync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: root-sync
     namespace: config-management-system
   spec:
     sourceFormat: unstructured
     git:
       repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
       branch: main
       dir: config-controller-quickstart
       auth: none
   

3. 構成を適用します。

   kubectl apply -f cc-rootsync.yaml
   

   インスタンスがリポジトリと同期した後、Config Sync は Pub/Sub トピックを作成し、Config Controller インスタンスに適用します。

4. Config Sync が Git リポジトリを Config Controller インスタンスに同期させていることを確認します。

   nomos status --contexts gke_PROJECT_ID_us-central1_krmapihost-cc-example
   

   出力は次のようになります。

   *gke_PROJECT_ID_us-central1_krmapihost-cc-example
   --------------------
   <root>:root-sync                         https://github.com/GoogleCloudPlatform/anthos-config-management-samples/config-controller-quickstart@main
   SYNCED @ 2023-01-10 18:31:02 +0000 UTC   715b4295d3eac07b057cce2543275c1ee104cad8
   Managed resources:
      NAMESPACE        NAME                                                               STATUS   SOURCEHASH
      config-control   pubsubtopic.pubsub.cnrm.cloud.google.com/pubsub-topic-sample-sync  Current   715b429
      config-control   service.serviceusage.cnrm.cloud.google.com/pubsub.googleapis.com   Current   715b429
   

   この出力が表示されない場合は、数分待ってからもう一度試してください。

5. Config Controller がリソースを作成していることを確認します。

   gcloud pubsub topics list
   

   出力は次のようになります。

   name: projects/PROJECT_ID/topics/start-instance-event
   ---
   labels:
     managed-by-cnrm: 'true'
   name: projects/PROJECT_ID/topics/sample-topic
   ---
   labels:
     managed-by-cnrm: 'true'
   name: projects/PROJECT_ID/topics/pubsub-topic-sample-sync
   ---
   labels:
     label-one: value-one
     managed-by-cnrm: 'true'
   name: projects/PROJECT_ID/topics/example-topic
   

   この出力には、Config Controller インスタンスの作成セクションで作成した Pub/Sub と、インスタンスを GitHub リポジトリに同期して作成した Pub/Sub が含まれています。

成功: Config Sync を使用してリソースをデプロイできました。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトを削除する

注意: プロジェクトを削除すると、次のような影響があります。

• プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
• カスタム プロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタム プロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

個々のリソースを削除する

1. Config Connector PubSubTopic リソースを削除します。

   kubectl delete -f pubsub-topic.yaml
   

2. Policy Controller の制約を削除します。

   kubectl delete -f bucket-constraint.yaml
   

3. NAT ルーターを削除します。

   gcloud compute routers delete cc-nat-router \
       --project=PROJECT_ID \
       --region=us-central1
   

   プロンプトが表示されたら、y キーを押します。

4. Config Sync が作成した Pub/Sub リソースを削除します。

   kubectl delete PubSubTopic pubsub-topic-sample-sync -n config-control
   

5. RootSync リソースを削除します。

   kubectl delete rootsync root-sync -n config-management-system
   

6. 任意のテキスト エディタを使用して、作成した YAML ファイルをすべて削除します。

   • enable-pubsub.yaml
   • pubsub-topic.yaml
   • bucket-constraint.yaml
   • asia-storage-bucket.yaml
   • cc-rootsync.yaml

7. Config Controller インスタンスを削除します。

   gcloud anthos config controller delete --location=us-central1 cc-example
   

   プロンプトが表示されたら、y キーを押します。

次のステップ

• Config Controller の設定方法を確認する。
• Config Controller の詳細を確認する。