kpt を使用したクラウド インフラストラクチャの管理

Last reviewed 2023-03-15 UTC

このチュートリアルでは、Kubernetes 構成(マニフェストとも呼ばれます)を操作(パッケージ化、pull、更新、変更)できる Google のオープンソース ツールである kpt について説明します。kpt は、これらの構成で構成と操作を明確に分けたい場合に、テンプレート ベースのツールに代わる手段になります。kpt を使用すると、構成に影響を与えるコード(変更または検査)を再利用および共有できます。

このチュートリアルでは、Config SyncAnthos セキュリティ ブループリントなどの他の Google ソリューションと kpt を組み合わせる方法についても説明します。Kubernetes を使用するデベロッパーも、Kubernetes ベースのプラットフォームを管理するプラットフォーム エンジニアも、このチュートリアルで、Kubernetes 関連の独自のワークフローで kpt を使用する方法を学習できます。このチュートリアルは、Kubernetes と Google Cloud に精通していることを前提としています。

クラウド インフラストラクチャの宣言型構成は、IT 業界で広く確立されている方法であり、基盤となるシステムの強力な抽象化を実現できます。この抽象化により、低レベルの構成の詳細と依存関係を管理する必要がなくなるため、宣言型構成には、グラフィカル インターフェースやコマンドライン インターフェースで実行されるオペレーションなどの命令型アプローチよりも利点があります。

宣言型構成の手法が主流となるなか、Kubernetes リソースモデルが注目されています。Kubernetes API は本来、完全に宣言型であるため、Kubernetes に指示するのは目的だけであり、目的を達成する方法は指示しません。Kubernetes API を使用すると、構成の操作(オブジェクトの追加、削除、変更)から構成(必要か実際かを問わず)を明確に分離できます。つまり、Kubernetes リソースモデルにおいて、構成はデータであり、コードではありません

この構成と運用の分離には多くの利点があります。たとえば、ユーザーや自動システムが構成を把握して取り組むことが可能となり、さらに、構成を変更するソフトウェアの再利用が容易になります。また、この分離により、Cloud Build を使用した GitOps スタイルの継続的デリバリーのチュートリアルで定義されている GitOps 方法論の実装も簡単になります。

このチュートリアルでは、kpt を使用した構成オペレーションからの構成宣言の分離について説明します。このチュートリアルでは、次の kpt の機能について取り上げます。

  • パッケージ管理: Kubernetes 構成パッケージをダウンロードして更新します。
  • 関数: コードの任意の部分を実行して、構成の変更や検証を行います。
  • 関数パイプライン: パッケージ作成者がパッケージに含める一連の関数。
  • リソース管理: Kubernetes クラスタの構成に対応するリソースを適用、更新、削除します。

目標

  • Google Kubernetes Engine(GKE)クラスタを作成する。
  • kpt を使用して既存の Kubernetes 構成セットをダウンロードする。
  • kpt 関数を使用して構成をカスタマイズする。
  • GKE クラスタに構成を適用する。
  • kpt を使用して、構成のアップストリームの変更を pull します。
  • 実際のシナリオで kpt を使用して GKE クラスタを強化する。

料金

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

  • Google Kubernetes Engine

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。 新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

始める前に

  1. Google Cloud アカウントにログインします。Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。
  2. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

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

  3. Google Cloud プロジェクトで課金が有効になっていることを確認します

  4. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

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

  5. Google Cloud プロジェクトで課金が有効になっていることを確認します

  6. Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。

    Cloud Shell をアクティブにする

    Google Cloud コンソールの下部で Cloud Shell セッションが開始し、コマンドライン プロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。

  7. 自分のプロジェクトを使用するように Cloud Shell を構成します。

    gcloud config set project PROJECT_ID
    
  8. Cloud Shell で、Google Kubernetes Engine と Cloud Source Repositories の API を有効にします。

    gcloud services enable container.googleapis.com \
       sourcerepo.googleapis.com
    

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

GKE クラスタの作成

このセクションでは、チュートリアルの後半で構成をデプロイする GKE クラスタを作成します。

  1. Cloud Shell で、GKE クラスタを作成します。

    gcloud container clusters create kpt-tutorial \
       --num-nodes=1 --machine-type=n1-standard-4 \
       --zone=us-central1-a --enable-network-policy
    
  2. クラスタに対するアクセス権があることを確認します。次のコマンドは、クラスタ内のノードに関する情報を返します。

    kubectl get nodes
    

