Kustomize と Helm で Config Sync を使用する

このチュートリアルでは、Helm チャートを参照する Kustomize の構成をリポジトリに追加し、Config Sync を使用してクラスタをリポジトリと同期します。

重要用語: Kustomize は、Kubernetes オブジェクト YAML ファイルをカスタマイズするためのスタンドアロン ツールであり、kubectl コマンドライン ツールの機能です。Config Sync は、構造化されていない信頼できる情報源に保存されている Kustomize 構成を自動的にレンダリングできます。Config Sync と Kustomize をともに使用する方法については、Kustomize で Kubernetes を構成するをご覧ください。

Config Sync を使用すると、Git リポジトリに配置した Kustomize 構成と Helm チャートが自動的にレンダリングされます。自動レンダリングには、次の利点があります。

• 外部ハイドレーション パイプラインが不要になります。自動レンダリングを使用しない場合は、ワークステーションで Kustomize と Helm を使用して構成を手動でレンダリングするか、CI システムでハイドレーション プロセスをトリガーするステップを設定する必要があります。自動レンダリングでは、Config Sync がこの実行を処理します。

• メンテナンス費用が削減されます。自動レンダリングを使用しない場合は、元の Kustomize 構成と Helm チャートを格納した Git リポジトリと、外部ハイドレーションによって生成された出力を格納した Git リポジトリを各一つ維持する必要があります。次に、レンダリングされた出力を格納した Git リポジトリから同期するように Config Sync を構成する必要があります。自動レンダリングを使用する場合は、元の構成ファイルを含むリポジトリを一つ維持するだけで済みます。

• 開発ワークフローが簡易化されます。自動レンダリングを使用しない場合、元の構成ファイルに変更を加えると、マージする前に 2 回確認する必要があります。1 回目は元のリポジトリで、2 回目はレンダリングされたリポジトリで確認が必要です。自動レンダリングを使用する場合は、レンダリングされた構成ファイルは Config Sync によって生成されるため、元の構成ファイルに加えられた変更を確認するだけで済みます。

注: Config Sync では、カスタム Kustomize プラグインを除いて、すべてのネイティブ Kustomize 構成がサポートされます。Config Sync では、プライベート リポジトリからの Kustomize リモートベースの pull はサポートされていません。Kustomize プラグインは、セキュリティに懸念があるため、サポートされていません。

目標

• 既製の Helm チャートを参照する Kustomize 構成を配置したリポジトリを cert-manager 用に構成します。cert-manager は、証明書の管理に役立つ Kubernetes 用のツールです。
• 作成した構成ファイルをプレビューして検証します。
• Config Sync を使用してチャートを自動的にレンダリングし、クラスタをリポジトリに同期します。
• インストールが成功したことを確認します。

費用

このドキュメントでは、課金対象である次の Google Cloudコンポーネントを使用します。

• Google Kubernetes Engine

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。

新規の Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

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

始める前に

1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Roles required to select or create a project

   • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
   • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

2. Verify that billing is enabled for your Google Cloud project.

3. Config Sync の要件を満たし、次の Config Sync の設定を使用しているクラスタを作成するか、このクラスタにアクセスできることを確認します。
   • 非構造化リポジトリを使用します。
   • RootSync API と RepoSync API が有効になっています。
   • spec.override.enableShellInRendering を true に設定し、Config Sync がレンダリング プロセスで公開リポジトリからリモートベースを pull できるようにします。
4. フリートにクラスタを登録します。
5. nomos コマンドライン ツールをインストールします。すでに nomos ツールがインストールされている場合は、バージョン 1.9.0 以降にアップグレードしてください。
6. Helm をインストールします。

また、Git、Kustomize、Helm にある程度習熟することも役立ちます。

リポジトリを構成する

次のタスクでは、Kustomize 構成と Helm チャートを組み合わせた構成ファイルを使用して、Git リポジトリを準備する方法を示します。

