自動レンダリングで複数の環境で Config Sync を使用する

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

このチュートリアルでは、Anthos Config Management のベスト プラクティスに従って、開発環境と本番環境の 2 つの環境で Google Kubernetes Engine（GKE）の 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 Sync を、Anthos Config Management サンプル リポジトリの config-source/ ディレクトリ内の構成ファイルと同期するように構成します。そのディレクトリは、次のディレクトリとファイルで構成されています。

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
bases:
- ../../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 ユーザーは無料トライアルをご利用いただける場合があります。

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

始める前に

このチュートリアルを開始する前に、次の手順が完了していることを確認してください。

  1. Google Cloud コンソールのプロジェクト セレクタページで、2 つの Google Cloud プロジェクトを選択または作成します。

    プロジェクト セレクタに移動

  2. Cloud プロジェクトに対して課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。

  3. Google Cloud CLI を最新バージョンにアップグレードします。

  4. nomos コマンドをインストールまたはアップグレードします。

クラスタを作成して登録する

複数の環境用に Config Sync を構成する際に必要となるワークフローに集中できるように、Config Sync の構成を自動化するスクリプトが multi-environments-kustomize ディレクトリに用意されています。

  1. Anthos Config Management のサンプル リポジトリのクローンを作成します。

    git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git

  2. このチュートリアルに必要なリソースが含まれているフォルダに移動します。

    cd anthos-config-management-samples/multi-environments-kustomize/

  3. このチュートリアルで使用するスクリプトを実行できるように、次の変数を設定します。

    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 プロジェクトのプロジェクト ID
    • PROD_PROJECT_ID: 本番環境プロジェクトとして使用する Google Cloud プロジェクトのプロジェクト ID
    • DEV_CLUSTER_ZONE: 開発環境クラスタを作成する Compute Engine ゾーン。例: us-central1-c
    • PROD_CLUSTER_ZONE: 本番環境クラスタを作成する Compute Engine ゾーン

  4. ./create-clusters.sh スクリプトを実行して、2 つのクラスタを作成します。

    ./create-clusters.sh

    このスクリプトを実行すると、dev プロジェクトに dev という名前の GKE クラスタが作成され、prod プロジェクトに prod という名前の GKE クラスタが作成されます。また、GKE と Anthos API が有効になり、dev クラスタと prod クラスタに接続します。これにより、kubectl で API にアクセスできるようになります。

    出力例:

    kubeconfig entry generated for dev.
Fetching cluster endpoint and auth data.
kubeconfig entry generated for prod.
⭐️ Done creating clusters.

  5. register-clusters.sh スクリプトを実行して、クラスタを 2 つの Anthos フリートに登録します。

    ./register-clusters.sh

    このスクリプトを実行すると、Anthos クラスタ登録用に Google Cloud サービス アカウントとキーが作成されます。このアカウントとキーが作成されたら、gcloud container fleet memberships register コマンドを使用して、それぞれのプロジェクトで dev クラスタと prod クラスタが Anthos に登録されます。

    出力例:

    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 がリポジトリ内の構成ファイルと同期されました。

構成を確認する

このセクションでは、クラスタがリポジトリ内の構成ファイルと同期されていることを確認します。

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

  ```

  2. kubectl を使用して開発環境クラスタに切り替えます。

    kubectl config use-context "gke_${DEV_PROJECT}_${DEV_CLUSTER_ZONE}_dev"

  3. リソースが同期されていることを確認するため、名前空間を取得します。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

プロジェクトを削除する

  1. Google Cloud コンソールで、[リソースの管理] ページに移動します。

    [リソースの管理] に移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