Config Controller による GKE クラスタの管理

プレビュー

このプロダクトは、Google Cloud Platform の利用規約の一般提供前のサービス規約の対象となります。一般提供前のプロダクトについてはサポートが制限され、一般提供前のプロダクトの変更は、他の一般提供前のバージョンと互換性がない可能性があります。詳細については、リリースステージの説明をご覧ください。

このチュートリアルでは、GKE クラスタ ブループリントを使用して、Config Controller で Google Kubernetes Engine（GKE）クラスタをプロビジョニングする方法について説明します。GKE クラスタ オペレータでクラスタ構成を宣言的に管理する場合は、以下の手順を行ってください。

Config Controller は、Anthos リソースと Google Cloud リソースをプロビジョニングし、オーケストレートするホスト型サービスです。Anthos Config Management の一部として、Google Cloud リソースのプロビジョニング、有効化、オーケストレートを行える API エンドポイントが用意されています。

KRM ブループリントを使用すると、組織全体でロールアウトできるベスト プラクティスをコード化しながら、一緒によく使用されるリソースをパッケージ化できます。

GKE クラスタ ブループリントは、既存の Google Cloud ネットワーク上で GKE クラスタを管理するために必要なすべてのリソースを含む KRM ブループリントです。複数のクラスタを設定するには、ブループリントを複数回インスタンス化します。

目標

• GKE クラスタを宣言的に構成します。
• Config Controller を使用して構成を適用します。

費用

このチュートリアルでは、課金対象である次の Google Cloud コンポーネントを使用します。

• Compute Engine
• Google Kubernetes Engine

GKE クラスタ ブループリントに含まれるリソースの一覧については、GKE パッケージのリソース セクションと、そのサブパッケージをご覧ください。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。

注: GKE クラスタのブループリントでは、セキュリティと本番環境への準備のベスト プラクティスに合わせてデフォルト値が構成されています。このため、デフォルトの構成では、他の方法で作成されたデフォルト クラスタよりも費用が高くなる可能性があります。適用する前に構成をよくご確認ください。

このチュートリアルを終了した後、作成したリソースを削除すると、それ以上の請求は発生しません。詳しくは、クリーンアップをご覧ください。

要件

• Google Workspace または Cloud Identity のサブスクリプションが必要です。

  Cloud Identity の設定方法を確認する。

  Google Workspace の設定方法を確認する。

• 組織で検証済みのドメインが必要です。

  Cloud Identity でドメインの所有権を検証する方法を確認する。

  Google Workspace でドメインの所有権を検証する方法を確認する。

• 組織に gke-security-groups という名前のグループが必要です。

  このセキュリティ グループの詳細については、GKE のグループをご覧ください。

  グループを作成する方法:

  • Google Workspace 管理コンソール
  • グループアプリ（ビジネス向け Google グループが必要）
  • Cloud Console のグループ（ビジネス向け Google グループが必要）

  詳しくは、ビジネス向け Google グループをオンまたはオフにする方法をご覧ください。

• Config Controller インスタンスが必要です。

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

  注: このチュートリアルでは、kpt を使用してリソースを適用します。GitOps は必要ありません。

• Google Cloud プロジェクトが必要です。これは、GKE クラスタを作成するプロジェクトです。Config Controller クラスタが存在するプロジェクトを使用することも、別のプロジェクトを使用することもできます。

  プロジェクトを作成および管理する方法を確認する

• Google Cloud プロジェクトの課金を有効にする必要があります。

  プロジェクトに対して課金が有効になっていることを確認する方法を確認する。

• プロジェクト内のリソースを管理するには、Config Controller の Namespace を構成しておく必要があります。

  デフォルトでは、Config Controller には Config Connector で使用するための config-control 名前空間が事前に構成されています。Config Controller の設定に、Config Connector がプロジェクトを管理するために必要な権限を付与する方法が記載されています。

  同じような構成の別の名前空間を使用することもできます。通常、これらのプロジェクトの名前空間には、管理するプロジェクトのプロジェクト ID の名前が付けられます。

  名前空間を監視するように Config Connector を構成する方法を確認する。

注: このチュートリアルの手順を行う際に Anthos の利用資格は必要ありません。

始める前に

1. Cloud Console で、Cloud Shell をアクティブにします。

   Cloud Shell をアクティブにする

   Cloud Console の下部にある Cloud Shell セッションが開始し、コマンドライン プロンプトが表示されます。Cloud Shell はシェル環境です。gcloud コマンドライン ツールなどの Cloud SDK がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。

このチュートリアルでは、すべてのコマンドを Cloud Shell から実行します。

環境を設定する

Cloud Shell で、次のコマンドを実行します。

1. Kubernetes の基本的なコマンドライン インターフェースである kubectl をインストールします。

   gcloud components install kubectl
   