kpt パッケージの適用

このセクションでは、kpt を使用して一連の構成をダウンロードし、カスタマイズして、前のセクションで作成したクラスタに適用します。kpt は、Cloud Shell 環境内にインストールする必要があります。インストールされていない場合は、次のコマンドを使用してインストールします。

  1. Cloud Shell で kpt をインストールします。

    sudo apt update && sudo apt-get install google-cloud-sdk-kpt
    
  2. 構成のサンプルセットをダウンロードします。詳細については、kpt pkg get をご覧ください。

    kpt pkg get https://github.com/GoogleContainerTools/kpt.git/package-examples/wordpress@v0.9
    

    上のコマンドは、kpt GitHub リポジトリで入手可能な wordpress サンプル パッケージで、v0.9 でタグ付けされたバージョンをダウンロードします。

  3. パッケージの内容を調べます(kpt pkg tree)。

    kpt pkg tree wordpress
    

    出力は次のようになります。

    Package "wordpress"
    ├── [Kptfile]  Kptfile wordpress
    ├── [service.yaml]  Service wordpress
    ├── deployment
    │   ├── [deployment.yaml]  Deployment wordpress
    │   └── [volume.yaml]  PersistentVolumeClaim wp-pv-claim
    └── Package "mysql"
        ├── [Kptfile]  Kptfile mysql
        ├── [deployment.yaml]  PersistentVolumeClaim mysql-pv-claim
        ├── [deployment.yaml]  Deployment wordpress-mysql
        └── [deployment.yaml]  Service wordpress-mysql
    

    このパッケージには、最上位レベルにパッケージ wordpress と、その下位のパッケージ wordpress/mysql という 2 つのパッケージがあり、どちらのパッケージにもメタデータ ファイル Kptfile が含まれています。Kptfile は、kpt 自体によってのみ使用され、パッケージの上流のソース、カスタマイズ、検証に関するデータが含まれています。

  4. パッケージのラベルを更新します。

    パッケージ作成者により、期待されるカスタマイズを伝えるためによく使用されるレンダリング パイプラインが追加されました。

    less wordpress/Kptfile
    

    内容は次のようになります。

    apiVersion: kpt.dev/v1
    kind: Kptfile
    metadata:
      name: wordpress
    upstream:
      type: git
      git:
        repo: https://github.com/GoogleContainerTools/kpt
        directory: /package-examples/wordpress
        ref: v0.9
      updateStrategy: resource-merge
    upstreamLock:
      type: git
      git:
        repo: https://github.com/GoogleContainerTools/kpt
        directory: /package-examples/wordpress
        ref: package-examples/wordpress/v0.9
        commit: b9ea0bca019dafa9f9f91fd428385597c708518c
    info:
      emails:
        - kpt-team@google.com
      description: This is an example wordpress package with mysql subpackage.
    pipeline:
      mutators:
        - image: gcr.io/kpt-fn/set-labels:v0.1
          configMap:
            app: wordpress
      validators:
        - image: gcr.io/kpt-fn/kubeval:v0.3
    

    set-label 関数のパラメータは、任意のエディタで app: wordpress から app: my-wordpress に変更できます。

  5. 任意のコードエディタを使用して MySQL デプロイメント wordpress/mysql/deployment.yaml を編集し、MySQL のバージョンを変更します。また、セキュリティをさらに強化するには、MYSQL_ROOT_PASSWORD 変数を MYSQL_PASSWORD に変更して、次の変数を追加します。

    • MYSQL_USER
    • MYSQL_RANDOM_ROOT_PASSWORD
    • MYSQL_DATABASE

    変更前:

    [...]
      containers:
        - name: mysql
          image: mysql:5.6
          ports:
            - name: mysql
              protocol: TCP
              containerPort: 3306
          env:
            - name: MYSQL_ROOT_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mysql-pass
                  key: password
    [...]
    

    変更後:

    [...]
      containers:
        - name: mysql
          image: mysql:8.0
          ports:
            - name: mysql
              protocol: TCP
              containerPort: 3306
          env:
            - name: MYSQL_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mysql-pass
                  key: password
            - name: MYSQL_RANDOM_ROOT_PASSWORD
              value: '1'
            - name: MYSQL_USER
              value: wordpress
            - name: MYSQL_DATABASE
              value: wordpress
    [...]
    
  6. 任意のコードエディタを使用して WordPress デプロイの wordpress/deployment/deployment.yaml を編集し、WordPress のバージョンを変更して WORDPRESS_DB_USER 変数を追加します。

    変更前:

    [...]
      containers:
        - name: wordpress
          image: wordpress:6.1-apache
          ports:
            - name: wordpress
              protocol: TCP
              containerPort: 80
          env:
            - name: WORDPRESS_DB_HOST
              value: wordpress-mysql
            - name: WORDPRESS_DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mysql-pass
                  key: password
    [...]
    

    変更後:

    [...]
      containers:
        - name: wordpress
          image: wordpress:4.8-apache
          ports:
            - name: wordpress
              protocol: TCP
              containerPort: 80
          env:
            - name: WORDPRESS_DB_HOST
              value: wordpress-mysql
            - name: WORDPRESS_DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mysql-pass
                  key: password
            - name: WORDPRESS_DB_USER
              value: wordpress
    [...]
    

    パラメータを介してのみ動作するツールとは異なり、kpt を使用すると、エディタを使用してその場でファイルを編集でき、その後にアップストリーム アップデートの統合も行います。パッチの作成や、パイプラインでの関数の作成の必要がなく、deployment.yaml を直接編集できます。

  7. 構成に「sample-annotation: sample-value」のアノテーションを追加します。

    kpt fn eval wordpress --image gcr.io/kpt-fn/set-annotations:v0.1 \
      -- sample-annotation=sample-value
    

    出力結果は次のようになります。

    [RUNNING] "gcr.io/kpt-fn/set-annotations:v0.1"
    [PASS] "gcr.io/kpt-fn/set-annotations:v0.1"
    

    新しいアノテーションを確認するには、任意の構成値を調べます。確認が簡単なものは wordpress/service.yaml です。

    この例では、パッケージ作成者が想定していない方法で、関数を使用してカスタマイズを行いました。kpt では、宣言型関数と命令型関数の実行がサポートされており、幅広いシナリオに対応できます。

    このパッケージが Infrastructure as Code を使用して開発された場合は、パッケージのソースに移動してコードを編集する必要があります。

  8. kpt で kubeval を使用してパイプラインを実行し、変更を検証します。

    kpt fn render wordpress
    

    パッケージ作成者により、パイプラインに検証ステップが追加されています。

    ...
    validators:
        - image: gcr.io/kpt-fn/kubeval:v0.3
    

    このレンダリング パイプラインの正常な出力は、次のようになります。

    Package "wordpress/mysql":
    [RUNNING] "gcr.io/kpt-fn/set-labels:v0.1"
    [PASS] "gcr.io/kpt-fn/set-labels:v0.1" in 1.3s
    
    Package "wordpress":
    [RUNNING] "gcr.io/kpt-fn/set-labels:v0.1"
    [PASS] "gcr.io/kpt-fn/set-labels:v0.1" in 1.3s
    [RUNNING] "gcr.io/kpt-fn/kubeval:v0.3"
    [PASS] "gcr.io/kpt-fn/kubeval:v0.3" in 3.7s
    
    Successfully executed 3 function(s) in 2 package(s).
    

    この手順は、Kubernetes リソースモデルの利点の例です。構成はこのよく知られたモデルで表現されているため、kubeval などの既存の Kubernetes ツールを使用できます。

  9. ローカル バージョンの構成とアップストリーム構成の違いを調べます。

    kpt pkg diff wordpress
    
  10. デプロイ用にパッケージを初期化します。

    kpt live init wordpress
    

    上のコマンドを実行すると、パッケージ内の構成のインベントリがビルドされます。特に kpt は、パッケージから構成を削除するときに、インベントリを使用して構成をプルーニングします。詳細については、kpt live をご覧ください。

  11. MySQL パスワードを含むシークレットを作成します。

    kubectl create secret generic mysql-pass --from-literal=password=foobar
    
  12. この構成を GKE クラスタに適用します。

    kpt live apply wordpress
    

    出力は次のようになります。

    installing inventory ResourceGroup CRD.
    inventory update started
    inventory update finished
    apply phase started
    service/wordpress apply successful
    service/wordpress-mysql apply successful
    deployment.apps/wordpress apply successful
    deployment.apps/wordpress-mysql apply successful
    persistentvolumeclaim/mysql-pv-claim apply successful
    persistentvolumeclaim/wp-pv-claim apply successful
    apply phase finished
    reconcile phase started
    service/wordpress reconcile successful
    service/wordpress-mysql reconcile successful
    deployment.apps/wordpress reconcile pending
    deployment.apps/wordpress-mysql reconcile pending
    persistentvolumeclaim/mysql-pv-claim reconcile pending
    persistentvolumeclaim/wp-pv-claim reconcile pending
    persistentvolumeclaim/wp-pv-claim reconcile successful
    persistentvolumeclaim/mysql-pv-claim reconcile successful
    deployment.apps/wordpress-mysql reconcile successful
    deployment.apps/wordpress reconcile successful
    reconcile phase finished
    inventory update started
    inventory update finished
    apply result: 6 attempted, 6 successful, 0 skipped, 0 failed
    reconcile result: 6 attempted, 6 successful, 0 skipped, 0 failed, 0 timed out
    
  13. 数分待ってから、すべてが想定どおりに動作していることを確認します。

    kpt live status wordpress
    

    出力は次のようになります。

    inventory-88521939/deployment.apps/default/wordpress is Current: Deployment is available. Replicas: 1
    inventory-88521939/persistentvolumeclaim/default/wp-pv-claim is Current: PVC is Bound
    inventory-88521939/service/default/wordpress-mysql is Current: Service is ready
    inventory-88521939/persistentvolumeclaim/default/mysql-pv-claim is Current: PVC is Bound
    inventory-88521939/deployment.apps/default/wordpress-mysql is Current: Deployment is available. Replicas: 1
    inventory-88521939/service/default/wordpress is Current: Service is ready
    