1. Git リポジトリを作成するか、Git リポジトリにアクセスできることを確認します。リポジトリでは Kustomize と Helm を使用しているため、これは非構造化リポジトリである必要があります。

2. Git リポジトリのルートで、kustomization.yaml という名前のファイルを作成して次のコードを貼り付けます。

   # ./kustomization.yaml
   resources:
   - base
   
   patches:
   - path: ignore-deployment-mutation-patch.yaml
     target:
       kind: Deployment
   

   このファイルは Kustomize ベースを指す Kustomize オーバーレイです。このオーバーレイには、すべての Deployment オブジェクトに client.lifecycle.config.k8s.io/mutation: ignore アノテーションを追加する、Helm チャートのベースに対するパッチが含まれています。アノテーションが作成されると、Config Sync はクラスタ内のオブジェクトに対して競合する変更を無視するようになります。

3. Git リポジトリに base という名前のディレクトリを作成します。

   mkdir base
   

4. base ディレクトリに kustomization.yaml という名前の別のファイルを作成して次のコードを貼り付けます。

   # ./base/kustomization.yaml
   helmCharts:
   - name: cert-manager
     repo: https://charts.jetstack.io
     version: v1.5.3
     releaseName: my-cert-manager
     namespace: cert-manager
   

   このファイルは Kustomize ベースで、リモート Helm チャートをレンダリングします。

5. Git リポジトリのルートに戻り、ignore-deployment-mutation-patch.yaml という名前のファイルを作成して次のコードを貼り付けます。

   # ./ignore-deployment-mutation-patch.yaml
   apiVersion: apps/v1
   kind: Deployment
   metadata:
    name: any
    annotations:
      client.lifecycle.config.k8s.io/mutation: ignore
   

   このファイルは、ベースの Helm チャートに適用されるパッチです。client.lifecycle.config.k8s.io/mutation: ignore アノテーションがベース ディレクトリ内のすべての Deployment に追加されます。

6. 変更をリポジトリに commit します。

   git add .
   git commit -m 'Set up manifests.'
   git push
   

サンプル リポジトリには、このようなリポジトリのサンプルがあります。

レンダリングされた構成ファイルをプレビューして検証する

Config Sync が構成ファイルをレンダリングしてクラスタに同期する前に、構成ファイルが正確であることを確認します。それには、nomos hydrate を実行してレンダリングされた構成ファイルをプレビューし、nomos vet を実行して形式が正しいことを検証します。

1. 次のフラグを使用して、次の nomos hydrate を実行します。

   nomos hydrate \
       --source-format=unstructured \
       --output=OUTPUT_DIRECTORY
   

   コマンドの内容:

   • --source-format=unstructured を使用すると、nomos hydrate は非構造化リポジトリで機能できます。Kustomize の構成と Helm チャートを使用しているため、非構造化リポジトリを使用してこのフラグを追加する必要があります。
   • --output=OUTPUT_DIRECTORY を使用すると、レンダリングされた構成ファイルのパスを定義できます。OUTPUT_DIRECTORY は、出力を保存する場所に置き換えます。

2. 次のフラグを指定して nomos vet を実行し、構成ファイルの構文と有効性を確認します。

   nomos vet \
       --source-format=unstructured \
       --keep-output=true \
       --output=OUTPUT_DIRECTORY
   

   コマンドの内容:

   • --source-format=unstructured を使用すると、nomos vet は非構造化リポジトリで機能できます。
   • --keep-output=true ではレンダリングされた構成ファイルが保存されます。
   • --output=OUTPUT_DIRECTORY はレンダリングされた構成ファイルのパスです。

Git リポジトリからの同期を構成する

使用する構成ファイルでリポジトリが作成されたので、クラスタからリポジトリへの同期を構成できます。