2. KRM ブループリントの基本的なコマンドライン インターフェースである kpt をインストールします。

   gcloud components install kpt
   

   注: このチュートリアルでは kpt v1 以降が必要です。

3. Config Controller に接続するように kubectl と kpt を構成します。

   gcloud alpha anthos config controller get-credentials CONFIG_CONTROLLER_NAME \
       --location COMPUTE_REGION \
       --project CONFIG_CONTROLLER_PROJECT_ID
   

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

   • CONFIG_CONTROLLER_NAME: Config Controller クラスタの名前。

   • COMPUTE_REGION: Config Controller クラスタのリージョン（例: us-central1）。

   • CONFIG_CONTROLLER_PROJECT_ID: Config Controller クラスタのプロジェクト ID。

   注: プレビュー版では、Config Controller は us-central1 リージョンでのみ使用できます。

4. Resource Manager API を有効にします。

   gcloud services enable cloudresourcemanager.googleapis.com \
       --project PROJECT_ID
   

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

   注: Resource Manager API は、Config Connector で他のサービス API の有効化を管理するために使用されます。

5. ResourceGroup CRD がまだインストールされていない場合は、インストールします。

   kpt live install-resource-group
   

6. Config Connector がプロジェクトの名前空間で構成され、正常な状態であることを確認します。

   kubectl get ConfigConnectorContext -n PROJECT_NAMESPACE \
       -o "custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,HEALTHY:.status.healthy"
   

   PROJECT_NAMESPACE は、プロジェクト リソースの管理に使用する名前空間（config-control など）に置き換えます。

   出力例:

   NAMESPACE        NAME                                                HEALTHY
   config-control   configconnectorcontext.core.cnrm.cloud.google.com   true
   

GKE クラスタを構成する

GKE クラスタ ブループリントで GKE クラスタを構成するには、次のコマンドを実行します。

1. kpt を使用して、目的の作業ディレクトリ内から GKE クラスタのブループリントを取得します。

   kpt pkg get \
       https://github.com/GoogleCloudPlatform/blueprints.git/catalog/gke@v0.3.0 \
       CLUSTER_NAME
   

   CLUSTER_NAME は、GKE クラスタに使用する名前（hello-cluster など）に置き換えます。

2. クラスタ ディレクトリに移動します。

   cd ./CLUSTER_NAME/
   

3. setters.yaml ファイルを変更してパッケージを構成します。

   cat > setters.yaml << EOF
   apiVersion: v1
   kind: ConfigMap
   metadata: # kpt-merge: /setters
     name: setters
   data:
     # The cluster name
     cluster-name: CLUSTER_NAME
     # The environment (set as a label on the cluster)
     environment: dev
     # The compute location (region or zone)
     location: us-central1
     # The project in which to manage cluster resources
     platform-project-id: PROJECT_ID
     # The namespace in which to manage cluster resources
     platform-namespace: PROJECT_NAMESPACE
     # The name of the VPC in which to create a dedicated subnet
     network-name: default
     # The project that the VPC is in
     network-project-id: PROJECT_ID
     # The namespace in which to manage network resources
     networking-namespace: PROJECT_NAMESPACE
     # The private IP range for masters to use when peering to the VPC
     master-ip-range: 192.168.0.0/28
     # The private IP range for nodes to use, allocated to the dedicated subnet
     node-ip-range: 10.4.0.0/22
     # The private IP range for pods to use, allocated to the dedicated subnet
     pod-ip-range: 10.5.0.0/16
     # The private IP range for services to use, allocated to the dedicated subnet
     service-ip-range: 10.6.0.0/16
     # The namespace in which to manage service enablement resources
     projects-namespace: PROJECT_NAMESPACE
     # The group in which to manage the list of groups that can be used for RBAC.
     # Must be named exactly 'gke-security-groups'.
     security-group: gke-security-groups@YOUR_DOMAIN
   EOF
   

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

   • PROJECT_ID: オブジェクトの ID。

     このチュートリアルでは、クラスタとネットワークが同じプロジェクトにデプロイされます。

   • PROJECT_NAMESPACE: プロジェクト リソースの管理に使用する名前空間（たとえば、config-control）。

     このチュートリアルでは、クラスタ、ネットワーク、サービスの有効化を同じ名前空間で管理します。

   • YOUR_DOMAIN: グループで使用されているドメイン（example.com など）。

     注: security-group 値は、サービス アカウントまたはユーザーのメールアドレスではなく、グループのメールアドレスにする必要があります。グループ名は gke-security-groups にする必要があります。

   その他のデータ フィールドは必要に応じて変更できます。

   提供されているデフォルト値は、空のプロジェクトでなければデフォルト ネットワークで機能します。

