このチュートリアルでは、Config Sync のベスト プラクティスに従って、開発環境と本番環境の 2 つの環境で Google Kubernetes Engine（GKE）Enterprise エディションの Config Sync を設定する方法について説明します。
このシナリオでは、Foo Corp のプラットフォーム管理を例にして説明します。このプラットフォーム管理チームでは、Foo Corp アプリケーションを GKE Enterprise にデプロイし、リソースを dev と prod の 2 つのプロジェクトに分割しています。dev プロジェクトには開発環境用の GKE Enterprise クラスタが含まれ、prod プロジェクトには本番環境用の GKE Enterprise クラスタが含まれています。プラットフォーム管理者は、両方の環境が Foo Corp のポリシーを遵守し、両方の環境で基本レベルのリソース（Kubernetes の Namespace やサービス アカウントなど）の整合性を維持することを目標としています。
次の図は、このチュートリアルで設定する環境の概要を示しています。
このチュートリアルでは、Config Sync の自動レンダリング機能を利用して、クラスタ上のリソースをレンダリングします。各クラスタは、Kustomization 構成ファイルを含むディレクトリから同期するように構成されています。これにより、Config Sync でレンダリング プロセスが自動的にトリガーされます。詳細については、Kustomize 構成と Helm チャートが配置されたリポジトリを使用するをご覧ください。
上の図のように、このチュートリアルでは次のリソースを作成します。
- 2 つの Google Cloud プロジェクト（開発環境用と本番環境用）。
- Config Sync がインストールされている別々のプロジェクトに 2 つの GKE Enterprise クラスタ（
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
目標
- 2 つの異なる環境の構成を自動的にレンダリングして同期するように Config Sync を設定します。
費用
このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。
始める前に
このチュートリアルを開始する前に、次の手順が完了していることを確認してください。
Google Cloud コンソールのプロジェクト セレクタページで、2 つの Google Cloud プロジェクトを選択または作成します。
-
Make sure that billing is enabled for your Google Cloud project.
Google Cloud CLI を最新バージョンにアップグレードします。
nomosコマンドをインストールまたはアップグレードします。
クラスタを作成して登録する
複数の環境に 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 Enterprise クラスタが作成され、prod プロジェクトにprodという名前の GKE Enterprise クラスタが作成されます。また、GKE Enterprise 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 Enterprise クラスタの登録用に Google Cloud サービス アカウントとキーが作成されます。このアカウントとキーが作成されたら、
gcloud container fleet memberships registerコマンドを使用して、それぞれのプロジェクトでdevクラスタとprodクラスタが GKE Enterprise に登録されます。出力例:
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 プロジェクトと環境で、開発環境と本番環境の構成ファイルが自動的にレンダリングされるようになりました。
クリーンアップ
このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。
すべてのリソースを削除する
このチュートリアルで作成したリソースを削除して、開発環境プロジェクトと本番環境プロジェクトの両方をそのまま保持するには、クリーンアップ スクリプトを実行します。
./cleanup.sh
プロジェクトを削除する
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
次のステップ
- Config Sync を使用した安全なロールアウトについて学習する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。