1. RootSync オブジェクトを構成するには、root-sync.yaml ファイルを作成します。

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: root-sync
     namespace: config-management-system
   spec:
     sourceFormat: unstructured
     git:
       repo: YOUR_GIT_REPOSITORY
       branch: main
       auth: none
     override:
       enableShellInRendering: true
   

   YOUR_GIT_REPOSITORY は、Git リポジトリの URL に置き換えます。

2. root-sync.yaml ファイルをクラスタに適用します。

   kubectl apply -f root-sync.yaml
   

インストールを確認する

Config Sync をインストールして構成したら、インストールが正常に完了したことを確認します。

1. nomos status を使用して、他にエラーがないことを確認します。

   nomos status
   

   出力例:

   *CLUSTER_NAME
   --------------------
   <root>   https:/github.com/GoogleCloudPlatform/anthos-config-management-samples.git/helm-component/manifests@init
   SYNCED   fd17dd5a
   

2. Helm コンポーネントが、正常にインストールされたかどうかを確認します。

   kubectl get all -n cert-manager
   

   出力例:

   NAME                                              READY   STATUS    RESTARTS   AGE
   pod/my-cert-manager-54f5ccf74-wfzs4               1/1     Running   0          10m
   pod/my-cert-manager-cainjector-574bc8678c-rh7mq   1/1     Running   0          10m
   pod/my-cert-manager-webhook-7454f4c77d-rkct8      1/1     Running   0          10m
   
   NAME                              TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
   service/my-cert-manager           ClusterIP   10.76.9.35     <none>        9402/TCP   10m
   service/my-cert-manager-webhook   ClusterIP   10.76.11.205   <none>        443/TCP    10m
   
   NAME                                         READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/my-cert-manager              1/1     1            1           10m
   deployment.apps/my-cert-manager-cainjector   1/1     1            1           10m
   deployment.apps/my-cert-manager-webhook      1/1     1            1           10m
   
   NAME                                                    DESIRED   CURRENT   READY   AGE
   replicaset.apps/my-cert-manager-54f5ccf74               1         1         1       10m
   replicaset.apps/my-cert-manager-cainjector-574bc8678c   1         1         1       10m
   replicaset.apps/my-cert-manager-webhook-7454f4c77d      1         1         1       10m
   

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトを削除する

注意: プロジェクトを削除すると、次のような影響があります。

• プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
• カスタム プロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタム プロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

リソースを個別に削除する

リポジトリ内のマニフェストを削除する

誤って削除されないように、Config Sync では、1 回の commit ですべての Namespace やクラスタ スコープのリソースを削除することはできません。次の手順に沿って操作を行うことにより、別々の commit で適切にコンポーネントをアンインストールし、Namespace を削除します。

1. リポジトリから cert-manager コンポーネントを削除します。

   git rm -rf manifests/cert-manager \
       && git commit -m "uninstall cert-manager" \
       && git push origin BRANCH
   

   BRANCH は、リポジトリを作成したブランチに置き換えます。

2. cert-manager Namespace を削除します。

   git rm manifests/namespace-cert-manager.yaml \
       && git commit -m "remove the cert-manager namespace" \
       && git push origin BRANCH
   

3. cert-manager Namespace が存在しないことを確認します。

   kubectl get namespace cert-namespace
   

   出力例:

   Error from server (NotFound): namespaces "cert-namespace" not found
   

クラスタの削除

クラスタを削除するには、次のコマンドを実行します。

コンソール

Google Cloud コンソールを使用してクラスタを削除するには、次の操作を行います。

1. Google Cloud コンソールで GKE のページに移動します。

   GKE に移動

2. 削除するクラスタの横にある [アクション] をクリックし、 [削除] をクリックします。

3. 確認するメッセージが表示されたら、もう一度 [削除] をクリックします。

gcloud

Google Cloud CLI を使用してクラスタを削除するには、次のコマンドを実行します。

gcloud container clusters delete CLUSTER_NAME

詳細については、gcloud container clusters delete のドキュメントをご覧ください。

次のステップ

• 非構造化リポジトリの操作について詳細を確認する。