4. テンプレート化されたリソースにセッター値をレンダリングします。

   kpt fn render
   

   出力例:

   Package "example/cluster":
   [RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
   [PASS] "gcr.io/kpt-fn/apply-setters:v0.1"
     Results:
       [INFO] set field value to "example-us-west4" in file "cluster/cluster.yaml" in field "metadata.name"
       [INFO] set field value to "config-control" in file "cluster/cluster.yaml" in field "metadata.namespace"
       [INFO] set field value to "dev" in file "cluster/cluster.yaml" in field "metadata.labels.gke.io/environment"
       [INFO] set field value to "platform-project-id" in file "cluster/cluster.yaml" in field "metadata.annotations.cnrm.cloud.google.com/project-id"
       ...(10 line(s) truncated, use '--truncate-output=false' to disable)
   
   Package "example/nodepools/primary":
   [RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
   [PASS] "gcr.io/kpt-fn/apply-setters:v0.1"
     Results:
       [INFO] set field value to "gke-example-us-east4-primary" in file "nodepools/primary/node-iam.yaml" in field "metadata.name"
       [INFO] set field value to "config-control" in file "nodepools/primary/node-iam.yaml" in field "metadata.namespace"
       [INFO] set field value to "platform-project-id" in file "nodepools/primary/node-iam.yaml" in field "metadata.annotations.cnrm.cloud.google.com/project-id"
       [INFO] set field value to "gke-example-us-east4-primary" in file "nodepools/primary/node-iam.yaml" in field "spec.displayName"
       ...(23 line(s) truncated, use '--truncate-output=false' to disable)
   
   Package "example/subnet":
   [RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
   [PASS] "gcr.io/kpt-fn/apply-setters:v0.1"
     Results:
       [INFO] set field value to "platform-project-id-example-us-west4" in file "subnet/subnet.yaml" in field "metadata.name"
       [INFO] set field value to "networking" in file "subnet/subnet.yaml" in field "metadata.namespace"
       [INFO] set field value to "network-project-id" in file "subnet/subnet.yaml" in field "metadata.annotations.cnrm.cloud.google.com/project-id"
       [INFO] set field value to "platform-project-id-example-us-west4" in file "subnet/subnet.yaml" in field "spec.description"
       ...(5 line(s) truncated, use '--truncate-output=false' to disable)
   
   Package "example":
   [RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
   [PASS] "gcr.io/kpt-fn/apply-setters:v0.1"
     Results:
       [INFO] set field value to "example" in file "cluster/cluster.yaml" in field "metadata.name"
       [INFO] set field value to "config-control" in file "cluster/cluster.yaml" in field "metadata.namespace"
       [INFO] set field value to "dev" in file "cluster/cluster.yaml" in field "metadata.labels.gke.io/environment"
       [INFO] set field value to "example-project-1234" in file "cluster/cluster.yaml" in field "metadata.annotations.cnrm.cloud.google.com/project-id"
       ...(44 line(s) truncated, use '--truncate-output=false' to disable)
   
   Successfully executed 4 function(s) in 4 package(s).
   

構成の変更を適用する

前の手順で行ったローカルの変更は、適用されるまでクラウドには反映されません。

構成の変更を適用するには、次のコマンドを実行します。

1. kpt を使用して作業ディレクトリを初期化します。これにより、変更を追跡するためのリソースが作成されます。

   kpt live init --namespace PROJECT_NAMESPACE
   

   PROJECT_NAMESPACE は、プロジェクト リソースの管理に使用する名前空間に置き換えます（例: config-control）。

2. 作成されるリソースをプレビューします。

   kpt live apply --dry-run
   

   すべてのリソースが「created（dry-run）」と表示されているはずです。

   出力例:

   service.serviceusage.cnrm.cloud.google.com/example-project-1234-example-container created (dry-run)
   computesubnetwork.compute.cnrm.cloud.google.com/example-project-1234-example created (dry-run)
   containercluster.container.cnrm.cloud.google.com/example created (dry-run)
   containernodepool.container.cnrm.cloud.google.com/example-primary created (dry-run)
   iampolicymember.iam.cnrm.cloud.google.com/artifactreader-gke-example-primary created (dry-run)
   iampolicymember.iam.cnrm.cloud.google.com/logwriter-gke-example-primary created (dry-run)
   iampolicymember.iam.cnrm.cloud.google.com/metricwriter-gke-example-primary created (dry-run)
   iamserviceaccount.iam.cnrm.cloud.google.com/gke-example-primary created (dry-run)
   8 resource(s) applied. 8 created, 0 unchanged, 0 configured, 0 failed (dry-run)
   0 resource(s) pruned, 0 skipped, 0 failed (dry-run)
   

3. kpt を使用してリソースを適用します。

   kpt live apply
   

   すべてのリソースが「created」と表示されているはずです。

   出力例:

   service.serviceusage.cnrm.cloud.google.com/example-project-1234-example-container created
   computesubnetwork.compute.cnrm.cloud.google.com/example-project-1234-example created
   containercluster.container.cnrm.cloud.google.com/example created
   containernodepool.container.cnrm.cloud.google.com/example-primary created
   iampolicymember.iam.cnrm.cloud.google.com/artifactreader-gke-example-primary created
   iampolicymember.iam.cnrm.cloud.google.com/logwriter-gke-example-primary created
   iampolicymember.iam.cnrm.cloud.google.com/metricwriter-gke-example-primary created
   iamserviceaccount.iam.cnrm.cloud.google.com/gke-example-primary created
   8 resource(s) applied. 8 created, 0 unchanged, 0 configured, 0 failed
   0 resource(s) pruned, 0 skipped, 0 failed
   

成功を検証する

変更が適用され、指定したリソースがプロビジョニングされていることを確認するには、次のコマンドを実行します。

1. リソースの準備ができるまで待ちます。

   kpt live status --output table --poll-until current
   

   このコマンドは、すべてのリソースのステータスが Current になり、条件が Ready になるまでポーリングします。

   必要に応じて、ctrl-c を使用して割り込みを行います。

   出力例:

   NAMESPACE   RESOURCE                                  STATUS      CONDITIONS      AGE     MESSAGE
   config-con  ComputeSubnetwork/example-project-1234-e  Current     Ready           41m     Resource is Ready
   config-con  ContainerCluster/example                  Current     Ready           41m     Resource is Ready
   config-con  ContainerNodePool/example-primary         Current     Ready           41m     Resource is Ready
   config-con  IAMPolicyMember/artifactreader-gke-examp  Current     Ready           41m     Resource is Ready
   config-con  IAMPolicyMember/logwriter-gke-example-pr  Current     Ready           41m     Resource is Ready
   config-con  IAMPolicyMember/metricwriter-gke-example  Current     Ready           41m     Resource is Ready
   config-con  IAMServiceAccount/gke-example-primary     Current     Ready           41m     Resource is Ready
   config-con  Service/example-project-1234-example-con  Current     Ready           41m     Resource is Ready
   

   注: このブループリントのリソースは、プロビジョニングに 40 分以上かかることがあります。

2. エラーが発生した場合は、デフォルトのイベント出力を使用してエラー メッセージをすべて確認します。

   kpt live status
   

よくある質問

固定フィールドを変更するにはどうすればよいですか？

まず、kubectl でリソースを削除してから、kubectl または kpt live apply で再度適用します。

リソースの状態が <NONE> と kpt live status が表示されるのはなぜですか？

これは通常、Config Connector がプロジェクトの名前空間用に構成されていないことを示します。

名前空間を監視するように Config Connector を構成する方法を確認してください。

setters.yaml を変更して再度適用しました。リソースが unchanged と表示されるのはなぜですか？

このエラーは、レンダリングせずに変更を適用しようとした場合に発生することがあります。

レンダリングを行うと、Kptfile で指定された関数のパイプラインが実行されます。その関数の中に apply-setters があり、この関数は入力として setters.yaml を使用します。

kpt fn render を実行して、関数のパイプラインを実行します。

クラスタの準備ができていますが、ノードプールがまだ作成されていないのはなぜですか？

Config Connector は、Google Cloud リソースに変更を適用するときに、指数バックオフで再試行を行います。リソースが更新されない場合、再試行バックオフが最大で 15 分に達することがあります。これにより、依存関係のチェーンがある場合に、他のリソースへの変更の適用を遅らせることができます。

クラスタのプロビジョニングには 15 分以上かかることがあります。これは、サブネットのプロビジョニングによって異なります。クラスタの準備ができるまで、ノードプールは再試行に最大で 15 分ほど待機することがあります。

ノードプールは、最終的にはプロビジョニングされますが、手動で再試行する場合は、影響を受けるリソースを削除してから再度適用します。

クリーンアップ

Config Controller の使用を停止する場合は、Config Controller で作成したすべてのリソースをクリーンアップしてから Config Controller を削除する必要があります。

1. kpt を使用して、作業ディレクトリからリソースを削除します。

   kpt live destroy
   

2. すべてのリソースが削除されるまで待ちます。

   until [ -z "$(kubectl get -R -f . --ignore-not-found | tee /dev/fd/2)" ]; \
   do sleep 1; done
   

   このコマンドは、すべてのリソースのステータスが Deleted になるまでポーリングします。

   必要に応じて、ctrl-c を使用して割り込みを行います。

   注: このブループリントのリソースは 5 分ほどで削除できます。

次のステップ

• ブループリントの詳細を確認する。
• Anthos Config Management のチュートリアルを使用する。
• KRM ブループリント カタログを参照する。
• Terraform ブループリント カタログを参照する。