Config Controller と KRM ブループリントによる GKE クラスタの管理

このチュートリアルでは、Config Controller を使用して KRM ブループリントを作成し、Google Kubernetes Engine(GKE)クラスタと Virtual Private Cloud(VPC)、GKE クラスタをホストするサブネット、Pod とサービスの名前付き IP 範囲など、必要なネットワーク インフラストラクチャをプロビジョニングする方法について説明します。GKE クラスタ オペレータでクラスタ構成とネットワーク インフラストラクチャを宣言的に管理する場合は、以下の手順を行ってください。

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

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

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

ネットワーキング ブループリントは、GKE クラスタの作成に必要な VPC、サブネット、エイリアス IP 範囲など、必要なネットワーキング コンポーネントの作成に役立つ一連の KRM ブループリントです。これらのブループリントを複数回インスタンス化すると、複数のクラスタに必要な複数のサブネットとエイリアス IP 範囲を設定できます。

目標

  • GKE クラスタをホストするために必要なネットワーク インフラストラクチャを宣言的に作成します。
  • このネットワーク インフラストラクチャ内で、GKE クラスタを宣言的に構成します。
  • Config Controller を使用して構成を適用します。

費用

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

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

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

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

要件

始める前に

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

    Cloud Shell をアクティブにする

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

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

環境を設定する

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

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

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

    gcloud components install kpt
    
  3. Config Controller に接続するように kubectlkpt を構成します。

    gcloud 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。

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

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

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

  5. 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
    

クラスタに VPC、サブネット、エイリアス IP 範囲を構成する

VPC を構成する

ネットワーク ブループリントで VPC を設定して構成するには、次のコマンドを実行します。

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

    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/networking/network/vpc@networking-blueprint-v0.4.0 \
      VPC_NAME
    

    VPC_NAME は、VPC に使用する名前(my-vpc など)に置き換えます。

  2. 新しく作成したディレクトリに移動します。

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

    ファイルで次のフィールドを更新します。実際のプロジェクト ID を入力してください。

      namespace: PROJECT_NAMESPACE
      network-name: VPC_NAME
      project-id: PROJECT_ID
    

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

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

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

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

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

  4. ファイルの末尾に prefix という新しいフィールドを追加します。右インデントに設定されていることを確認します。

      prefix: NAT-PREFIX
    

    NAT-PREFIX は、接頭辞(nat など)で置き換えます。

    これは、VPC を設定するときに NAT 名の接頭辞として使用されます。

    ファイルは以下のようになります。

    apiVersion: v1
    kind: ConfigMap
    metadata: # kpt-merge: /setters
      name: setters
    data:
      namespace: PROJECT_NAMESPACE
      network-name: VPC_NAME
      project-id: PROJECT_ID
      prefix: NAT-PREFIX
    
  5. kpt set-namespace 関数を使用して、ブループリントの名前空間を次のように変更します。

      kpt fn eval --image set-namespace:v0.1 -- namespace=PROJECT_NAMESPACE
    

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

サブネットを構成する

  1. VPC_NAME ディレクトリから、kpt を使用してサブネットワークのブループリントを取得します。

    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/networking/network/subnet@networking-blueprint-v0.4.0 \
      SUBNET_NAME
    

    SUBNET_NAME は、プロジェクト リソースの管理に使用する名前空間に置き換えます(例: gke-subnet)。

  2. サブネット ディレクトリに移動します。

    cd SUBNET_NAME
    
  3. subnet.yaml ファイルを編集して、spec セクションの下でファイルの最後に次のスニペットを追加します。これにより、GKE クラスタの Pod と Service の IP アドレスを割り振るために使用される 2 つの名前付き範囲が定義されます。

      secondaryIpRange:
      - ipCidrRange: 172.17.0.0/16
        rangeName: pods
      - ipCidrRange: 172.18.0.0/16
        rangeName: services
    

    subnet.yaml ファイルは次のようになります。

    apiVersion: compute.cnrm.cloud.google.com/v1beta1
    kind: ComputeSubnetwork
    metadata: # kpt-merge: networking/network-name-subnetwork
      name: network-name-subnetwork # kpt-set: ${prefix}${network-name}-subnetwork
      namespace: networking # kpt-set: ${namespace}
      annotations:
        cnrm.cloud.google.com/project-id: project-id # kpt-set: ${project-id}
        cnrm.cloud.google.com/blueprint: cnrm/landing-zone:networking/v0.4.0
    spec:
      description: Subnetwork
      ipCidrRange: 10.2.0.0/16 # kpt-set: ${ip-cidr-range}
      logConfig:
        metadata: INCLUDE_ALL_METADATA
        aggregationInterval: INTERVAL_10_MIN
        flowSampling: 0.5
      networkRef:
        name: network-name # kpt-set: ${network-name}
      privateIpGoogleAccess: false
      region: us-central1 # kpt-set: ${region}
      secondaryIpRange:
      - ipCidrRange: 172.17.0.0/16
        rangeName: pods
      - ipCidrRange: 172.18.0.0/16
        rangeName: services
    

