このチュートリアルでは、Config Controller でプロジェクトの名前空間ブループリントを使用して、特定のプロジェクトの Google Cloud リソースを管理する専用の名前空間を作成する方法を説明します。インフラストラクチャ管理者が、内部テナントにプロジェクト構成を宣言的に管理することを許可する場合は、この手順を行ってください。
Config Controller は、Anthos リソースと Google Cloud リソースをプロビジョニングし、オーケストレートするホスト型サービスです。Anthos Config Management の一部として、Google Cloud リソースのプロビジョニング、有効化、オーケストレートを行える API エンドポイントが用意されています。
KRM ブループリントを使用すると、組織全体でロールアウトできるベスト プラクティスをコード化しながら、一緒によく使用されるリソースをパッケージ化できます。
プロジェクトの名前空間ブループリントは、お客様またはテナントが Google Cloud プロジェクト リソースを管理可能な名前空間を Config Controller にプロビジョニングするために必要なすべてのリソースを含む KRM ブループリントです。複数のプロジェクトの名前空間を設定するには、ブループリントを複数回インスタンス化します。
プロジェクトの名前空間ブループリントを使用すると、1 つ以上のプロジェクトの名前空間を簡単に管理できますが、gcloud command-line tool
目標
- Config Controller でプロジェクトの名前空間を構成します。
kpt live applyを使用して構成を適用します。
費用
このチュートリアルでは、課金対象である次の Google Cloud コンポーネントを使用します。
プロジェクトの名前空間ブループリントに含まれるリソースの完全なリストについては、プロジェクトの名前空間ブループリント パッケージのリソース セクションをご覧ください。
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
このチュートリアルを終了した後、作成したリソースを削除すると、それ以上の請求は発生しません。詳しくは、クリーンアップをご覧ください。
要件
Config Controller インスタンスが必要です。
Google Cloud プロジェクトが必要です。これは、プロジェクトの名前空間が管理するテナント プロジェクトです。
テナント プロジェクトに対して課金を有効にする必要があります。
始める前に
-
Cloud Console で、Cloud Shell をアクティブにします。
Cloud Console の下部にある Cloud Shell セッションが開始し、コマンドライン プロンプトが表示されます。Cloud Shell はシェル環境です。
gcloudコマンドライン ツールなどの Cloud SDK がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。
このチュートリアルでは、すべてのコマンドを Cloud Shell から実行します。
環境を設定する
Cloud Shell で、次のコマンドを実行します。
Kubernetes の基本的なコマンドライン インターフェースである
kubectlをインストールします。gcloud components install kubectlKRM ブループリントの基本的なコマンドライン インターフェースである
kptをインストールします。gcloud components install kptConfig Controller に接続するように
kubectlとkptを構成します。gcloud alpha anthos config controller get-credentials INSTANCE_NAME \ --location COMPUTE_REGION \ --project ADMIN_PROJECT_ID次のように置き換えます。
INSTANCE_NAME: Config Controller インスタンスの名前。COMPUTE_REGION: Config Controller インスタンスのリージョン（例:us-central1）。ADMIN_PROJECT_ID: Config Controller インスタンスのプロジェクト ID。
Resource Manager API を有効にします。
Resource Manager API は、Config Connector で他のサービス API の有効化を管理するために使用されます。
gcloud services enable cloudresourcemanager.googleapis.com \ --project TENANT_PROJECT_IDTENANT_PROJECT_IDは、プロジェクトの ID に置き換えます。ResourceGroup CRD がまだインストールされていない場合は、インストールします。
kpt live install-resource-groupConfig Connector が
config-controlで構成され、正常な状態であることを確認します。kubectl get ConfigConnectorContext -n config-control \ -o "custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,HEALTHY:.status.healthy"予想される出力:
NAMESPACE NAME HEALTHY config-control configconnectorcontext.core.cnrm.cloud.google.com trueテナント プロジェクト内の Google Cloud リソースを管理する権限を Config Controller に付与します。
export TENANT_PROJECT_ID=TENANT_PROJECT_ID export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \ -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)" gcloud projects add-iam-policy-binding "${TENANT_PROJECT_ID}" \ --member "serviceAccount:${SA_EMAIL}" \ --role "roles/owner" \ --project "${TENANT_PROJECT_ID}"
プロジェクトの名前空間を構成する
次のコマンドを実行して、別のプロジェクトのリソースを管理するプロジェクト名前空間を作成します。
kptを使用して、目的の作業ディレクトリからプロジェクトの名前空間ブループリントを取得します。kpt pkg get \ https://github.com/GoogleCloudPlatform/blueprints.git/catalog/project/kcc-namespace@main \ TENANT_PROJECT_IDTENANT_PROJECT_IDは、プロジェクトの ID に置き換えます。このブループリントでは、プロジェクト ID はプロジェクトの名前空間の名前としても使用されます。
パッケージ ディレクトリに移動します。
cd ./TENANT_PROJECT_ID/setters.yamlファイルを変更してパッケージを構成します。cat > setters.yaml << EOF apiVersion: v1 kind: ConfigMap metadata: name: setters data: project-id: TENANT_PROJECT_ID management-project-id: ADMIN_PROJECT_ID management-namespace: ADMIN_NAMESPACE projects-namespace: PROJECTS_NAMESPACE networking-namespace: NETWORKING_NAMESPACE EOF次のように置き換えます。
ADMIN_PROJECT_ID: Config Controller クラスタが含まれているプロジェクトの ID。管理プロジェクトは、Config Connector Workload Identity をブートストラップするために使用されます。
ADMIN_NAMESPACE: プロジェクトの名前空間の管理に使用する名前空間（例:config-control）。管理名前空間は、管理プロジェクトの Config Connector Workload Identity をブートストラップするために使用されます。
PROJECTS_NAMESPACE: プロジェクトの権限管理に使用する名前空間（例:config-control）。プロジェクトの名前空間は IAM ポリシーなどの管理に使用されるため、テナント名前空間にアクセスできるテナントは権限をエスカレーションできません。
ランディング ゾーンのブループリントを使用した場合は、プロジェクトを管理する
projects名前空間がすでに作成されています。ない場合は、config-controlに設定します。NETWORKING_NAMESPACE: 共有 VPC の管理に使用される名前空間（例:config-control）。これにより、使用するネットワークまたはサブネットを選択する際に、名前空間をまたいだリソース参照を使用できます。
ランディング ゾーンのブループリントを使用した場合は、共有 VPC を管理するための
networking名前空間がすでに用意されています。ない場合は、config-controlに設定します。
テンプレート化されたリソースにセッター値をレンダリングします。
kpt fn render出力例:
Package "example-1234": [RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1" [PASS] "gcr.io/kpt-fn/apply-setters:v0.1" Results: [INFO] set field value to "cnrm-network-viewer-example-1234" in file "kcc-namespace-viewer.yaml" in field "metadata.name" [INFO] set field value to "config-control" in file "kcc-namespace-viewer.yaml" in field "metadata.namespace" [INFO] set field value to "cnrm-controller-manager-example-1234" in file "kcc-namespace-viewer.yaml" in field "subjects[0].name" [INFO] set field value to "cnrm-project-viewer-example-1234" in file "kcc-namespace-viewer.yaml" in field "metadata.name" ...(20 line(s) truncated, use '--truncate-output=false' to disable) Successfully executed 1 function(s) in 1 package(s).
テナントの権限を構成する
テナント プロジェクトに Google Cloud プロジェクトのリソースをプロビジョニングできるようにするには、次のコマンドでテナント プロジェクトの名前空間の使用権限を付与します。
次の
RoleBindingを含むproject-admin.yamlファイルを作成します。cat > project-admin.yaml << EOF apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: project-admin namespace: TENANT_PROJECT_ID roleRef: kind: ClusterRole name: cnrm-admin apiGroup: rbac.authorization.k8s.io subjects: - kind: User name: TENANT_EMAIL apiGroup: rbac.authorization.k8s.io EOFTENANT_EMAILは、テナント Google Cloud ユーザー アカウントのメールアドレス（janedoe@example.comなど）に置き換えます。cnrm-adminロールを使用すると、テナントはプロジェクトの名前空間に Config Connector リソースを作成できます。グループまたはサービス アカウントを承認する方法については、RoleBinding または ClusterRoleBinding を使用したロールの割り当てをご覧ください。
構成の変更を適用する
前の手順で行ったローカルの変更は、適用されるまでクラウドには反映されません。
構成の変更を適用するには、次のコマンドを実行します。
kpt を使用して作業ディレクトリを初期化します。これにより、変更を追跡するためのリソースが作成されます。
kpt live init --namespace ADMIN_NAMESPACEADMIN_NAMESPACEは、プロジェクトの名前空間の管理に使用する名前空間に置き換えます（例:config-control）。作成されるリソースをプレビューします。
kpt live apply --dry-runすべてのリソースが「created（dry-run）」と表示されているはずです。
出力例:
namespace/example-1234 created (dry-run) rolebinding.rbac.authorization.k8s.io/cnrm-network-viewer-example-1234 created (dry-run) rolebinding.rbac.authorization.k8s.io/cnrm-project-viewer-example-1234 created (dry-run) rolebinding.rbac.authorization.k8s.io/project-admin created (dry-run) configconnectorcontext.core.cnrm.cloud.google.com/configconnectorcontext.core.cnrm.cloud.google.com created (dry-run) iampartialpolicy.iam.cnrm.cloud.google.com/example-1234-sa-workload-identity-binding created (dry-run) iampartialpolicy.iam.cnrm.cloud.google.com/kcc-example-1234-owners-permissions created (dry-run) iamserviceaccount.iam.cnrm.cloud.google.com/kcc-example-1234 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)kptでリソースを適用します。kpt live applyすべてのリソースが「created」と表示されているはずです。
出力例:
namespace/example-1234 created rolebinding.rbac.authorization.k8s.io/cnrm-network-viewer-example-1234 created rolebinding.rbac.authorization.k8s.io/cnrm-project-viewer-example-1234 created rolebinding.rbac.authorization.k8s.io/project-admin created configconnectorcontext.core.cnrm.cloud.google.com/configconnectorcontext.core.cnrm.cloud.google.com created iampartialpolicy.iam.cnrm.cloud.google.com/example-1234-sa-workload-identity-binding created iampartialpolicy.iam.cnrm.cloud.google.com/kcc-example-1234-owners-permissions created iamserviceaccount.iam.cnrm.cloud.google.com/kcc-example-1234 created 8 resource(s) applied. 8 created, 0 unchanged, 0 configured, 0 failed 0 resource(s) pruned, 0 skipped, 0 failed
成功を検証する
変更が適用され、指定したリソースがプロビジョニングされていることを確認するには、次のコマンドを実行します。
リソースの準備ができるまで待ちます。
kpt live status --output table --poll-until currentこのコマンドは、すべてのリソースのステータスが
Currentで、条件がReadyまたは<None>（Ready 条件をサポートしていないリソースの場合）になるまでポーリングします。Readyは、Ready = true の場合は緑色、Ready = false の場合は赤色になります。必要に応じて、
ctrl-cを使用して割り込みを行います。出力例:
NAMESPACE RESOURCE STATUS CONDITIONS AGE MESSAGE Namespace/example-1234 Current <None> 13s Resource is current config-con IAMPartialPolicy/example-1234-sa-workloa Current Ready 11s Resource is Ready config-con IAMPartialPolicy/kcc-example-1234-owners Current Ready 11s Resource is Ready config-con IAMServiceAccount/kcc-example-1234 Current Ready 11s Resource is Ready config-con RoleBinding/cnrm-network-viewer-example- Current <None> 13s Resource is current config-con RoleBinding/cnrm-project-viewer-example- Current <None> 12s Resource is current example-12 ConfigConnectorContext/configconnectorco Current <None> 12s Resource is current example-12 RoleBinding/project-admin Current <None> 12s Resource is currentエラーが発生した場合は、デフォルトのイベント出力を使用してエラー メッセージをすべて確認します。
kpt live status
クリーンアップ
Config Controller の使用を停止する場合は、Config Controller で作成したすべてのリソースをクリーンアップしてから Config Controller を削除する必要があります。
kptを使用して、作業ディレクトリからリソースを削除します。kpt live destroyすべてのリソースが削除されるまで待ちます。
until [ -z "$(kubectl get -R -f . --ignore-not-found | tee /dev/fd/2)" ]; \ do sleep 1; doneこのコマンドは、すべてのリソースのステータスが
Deletedになるまでポーリングします。必要に応じて、
ctrl-cを使用して割り込みを行います。
次のステップ
- 他のブループリント チュートリアルを確認する。
- KRM ブループリント カタログを参照する。