ローカル パッケージの更新

このセクションでは、アップストリーム パッケージからのいくつかの変更を加えて、パッケージのローカル バージョンを更新します。

  1. 構成用の Git リポジトリを作成し、メールアドレスと名前を構成します。パッケージを更新するには、ローカル Git リポジトリが必要です。YOUR_EMAIL をメールアドレスに、YOUR_NAME を名前に置き換えます。

    cd wordpress/
    git init -b main
    git config user.email "YOUR_EMAIL"
    git config user.name "YOUR_NAME"
    
  2. 構成を commit します。

    git add .
    git commit -m "First version of Wordpress package"
    cd ..
    
  3. ローカル パッケージを更新します。この手順では、v0.10 バージョンをアップストリームから pull します。

    kpt pkg update wordpress@v0.10
    
  4. アップストリームからの更新がローカル パッケージに適用されることを確認します。

    cd wordpress/
    git diff
    

    このケースでは、更新により、WordPress のデプロイ ボリュームが 3 Gi から 4 Gi に変更されました。自分が行った変更も確認できます。

  5. 変更を commit します。

    git commit -am "Update to package version v0.10"
    
  6. 新しいバージョンのパッケージを適用します。

    kpt live apply .
    

リソースとパッケージの削除

kpt は作成されたリソースをトラッキングするため、パッケージからリソースを削除するときに、クラスタからリソースをプルーニングできます。クラスタからパッケージを完全に削除することもできます。このセクションでは、パッケージからリソースを削除してから、そのパッケージを削除します。

  1. パッケージから service.yaml ファイルを削除します。

    git rm service.yaml
    git commit -m "Remove service"
    
  2. 変更を適用し、kpt が WordPress サービスをプルーニングしたことを確認します。

    kpt live apply .
    kubectl get svc
    
  3. クラスタから残りのパッケージを削除し、クラスタに残っていないことを確認します。

    kpt live destroy .
    kubectl get deployment
    

