このクイックスタートでは、foo-corp example repo を使用して Config Sync を新しいクラスタで起動し、一連の構成を使用してクラスタをブートストラップする方法について説明します。このクイックスタートでは、リポジトリへの書き込み権限は必要ありません。以下では、組織のコンプライアンス チームが構成の作成を担当し、クラスタをリポジトリと同期する必要があることを前提として説明します。
このクイックスタートを終了すると、構成の作成、テスト、同期に関する上級クイックスタートに進むことができます。
始める前に
クラスタの認証を行うように
kubectl
コマンドを設定します。次のコマンドを実行して、自分自身をクラスタ管理者にする RoleBinding を作成します。[MY-CLUSTER]
にあるクラスタ名を使用し、[USER-ACCOUNT] にある Cloud 請求先アカウントのメールアドレスを使用します。ローカル システムでのgcloud
コマンドの構成方法によっては、--project
フィールドと--zone
フィールドの追加が必要になる場合があります。gcloud container clusters get-credentials [MY-CLUSTER] kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole cluster-admin --user [USER_ACCOUNT]
ローカル システムに
nomos
コマンドをインストールします。作成したクラスタに Config Sync Operator をインストールします。
クラスタを構成する
config-management.yaml
を作成し、下の YAML をコピーします。リポジトリは読み取り制限がないので、secretType
は none
に設定されています。フィールドの詳細については、Git リポジトリの構成をご覧ください。
apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
name: config-management
spec:
# clusterName is required and must be unique among all managed clusters
clusterName: my-cluster
git:
syncRepo: https://github.com/GoogleCloudPlatform/csp-config-management/
syncBranch: 1.0.0
secretType: none
policyDir: "foo-corp"
クラスタに構成を適用します。
kubectl apply -f config-management.yaml
コマンドが成功すると、Kubernetes はクラスタの Config Sync Operator を更新し、リポジトリからのクラスタ構成の同期を開始します。Config Sync Operator が実行されていることを確認するには、config-management-system
名前空間で実行されている Pod のリストを取得します。
kubectl get pods -n config-management-system
出力:
NAME READY STATUS RESTARTS AGE
git-importer-5f8bdb59bd-7nn5m 2/2 Running 0 2m
monitor-58c48fbc66-ggrmd 1/1 Running 0 2m
syncer-7bbfd7686b-dxb45 1/1 Running 0 2m
クラスタとリポを調べる
foo-corp
リポジトリの cluster/
ディレクトリと namespaces/
ディレクトリに構成ファイルが配置されています。リポジトリから読み取るように Config Sync Operator が構成されるとすぐに、これらの構成ファイルが適用されます。
Config Sync で管理されるオブジェクトの app.kubernetes.io/managed-by
ラベルは configmanagement.gke.io
に設定されています。
次のコマンドを実行して、Config Sync で管理されている名前空間の一覧を取得します。
kubectl get ns -l app.kubernetes.io/managed-by=configmanagement.gke.io
出力:
NAME STATUS AGE
audit Active 4m
shipping-dev Active 4m
shipping-prod Active 4m
shipping-staging Active 4m
これらの名前空間を作成した構成ファイル(namespaces/audit/namespace.yaml
、namespaces/online/shipping-app-backend/shipping-dev/namespace.yaml
など)を調べます。
次のコマンドを実行して、Config Sync で管理されている ClusterRoles の一覧を取得します。
kubectl get clusterroles -l app.kubernetes.io/managed-by=configmanagement.gke.io
出力:
NAME AGE
namespace-reader 6m52s
pod-creator 6m52s
ClusterRole の構成ファイルの宣言を調べます。
cluster/namespace-reader-clusterrole.yaml
cluster/pod-creator-clusterrole.yaml
同じ方法で Roles や PodSecurityPolicies などの他のオブジェクトも検証できます。
マネージド オブジェクトを手動で変更しようとした場合
Config Sync によって管理されている Kubernetes オブジェクトを手動で変更すると、そのオブジェクトの構成は、リポジトリ内のオブジェクトの構成ファイルと一致するよう自動的に更新されます。これをテストするには、shipping-dev
名前空間を削除します。
kubectl delete namespace shipping-dev
すぐに確認すると、この名前空間がリストから消えたことがわかりますが、数秒以内に再びリストに現れます。例:
kubectl get ns shipping-dev
出力:
Error from server (NotFound): namespaces "shipping-dev" not found
数秒後に次のコマンドを実行します。
kubectl get ns shipping-dev
出力:
NAME STATUS AGE
shipping-dev Active 3s
クリーンアップ
このトピックの演習を終えたら、テストに使用したクラスタを削除してクリーンアップ作業を行います。
次のステップ
- 構成ファイルの作成、テスト、同期に関する上級クイックスタートに進む。
- 構成ファイルの作成方法について学ぶ。
- 構成ファイルの検証について詳細を確認する。