ブループリントをレンダリングする

ブループリントを適用する前に、レンダリングする必要があります。このステップでは、Kptfile で定義されている関数のパイプラインをブループリントのリソースで実行します。実行できる関数の典型的な例として、前に編集したセッターを適用する apply-setters があります。

  1. 次に、VPC_NAME ディレクトリに戻り、kpt を使用してセッターの値をテンプレート化されたリソースにレンダリングします。

    cd ..
    kpt fn render
    

    出力例を以下に示します。

    [RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
    [PASS] "gcr.io/kpt-fn/apply-setters:v0.1" in 5.4s
      Results:
        [INFO] set field value to "ALL_SUBNETWORKS_ALL_IP_RANGES" in file "nat.yaml" in field "spec.sourceSubnetworkIpRangesToNat"
        [INFO] set field value to "10.2.0.0/16" in file "subnet.yaml" in field "spec.ipCidrRange"
    
    Package "my-vpc":
    [RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
    [PASS] "gcr.io/kpt-fn/apply-setters:v0.1" in 2.3s
      Results:
        [INFO] set field value to "00-my-vpc-router-nat" in file "nat.yaml" in field "metadata.name"
        [INFO] set field value to "config-control" in file "nat.yaml" in field "metadata.namespace"
        [INFO] set field value to "krm-playground-00" in file "nat.yaml" in field "metadata.annotations.cnrm.cloud.google.com/project-id"
        [INFO] set field value to "00-my-vpc-router" in file "nat.yaml" in field "spec.routerRef.name"
        ...(13 line(s) truncated, use '--truncate-output=false' to disable)
    
    Successfully executed 2 function(s) in 2 package(s).
    

構成の変更を適用する

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

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

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

    kpt live init --namespace PROJECT_NAMESPACE
    

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

    initializing Kptfile inventory info (namespace: config-control)...success
    
  2. 作成されるリソースをプレビューします。

    kpt live apply --dry-run
    

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

    出力例:

    computerouter.compute.cnrm.cloud.google.com/my-vpc-router created (dry-run)
    computerouternat.compute.cnrm.cloud.google.com/my-vpc-router-nat created (dry-run)
    computesubnetwork.compute.cnrm.cloud.google.com/my-vpc-subnetwork created (dry-run)
    service.serviceusage.cnrm.cloud.google.com/proj-id-00-compute created (dry-run)
    computenetwork.compute.cnrm.cloud.google.com/my-vpc created (dry-run)
    5 resource(s) applied. 5 created, 0 unchanged, 0 configured, 0 failed (dry-run)
    
  3. kpt を使用してリソースを適用します。

    kpt live apply
    

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

    出力例:

    computenetwork.compute.cnrm.cloud.google.com/my-vpc created
    computerouter.compute.cnrm.cloud.google.com/my-vpc-router created
    computerouternat.compute.cnrm.cloud.google.com/my-vpc-router-nat created
    computesubnetwork.compute.cnrm.cloud.google.com/my-vpc-subnetwork created
    service.serviceusage.cnrm.cloud.google.com/proj-id-00-compute created
    5 resource(s) applied. 5 created, 0 unchanged, 0 configured, 0 failed
    

ネットワーク リソースが正常に作成されたことを確認する

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

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

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

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

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

    出力例:

    NAMESPACE   RESOURCE                                STATUS      CONDITIONS      AGE     MESSAGE
    config-con  ComputeNetwork/my-vpc                   Current     Ready           2m      Resource is Ready
    config-con  ComputeRouter/my-vpc-router             Current     Ready           2m      Resource is Ready
    config-con  ComputeRouterNAT/my-vpc-router-nat      Current     Ready           2m      Resource is Ready
    config-con  ComputeSubnetwork/my-vpc-subnetwork     Current     Ready           2m      Resource is Ready
    config-con  Service/proj-id-00-compute              Current     Ready           2m      Resource is Ready
    
  2. エラーが発生した場合は、デフォルトのイベント出力を使用してエラー メッセージをすべて確認します。

    kpt live status
    

    すべてのリソースが作成され、準備完了になるまで数分かかります。

    ネットワーク リソースが正常に作成されたら、1 つ上のディレクトリに移動して GKE クラスタの構成を開始します。

    cd ..
    

GKE クラスタを構成する

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

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

    kpt pkg get \
        https://github.com/GoogleCloudPlatform/blueprints.git/catalog/gke@gke-blueprint-v0.4.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 name of this cluster
      cluster-name: CLUSTER_NAME
      # The compute location (region for a regional cluster or zone for a zonal cluster)
      location: us-central1
      # The private IP range for masters to use when peering to the VPC
      master-ip-range: 10.254.0.0/28
      # The reference to the network
      network-ref: projects/PROJECT_ID/global/networks/VPC_NAME
      # The reference to the subnet
      subnet-ref: projects/PROJECT_ID/regions/us-central1/subnetworks/subnetwork
      # The namespace in which to manage cluster resources
      platform-namespace: PROJECT_NAMESPACE
      # The project in which to manage cluster resources
      project-id: PROJECT_ID
      # The namespace in which to manage service enablement resources
      projects-namespace: PROJECT_NAMESPACE
      # The private IP range name for Pods to use, this range must already exist
      pods-range-name: pods
      # The private IP range name for services to use, this range must already exist
      services-range-name: services
      # 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 など)。

    • network-ref: クラスタの作成が必要なネットワークへの selfLink 参照。

      次の形式になります。 projects/{network-project-id}/global/networks/{vpc-name}

    • subnet-ref: クラスタの作成が必要なサブネットへの selfLink 参照。

      次の形式になります。 projects/{network-project-id}/regions/{region}/subnetworks/{subnet-name}

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

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

RBAC 向け Google グループの無効化

個人だけでなく Google グループを認証に使用できるよう RBAC を構成しない場合は、RBAC 向け Google グループ機能を無効にするようにクラスタ構成を変更できます。たとえば、gke-security-groups が作成されておらず、その作成権限もない場合、これに該当します。詳しくは、グループの設定をご覧ください。

  1. RBAC 向け Google グループを無効にするには、cluster/cluster.yaml ファイルを直接編集します。

  2. authenticatorGroupsConfig フィールドを含むセクションを見つけて、次の 3 行を削除します。

      # Enable Groups for GKE, to allow role binding to Google Groups.
      authenticatorGroupsConfig:
        securityGroup: gke-security-group@example.com # kpt-set: ${security-group}
    
  3. ファイルを保存します。

    これにより、Google グループの RBAC 機能が無効になります。

ブループリントをレンダリングする

このステップでは、Kptfile で定義されている関数のパイプラインをブループリントのリソースで実行します。通常、これにより、以前に編集したセッターを適用する apply-setters が実行されます。

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

    kpt fn render
    

    出力例:

    Package "example/cluster":
    [RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
    [PASS] "gcr.io/kpt-fn/apply-setters:v0.1" in 3.3s
      Results:
        [INFO] set field value to "example-us-west4" in file "cluster.yaml" in field "metadata.name"
        [INFO] set field value to "config-control" in file "cluster.yaml" in field "metadata.namespace"
        [INFO] set field value to "project-id" in file "cluster.yaml" in field "metadata.annotations.cnrm.cloud.google.com/project-id"
        ...(9 line(s) truncated, use '--truncate-output=false' to disable)
    
    Package "test-00/nodepools/primary":
    [RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
    [PASS] "gcr.io/kpt-fn/apply-setters:v0.1" in 2.2s
      Results:
        [INFO] set field value to "gke-example-us-east4-primary" in file "node-iam.yaml" in field "metadata.name"
        [INFO] set field value to "config-control" in file "node-iam.yaml" in field "metadata.namespace"
        [INFO] set field value to "project-id" in file "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 "node-iam.yaml" in field "spec.displayName"
        ...(23 line(s) truncated, use '--truncate-output=false' to disable)
    
    Package "test-00":
    [RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
    [PASS] "gcr.io/kpt-fn/apply-setters:v0.1" in 2.3s
      Results:
        [INFO] set field value to "test-00" in file "cluster.yaml" in field "metadata.name"
        [INFO] set field value to "config-control" in file "cluster.yaml" in field "metadata.namespace"
        [INFO] set field value to "krm-playground-00" in file "cluster.yaml" in field "metadata.annotations.cnrm.cloud.google.com/project-id"
        ...(36 line(s) truncated, use '--truncate-output=false' to disable)
    
    Successfully executed 3 function(s) in 3 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/proj-id-00-test-00-container created (dry-run)
    containercluster.container.cnrm.cloud.google.com/test-00 created (dry-run)
    containernodepool.container.cnrm.cloud.google.com/test-00-primary created (dry-run)
    iampolicymember.iam.cnrm.cloud.google.com/artifactreader-gke-test-00-primary created (dry-run)
    iampolicymember.iam.cnrm.cloud.google.com/logwriter-gke-test-00-primary created (dry-run)
    iampolicymember.iam.cnrm.cloud.google.com/metricwriter-gke-test-00-primary created (dry-run)
    iamserviceaccount.iam.cnrm.cloud.google.com/gke-test-00-primary created (dry-run)
    7 resource(s) applied. 7 created, 0 unchanged, 0 configured, 0 failed (dry-run)
    
  3. kpt を使用してリソースを適用します。

    kpt live apply
    

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

    出力例:

    iamserviceaccount.iam.cnrm.cloud.google.com/gke-test-00-primary created
    service.serviceusage.cnrm.cloud.google.com/proj-id-00-test-00-container created
    containercluster.container.cnrm.cloud.google.com/test-00 created
    containernodepool.container.cnrm.cloud.google.com/test-00-primary created
    iampolicymember.iam.cnrm.cloud.google.com/artifactreader-gke-test-00-primary created
    iampolicymember.iam.cnrm.cloud.google.com/logwriter-gke-test-00-primary created
    iampolicymember.iam.cnrm.cloud.google.com/metricwriter-gke-test-00-primary created
    7 resource(s) applied. 7 created, 0 unchanged, 0 configured, 0 failed
    

GKE クラスタ リソースが正常に作成されたことを確認する

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

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

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

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

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

    出力例:

    NAMESPACE   RESOURCE                                  STATUS      CONDITIONS      AGE     MESSAGE
    config-con  ContainerCluster/test-00                  Current     Ready           12m     Resource is Ready
    config-con  ContainerNodePool/test-00-primary         Current     Ready           12m     Resource is Ready
    config-con  IAMPolicyMember/artifactreader-gke-test-  Current     Ready           12m     Resource is Ready
    config-con  IAMPolicyMember/logwriter-gke-test-00-pr  Current     Ready           12m     Resource is Ready
    config-con  IAMPolicyMember/metricwriter-gke-test-00  Current     Ready           12m     Resource is Ready
    config-con  IAMServiceAccount/gke-test-00-primary     Current     Ready           12m     Resource is Ready
    config-con  Service/proj-id-00-test-00-contai         Current     Ready           12m     Resource is Ready
    
  2. エラーが発生した場合は、デフォルトのイベント出力を使用してエラー メッセージをすべて確認します。

    kpt live status
    

よくある質問

クリーンアップ

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

  1. GKE クラスタのブループリントの作業ディレクトリから 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 を使用して割り込みを行います。

  3. このチュートリアルで作成したネットワーク リソースを削除します。ブループリント用に作成した VPC ディレクトリから kpt を使用します。

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

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

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

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

次のステップ