kpt を使用して GKE を強化する

kpt live コマンドは、パッケージを Kubernetes クラスタに適用するための唯一の方法ではありません。このセクションでは、単純ですが実際のシナリオで、Config Sync とともに kpt を使用します。Config Sync ツールを使用すると、Git リポジトリからすべての Kubernetes クラスタの構成を一元的で均一、かつ宣言的に管理できます。Config Sync は、GKE のスタンドアロン プロダクトとして利用できます。このチュートリアルで使用する Anthos には、Anthos Config Management が含まれています。

Anthos セキュリティ ブループリントは、Anthos ベースのワークロード用に事前にパッケージ化されたさまざまなセキュリティ設定を提供します。このセクションでは、トラフィックを制限するブループリント(および GitHub リポジトリの該当のディレクトリ)を使用します。kpt を使用して default-deny パッケージをダウンロードします。このパッケージは、デフォルトでは Kubernetes ネットワーク ポリシーを使用して GKE クラスタ内のトラフィックを拒否します(DNS 解決を除く)。構成を適用するには、構成を Config Sync Git リポジトリに commit します。

Config Sync のインストール

このセクションでは、Config Sync に必要な Git リポジトリを作成し、GKE クラスタに Config Sync をインストールします。

  1. Cloud Shell で、Cloud Source Repositories を使用して Config Sync 用の Git リポジトリを作成します。

    cd ~
    gcloud source repos create config-management
    
  2. Git リポジトリに対する認証を行うための SSH 認証鍵ペアを生成します。

    cd ~
    ssh-keygen -t rsa -b 4096  -N '' \
       -f cloud_source_repositories_key
    
  3. Git リポジトリにアクセスするための SSH 秘密鍵を含む Kubernetes Secret を作成します。

    kubectl create ns config-management-system && \
    kubectl create secret generic git-creds \
      --namespace=config-management-system \
      --from-file=ssh=cloud_source_repositories_key
    
  4. 公開鍵を表示してコピーします。

    cat cloud_source_repositories_key.pub
    
  5. Cloud Source Repositories に移動します。

    SSH 認証鍵の管理ページ。

  6. 表示される [Register SSH Key] ダイアログで、次の値を入力します。

    1. [Key name] フィールドに「config-management」と入力します。
    2. [Key] フィールドに公開鍵を貼り付けます。
    3. [Register] をクリックします。
  7. Cloud Shell に Git リポジトリのクローンを作成します。

    gcloud source repos clone config-management
    cd config-management
    git checkout -b main
    
  8. nomos という名前の Config Sync コマンドライン ツールをダウンロードします。nomos は、Cloud Shell 環境内にインストールする必要があります。インストールされていない場合は、次のコマンドを使用してインストールします。

    sudo apt update && sudo apt-get install google-cloud-sdk-nomos
    
  9. Config Sync リポジトリを初期化します。

    nomos init
    git add .
    git commit -m "Config Management directory structure"
    git push -u origin main
    
  10. Config Sync 演算子をデプロイします。

    gsutil cp gs://config-management-release/released/latest/config-management-operator.yaml /tmp/config-management-operator.yaml
    kubectl apply -f /tmp/config-management-operator.yaml
    

