このチュートリアルでは、Config Sync のベスト プラクティスに従って、開発環境と本番環境の 2 つの環境で Google Kubernetes Engine の Config Sync を設定する方法について説明します。
このシナリオでは、Foo Corp のプラットフォーム管理を例にして説明します。このプラットフォーム管理チームでは、Foo Corp アプリケーションを GKE にデプロイし、リソースを dev と prod の 2 つのプロジェクトに分割しています。dev プロジェクトには開発環境用の GKE クラスタが含まれ、prod プロジェクトには本番環境用の GKE クラスタが含まれています。プラットフォーム管理者は、両方の環境が Foo Corp のポリシーを遵守し、両方の環境で基本レベルのリソース（Kubernetes の Namespace やサービス アカウントなど）の整合性を維持することを目標としています。
次の図は、このチュートリアルで設定する環境の概要を示しています。
このチュートリアルでは、Config Sync の自動レンダリング機能を利用して、クラスタ上のリソースをレンダリングします。各クラスタは、Kustomization 構成ファイルを含むディレクトリから同期するように構成されています。これにより、Config Sync でレンダリング プロセスが自動的にトリガーされます。詳細については、Kustomize 構成と Helm チャートが配置されたリポジトリを使用するをご覧ください。
上の図のように、このチュートリアルでは次のリソースを作成します。
- 2 つの Google Cloud プロジェクト（開発環境用と本番環境用）。
- Config Sync がインストールされている別々のプロジェクトに 2 つの GKE クラスタ（
devとprod）。
リポジトリのアーキテクチャ
このチュートリアルでは、サンプル リポジトリの config-source/ ディレクトリ内の構成ファイルと同期するように Config Sync を構成します。このディレクトリは、次のディレクトリとファイルで構成されています。
config-source/
├── base
│ ├── foo
│ │ ├── kustomization.yaml
│ │ ├── namespace.yaml
│ │ └── serviceaccount.yaml
│ ├── kustomization.yaml
│ ├── pod-creator-clusterrole.yaml
│ └── pod-creator-rolebinding.yaml
├── cloudbuild.yaml
├── overlays
│ ├── dev
│ │ └── kustomization.yaml
│ └── prod
│ └── kustomization.yaml
└── README.md
config-source ディレクトリには、base/ マニフェストと、dev/ および prod/ Kustomize オーバーレイが含まれます。各ディレクトリには kustomization.yaml ファイルが含まれています。このファイルには、Kustomize が管理してクラスタに適用する必要があるファイルが記述されています。dev/kustomization.yaml と prod/kustomization.yaml では、一連のパッチが定義されています。これらのパッチは、特定の環境用の base/ リソースを操作します。
たとえば、dev RoleBinding は、すべての Foo Corp デベロッパーに Dev クラスタへの Pod のデプロイを許可しますが、prod RoleBinding は、継続的デプロイ エージェント deploy-bot@foo-corp.com にのみ本番環境への Pod を許可します。
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
patches:
# ServiceAccount - make name unique per environ
- target:
kind: ServiceAccount
name: foo-ksa
patch: |-
- op: replace
path: /metadata/name
value: foo-ksa-dev
- op: replace
path: /metadata/namespace
value: foo-dev
# Pod creators - give all Foo Corp developers access
- target:
kind: RoleBinding
name: pod-creators
patch: |-
- op: replace
path: /subjects/0/name
value: developers-all@foo-corp.com
commonLabels:
environment: dev
クラスタを作成して登録する
複数の環境に Config Sync を構成する際に必要となるワークフローに集中できるように、Config Sync の構成を自動化するスクリプトが multi-environments-kustomize ディレクトリに用意されています。
サンプル リポジトリのクローンを作成します。
git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.gitこのチュートリアルに必要なリソースが含まれているフォルダに移動します。
cd anthos-config-management-samples/multi-environments-kustomize/このチュートリアルで使用するスクリプトを実行できるように、次の変数を設定します。
export DEV_PROJECT="DEV_PROJECT_ID" export PROD_PROJECT="PROD_PROJECT_ID" export DEV_CLUSTER_ZONE="DEV_CLUSTER_ZONE" export PROD_CLUSTER_ZONE="PROD_CLUSTER_ZONE" export CM_CONFIG_DIR="config-sync-rendering"次のように置き換えます。
DEV_PROJECT_ID: 開発環境プロジェクトとして使用するGoogle Cloud プロジェクトのプロジェクト IDPROD_PROJECT_ID: 本番環境プロジェクトとして使用するGoogle Cloud プロジェクトのプロジェクト IDDEV_CLUSTER_ZONE: 開発環境クラスタを作成する Compute Engine ゾーン。例:us-central1-cPROD_CLUSTER_ZONE: 本番環境クラスタを作成する Compute Engine ゾーン
./create-clusters.shスクリプトを実行して、2 つのクラスタを作成します。./create-clusters.shこのスクリプトを実行すると、dev プロジェクトに
devという名前の GKE クラスタが作成され、prod プロジェクトにprodという名前の GKE クラスタが作成されます。また、GKE API が有効になり、devクラスタとprodクラスタに接続します。これにより、kubectlで API にアクセスできるようになります。出力例:
kubeconfig entry generated for dev. Fetching cluster endpoint and auth data. kubeconfig entry generated for prod. ⭐️ Done creating clusters.register-clusters.shスクリプトを実行して、クラスタを 2 つのフリートに登録します。./register-clusters.shこのスクリプトを実行すると、GKE クラスタの登録用に Google Cloud サービス アカウントとキーが作成されます。スクリプトは次にコマンド
gcloud container fleet memberships registerを使用して、それぞれのプロジェクトでdevクラスタとprodクラスタを GKE に登録します。出力例:
Waiting for Feature Config Management to be created...done. ⭐️ Done registering clusters.
Config Sync の設定
クラスタを作成して登録できたので、Config Sync をインストールして確認します。
Config Sync のインストール
Config Sync をインストールするには、開発環境クラスタと本番環境クラスタで、install-config-sync.sh スクリプトを実行します。
./install-config-sync.sh
予想される出力:
🔁 Installing ConfigSync on the dev cluster...
Updated property [core/project].
Switched to context "DEV_CLUSTER".
Waiting for Feature Config Management to be updated...done.
🔁 Installing ConfigSync on the prod cluster...
Updated property [core/project].
Switched to context "PROD_CLUSTER".
Waiting for Feature Config Management to be updated...done.
これで Config Sync がリポジトリ内の構成ファイルと同期されました。
構成を確認する
このセクションでは、クラスタがリポジトリ内の構成ファイルと同期されていることを確認します。
nomos statusコマンドを実行して、Config Sync のインストール状態を確認します。nomos statusこれで、開発環境クラスタと本番環境クラスタの両方がそれぞれのリポジトリと同期されます。
gke_DEV_PROJECT_ID_us-central1-c_dev -------------------- <root> https://github.com/GoogleCloudPlatform/anthos-config-management-samples/multi-environments-kustomize/config-source/overlays/dev@main SYNCED 8f2e196f Managed resources: NAMESPACE NAME STATUS clusterrole.rbac.authorization.k8s.io/pod-creator Current namespace/default Current namespace/foo Current default rolebinding.rbac.authorization.k8s.io/pod-creators Current foo serviceaccount/foo-ksa-dev Current *gke_PROD_PROJECT_ID_us-central1-c_prod -------------------- <root> https://github.com/GoogleCloudPlatform/anthos-config-management-samples/multi-environments-kustomize/config-source/overlays/prod@main SYNCED c91502ee Managed resources: NAMESPACE NAME STATUS clusterrole.rbac.authorization.k8s.io/pod-creator Current namespace/default Current namespace/foo Current default rolebinding.rbac.authorization.k8s.io/pod-creators Current foo serviceaccount/foo-ksa-prod Current ```kubectlを使用して開発環境クラスタに切り替えます。kubectl config use-context "gke_${DEV_PROJECT}_${DEV_CLUSTER_ZONE}_dev"リソースが同期されていることを確認するため、名前空間を取得します。
foo名前空間が表示されます。kubectl get namespace出力例:
NAME STATUS AGE config-management-monitoring Active 9m38s config-management-system Active 9m38s default Active 47h foo Active 9m5s kube-node-lease Active 47h kube-public Active 47h kube-system Active 47h resource-group-system Active 9m30sこれで、複数の Google Cloud プロジェクトと環境で、開発環境と本番環境の構成ファイルが自動的にレンダリングされるようになりました。