Config Sync を構成する

  1. Config Sync を構成する ConfigManagement カスタム リソースを作成します。

    PROJECT=$(gcloud config get-value project)
    EMAIL=$(gcloud config get-value account)
    cat <<EOF > /tmp/config-management.yaml
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      clusterName: kpt-tutorial
      git:
        syncRepo: ssh://${EMAIL}@source.developers.google.com:2022/p/${PROJECT}/r/config-management
        syncBranch: main
        secretType: ssh
    EOF
    kubectl -n config-management-system \
        apply -f /tmp/config-management.yaml
    

    その他のインストール オプションについては、Config Sync のドキュメントのインストールをご覧ください。

  2. Cloud Shell で、Config Sync が正しく動作していることを確認します。

    nomos status --contexts=$(kubectl config current-context)
    

    このコマンドは、ステータスを SYNCED として返します。Config Sync での初期化に時間がかかることがあります。ステータスが更新されない場合は、数分待ってからコマンドを再実行します。

Anthos セキュリティ ブループリントを適用する

このセクションでは、kpt を使用して、トラフィックを制限する Anthos セキュリティ ブループリントの default-deny パッケージをダウンロードします。次に、Config Sync を使用してパッケージを default 名前空間にのみ適用します。

  1. default-deny パッケージをダウンロードします。

    cd ~
    kpt pkg get https://github.com/GoogleCloudPlatform/anthos-security-blueprints.git/restricting-traffic/default-deny ./
    

    パッケージのコンテンツを調べることができます。default-deny/Kptfile ファイルにはパッケージのメタデータが含まれ、default-deny/default-deny.yaml ファイルにはこのブループリントの唯一の構成である Kubernetes NetworkPolicy が含まれます。

  2. Config Sync リポジトリで kpt を使用してパッケージの内容をコピーし、ラベルを追加してカスタマイズします。

    kpt fn source default-deny/ | \
        kpt fn eval - --image=gcr.io/kpt-fn/set-annotations:v0.1 -- \
        anthos-security-blueprint=restricting-traffic | \
        kpt fn sink ~/config-management/namespaces/default/
    

    この例に示すように、パイプを使用して kpt fn コマンドを連結できます。kpt fn コマンドを連結させることで、構成を読み取り、必要に応じて変更し、結果を書き込むことができます。kpt fn コマンドはいくつでも連結できます。

  3. Config Sync リポジトリに namespace.yaml ファイルを作成します。

    cat >> ~/config-management/namespaces/default/namespace.yaml <<EOF
    apiVersion: v1
    kind: Namespace
    metadata:
      name: default
    EOF
    

    default 名前空間は GKE クラスタ内に存在しますが、Config Sync で管理されません。この手順でディレクトリとファイルを作成するときは、Config Sync に名前空間を管理させます。パッケージを複数の名前空間に一括して適用するには、抽象名前空間を作成します。

  4. Kubernetes NetworkPolicy が Anthos Config Management リポジトリに書き込まれ、anthos-security-blueprint: restricting-traffic アノテーションが付いていることを確認します。

    cat config-management/namespaces/default/default-deny.yaml
    

    出力は次のようになります。

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata: # kpt-merge: /default-deny
      name: default-deny
      annotations:
        internal.kpt.dev/upstream-identifier: 'networking.k8s.io|NetworkPolicy|default|default-deny'
        anthos-security-blueprint: restricting-traffic
    spec:
      policyTypes:
      - Ingress
      - Egress
      podSelector: {}
      egress:
      - to:
        - namespaceSelector:
            matchLabels:
              k8s-namespace: kube-system
          podSelector:
            matchExpressions:
            - key: k8s-app
              operator: In
              values: ["kube-dns", "node-local-dns"]
        ports:
        - protocol: TCP
          port: 53
        - protocol: UDP
          port: 53
    
  5. 変更を commit して push します。

    cd ~/config-management/
    git add namespaces/default/
    git commit -m "Default deny"
    git push
    
  6. 新しいポリシーが適用されていることを確認します。

    kubectl get networkpolicies
    

    新しいポリシーが存在しない場合は、数秒待ってからコマンドを再度実行します。Config Sync は、デフォルトでは 15 秒ごとに構成を更新します。さらなるトラブルシューティングが必要な場合は、次のコマンドを実行して、可能性のある Config Sync エラーに関する情報を取得します。

    nomos status --contexts=$(kubectl config current-context)
    
  7. 新しいポリシーをテストするには、default 名前空間内で動作している Pod でシェルを起動します。

    kubectl -n default run -i --tty --rm test \
            --image=busybox --restart=Never -- sh
    
  8. 8.8.8.8 を ping して、想定どおりに機能していないことを確認します。

    ping -c 3 -W 1 8.8.8.8
    

    出力は次のようになります。

    PING 8.8.8.8 (8.8.8.8): 56 data bytes
    
    --- 8.8.8.8 ping statistics ---
    3 packets transmitted, 0 packets received, 100% packet loss
    
  9. Kubernetes API サーバーにクエリを実行して、想定どおりに動作していないことを確認します。

    wget --timeout=3 https://${KUBERNETES_SERVICE_HOST}
    

    出力は次のようになります。

    Connecting to 10.3.240.1 (10.3.240.1:443)
    wget: download timed out
    
  10. Pod を終了します。

    exit
    

クリーンアップ

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

プロジェクトの削除

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

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

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

リソースの削除

このチュートリアルで使用した Google Cloud プロジェクトを残しておく場合は、Git リポジトリと GKE クラスタを削除できます。Cloud Shell で、次のコマンドを実行します。

gcloud source repos delete config-management --quiet
gcloud container clusters delete kpt-tutorial \
    --async --quiet --zone=us-central1-a

次のステップ