This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

自動管理パッケージ構成の表示と更新

このトピックでは、tanzu-core リポジトリからインストールされた自動管理パッケージの構成を表示、カスタマイズ、およびトラブルシューティングする方法について説明します。また、カスタマイズ可能な Antrea、Pinniped、Calico、vSphere CPI、vSphere CSI 構成の設定も一覧表示されます。

パッケージの構成の表示

tanzu-core リポジトリにある自動管理パッケージには、Antrea または Calico コンテナ ネットワーク インターフェイスや Pinniped 認証コンポーネントなど、基本的なクラスタ機能をサポートするコンポーネントが含まれています。場合によっては、内部の Tanzu Kubernetes Grid および Kubernetes リソースはこれらのコンポーネントを addons として参照します。

自動管理パッケージとそのパッケージに含まれるアドオン コンポーネントの構成を表示するには、次の手順を実行できます。

  • 管理クラスタに対して kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE コマンドを実行して、インストールされたアドオン コンポーネントの Kubernetes シークレットを取得します。ここで、

    • CLUSTER-NAME はターゲット クラスタの名前です。ワークロード クラスタにインストールされているアドオン コンポーネントのシークレットを取得することを望む場合、CLUSTER-NAME はワークロード クラスタの名前になります。
    • PACKAGE-NAME はパッケージの名前です。
    • CLUSTER-NAMESPACE はターゲット クラスタの名前空間です。

  • projects.registry.vmware.com/tkg/packages/core からパッケージ構成ファイルをダウンロードします。

たとえば、Antrea の構成を表示するには、次の手順を実行します。

  • 管理クラスタに対して次のコマンドを実行して、Antrea シークレットを取得します。

    kubectl get secret CLUSTER-NAME-antrea-addon -n CLUSTER-NAMESPACE

  • Antrea パッケージ構成ファイルをダウンロードします。

    1. クラスタの作成に使用した Tanzu Kubernetes リリース (TKr) で、antrea のバージョン タグを見つけます。TKr を取得するには、管理クラスタに対して kubectl get tkr コマンドを実行します。

      1. kubectl get clusters CLUSTER-NAME -n CLUSTER-NAMESPACE --show-labels を実行します。

      2. 出力で、tanzuKubernetesRelease の値を見つけます。たとえば、tanzuKubernetesRelease=v1.23.10---vmware.1-tkg.1 などです。

      3. kubectl get tkr TKR-VERSION を実行します。ここで、TKR-VERSION は上記で取得した値です。例：

        kubectl get tkr v1.23.10---vmware.1-tkg.1 -o yaml

      4. 出力で、packages/core/antrea にあるバージョン タグを見つけます。

        または、~/.config/tanzu/tkg/bom/YOUR-TKR-BOM-FILE で TKr を確認して、バージョン タグを見つけることができます。

    2. パッケージ構成ファイルをダウンロードします。例：

      imgpkg pull -b projects.registry.vmware.com/tkg/packages/core/antrea:v1.2.3_vmware.4-tkg.1-advanced -o antrea

    3. antrea に移動し、ファイルを確認します。

Antrea コンテナ ネットワーク機能の詳細については、「VMware Container Networking with Antrea 1.4.0 リリース ノート」を参照してください。Antrea コンテナ クラスタと VMware NSX の統合の詳細については、「Antrea コンテナ クラスタの統合」を参照してください。

パッケージ構成のカスタマイズ

自動管理パッケージは Tanzu Kubernetes Grid によって管理されるため、通常、ワークロード クラスタ内の自動管理パッケージの構成をカスタマイズする必要はありません。

ただし、必要に応じてこれらの設定をカスタマイズできます。自動管理パッケージ設定のカスタマイズ方法は、クラスタのタイプによって異なります。

プランベースまたは TKC ベースのクラスタの場合は、コンポーネント シークレットの values.yaml セクションを変更してパッチを適用し、「values.yaml 設定のカスタマイズ」の説明に従って既存のクラスタを個別にカスタマイズできます。

プランベースまたは TKC ベースのクラスタでは、「オーバーレイを使用したカスタマイズ」の説明に従って、管理クラスタ内のパッケージ構成シークレットにオーバーレイを追加して、作成する前にクラスタをカスタマイズできます。

クラスベースのクラスタの場合は、「クラスベースのクラスタを作成する」で説明されている 2 段階のプロセスの手順 1 に従ってクラスタ マニフェストを作成し、手順 2 でクラスタを作成する前にカスタム オブジェクト定義をマニフェストに追加することで、作成する前にクラスタをカスタマイズできます。例については、「クラスベースのマニフェストをカスタマイズする」を参照してください。

自動管理パッケージの values.yaml 設定

自動管理パッケージでは、次の構成設定をカスタマイズできます。これらの値は、パッケージ コンポーネント シークレットの values.yaml セクションで設定されます。

パッケージ 設定 説明
Antrea antrea.config.defaultMTU デフォルトの設定は null です。
Antrea antrea.config.tlsCipherSuites デフォルトでは、FIPS 対応の暗号化スイートを含めます。他の暗号化スイートに切り替えるには、tlsCipherSuites フィールドの値を更新します。
Calico calico.config.vethMTU デフォルトは “0” で、Calico は最大転送サイズ (MTU) 設定を自動検出します。このパラメータを設定して、最大パケット サイズをバイト単位で文字列として指定します。
Calico calico.config.skipCNIBinaries デフォルトは true で、クラスタの作成時に Calico が既存の CNI プラグインの設定を上書きすることを制限します。クラスタをアップグレードするときに、上書きを回避するには、calico.config.skipCNIBinaries=true を設定します。
Pinniped pinniped.supervisor_svc_external_dns OIDC IDP クライアントのコールバック URL として使用される、Pinniped スーパーバイザーに関連付けられた FQDN。Pinniped のサービス タイプによっては、ポート番号を含める必要があります。
  • LoadBalancer の場合、NSX ALB、AWS、または Azure を使用する vSphere では、ポート番号を含めないでください。https://hr.tkg.example.com.
  • NodePort の場合は、NSX ALB を使用しない vSphere と同様に、ポート番号を含めます。https://hr.tkg.example.com:31234。
Pinniped pinniped.upstream_oidc_client_id OIDC プロバイダのクライアント ID。
Pinniped pinniped.upstream_oidc_client_secret OIDC プロバイダのクライアント シークレット。
Pinniped pinniped.upstream_oidc_issuer_url OIDC プロバイダの URL。
Pinniped pinniped.upstream_oidc_tls_ca_data OIDC プロバイダへの TLS 接続を検証するために使用される Base64 エンコード形式 CA バンドル データ。
Pinniped pinniped.upstream_oidc_additional_scopes トークン応答で要求する追加範囲のリスト。
Pinniped pinniped.upstream_oidc_claims OIDC 要求マッピング。
Pinniped dex.config.ldap.host* LDAP サーバの IP アドレスまたは DNS アドレスです。デフォルト ポート 636 を別のポートに変更する場合は、“host:port” を指定します。
Pinniped dex.config.ldap.bindDN* および dex.config.ldap.BIND_PW_ENV_VAR* アプリケーション サービス アカウントの DN およびパスワード。
Pinniped dex.config.ldap.userSearch* ユーザーの検索属性。スキーマについては、Dex のドキュメントを参照してください。
Pinniped dex.config.ldap.groupSearch* グループの検索属性。スキーマについては、Dex のドキュメントを参照してください。
vSphere CSI vsphereCSI.provisionTimeout デフォルトの設定は 300s です。
vSphere CSI vsphereCSI.attachTimeout デフォルトの設定は 300s です。
vSphere CSI vsphereCSI.netPermissions デフォルトの設定は null です。

* dex. で始まる Pinniped 設定を更新する場合は、「管理クラスタ展開後の Dex 設定の更新」を参照してください。

values.yaml 設定のカスタマイズ

すでに実行されているプランベースまたは TKC ベースのクラスタ内のアドオン コンポーネント シークレットの values.yaml セクションをカスタマイズするには、次の手順を実行します。

  1. 管理クラスタに対して kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE コマンドを実行して、シークレットを取得します。例：

    kubectl get secret example-workload-cluster-antrea-addon -n example-workload-cluster-namespace -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml

  2. values.yaml セクションを更新します。上記の表に記載されている値を更新できます。

  3. 編集した values.yaml ファイルを base64 でエンコードし、それをクラスタ シークレット内で置き換えて更新を適用します。このコマンドは、環境の OS によって異なります。例：

    Linux：

    kubectl patch secret/example-workload-cluster-antrea-addon -n example-workload-cluster-namespace -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge

    macOS：

    kubectl patch secret/example-workload-cluster-antrea-addon -n example-workload-cluster-namespace -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge

  4. シークレットを更新したら、kubectl get packageinstall コマンドを実行して、パッケージのステータスを確認します。例：

    $ kubectl get packageinstall antrea -n tkg-system
NAMESPACE    NAME                   PACKAGE NAME                      PACKAGE VERSION                 DESCRIPTION                  AGE
tkg-system   antrea                 antrea.tanzu.vmware.com           0.13.3+vmware.1-tkg.1           Reconcile succeeded          7d14h

    返されたステータスが Reconcile failed の場合は、次のコマンドを実行してエラーの詳細を取得します。

    kubectl get packageinstall antrea -n tkg-system -o yaml

  5. kubectl get app コマンドを実行します。例：

    $ kubectl get app antrea -n tkg-system
NAME           DESCRIPTION             SINCE-DEPLOY    AGE
antrea         Reconcile succeeded     3m23s           7h50m

    返されたステータスが Reconcile failed の場合は、次のコマンドを実行してエラーの詳細を取得します。

    kubectl get app antrea -n tkg-system -o yaml

次の例では、Antrea のデフォルトの最大転送ユニット (MTU) を更新します。

stringData:
  values.yaml: |
    #@data/values
    #@overlay/match-child-defaults missing_ok=True
    ---
    infraProvider: vsphere
    antrea:
      config:
        defaultMTU: 8900
注

クラスタ内のすべてのノードに対して同じ MTU 設定を構成していることを確認します。ファイアウォール設定で、構成された MTU サイズのパケットを許可する必要があります。クラスタ内のノードで異なる MTU 設定によって発生した問題を解決するには、「MTU の不一致によってクラスタ ワーカー ノードが NotReady ステータスになる」を参照してください。

オーバーレイを使用したカスタマイズ

場合によっては、アドオン コンポーネント シークレットにオーバーレイを追加して、作成前にプランベースまたは TKC ベースのクラスタの自動管理パッケージ構成をカスタマイズできます。

次の例では、Pinniped に対して、NSX Advanced Load Balancer (ALB) が制御プレーン エンドポイントとして機能しない場合に、vSphere のデフォルトである NodePort の代わりに LoadBalancer サービス タイプを使用するように指示しています。

...
stringData:
 overlays.yaml: |
   #@ load("@ytt:overlay", "overlay")
   #@overlay/match by=overlay.subset({"kind": "Service", "metadata": {"name": "pinniped-supervisor", "namespace": "pinniped-supervisor"}})
   ---
   #@overlay/replace
   spec:
     type: LoadBalancer
     selector:
       app: pinniped-supervisor
     ports:
       - name: https
         protocol: TCP
         port: 443
         targetPort: 8443
 values.yaml: |
   #@data/values
   #@overlay/match-child-defaults missing_ok=True
   ---
   infrastructure_provider: vsphere
   tkg_cluster_role: management

オーバーレイを追加するには、次の手順を実行します。

  1. 管理クラスタに対して kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE コマンドを実行して、シークレットを取得します。例：

    kubectl get secret example-workload-cluster-pinniped-addon -n example-workload-cluster-namespace -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml

  2. overlays.yaml セクションを stringData に追加します。

  3. 編集した values.yaml ファイルを base64 でエンコードし、それをクラスタ シークレット内で置き換えて更新を適用します。このコマンドは、環境の OS によって異なります。例：

    Linux：

    kubectl patch secret/example-workload-cluster-pinniped-addon -n example-workload-cluster-namespace -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge

    macOS：

    kubectl patch secret/example-workload-cluster-pinniped-addon -n example-workload-cluster-namespace -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge

  4. シークレットを更新した後、「自動管理パッケージの values.yaml 設定」で説明されているように、kubectl get packageinstall と kubectl get app コマンドを実行してパッケージのステータスを確認します。

クラスベースのマニフェストのカスタマイズ

クラスベースのクラスタの場合は、「クラスベースのクラスタを作成する」で説明されている 2 段階のプロセスの手順 1 に従ってクラスタ マニフェストを作成し、手順 2 でクラスタを作成する前にカスタム オブジェクト定義をマニフェストに追加することで、作成する前にクラスタをカスタマイズできます。

たとえば、vSphere CSI の netPermissions 値をカスタマイズするには、VSphereCSIConfig オブジェクトの spec.vsphereCSI 定義ブロックに次のような netPermissions ブロックを追加して、tanzu cluster create --dry-run で生成されたマニフェストを変更します。

apiVersion: csi.tanzu.vmware.com/v1alpha1
kind: VSphereCSIConfig
[...]
spec:
  vsphereCSI:
    mode: vsphereCSI
    config:
      [...]
      provisionTimeout: 33s
      attachTimeout: 77s
      resizerTimeout: 99s
      netPermissions:
        PERM-1:
          ips: "*"
          permissions: READ_WRITE
          rootsquash: false
        PERM-2:
          ips: "10.20.20.0/24"
          permissions: READ_ONLY
          rootsquash: true
        PERM-3:
          ips: "10.30.30.0/24"
          permissions: NO_ACCESS

ここで、

  • PERM-* は権限設定の該当セクションに付ける名前で、vSphere 構成シークレット内で [NetPermissions "PERM-1"] などに変換されます。
  • ips: 値は、セクションが権限を設定するファイル ボリュームのアドレス範囲です。
  • permissions: 値は、そのセクションに設定された権限です。

マニフェストを変更したら、「クラスベースのクラスタの作成」の手順 2 に従ってクラスタを作成できます。

パッケージ構成のトラブルシューティング

クラスタ内の自動管理パッケージ構成をトラブルシューティングするには、パッケージの PackageInstall カスタム リソース (CR) およびコンポーネント Secret を確認して変更します。

パッケージ構成に一時的な変更を適用するには、以下の「自動管理パッケージのライフサイクル管理の一時停止」で説明されているように、PackageInstall オブジェクトと Secret オブジェクトの調整を一時停止する必要がある場合があります。この手順は、パッケージのライフサイクル管理を無効にするため、慎重に行う必要があります。

重要な用語

Tanzu Kubernetes Grid は、次のリソースを使用して自動管理パッケージのライフサイクルを管理します。

管理クラスタにインストールされているコンポーネント：

  • kapp-controller、ローカル パッケージ マネージャ：管理クラスタを展開すると、Tanzu CLI によってクラスタに kapp-controller がインストールされます。kapp-controller は、tanzu-addons-manager およびその他の自動管理パッケージをインストールします。また、kapp-controllerを、その管理クラスタから展開する各ワークロード クラスタにインストールして管理します。
  • tanzu-addons-manager：管理クラスタおよび管理クラスタから展開するワークロード クラスタに自動管理パッケージとしてインストールされるアドオン コンポーネントを管理します。
  • tkr-controller：管理クラスタに TKr と BoM ConfigMaps を作成します。

ワークロード クラスタにインストールされたコンポーネント：

kapp-controller は、それが実行されているワークロード クラスタに自動管理パッケージをインストールします。

オブジェクト:

  • Secret：Tanzu CLI は、クラスタごとに各アドオン コンポーネントに対して Secret を作成します。これらのシークレットは、アドオン コンポーネントの構成を定義します。tanzu-addons-manager はシークレットを読み取り、含まれている構成情報を使用してアドオン コンポーネントを構成します。すべてのシークレットは管理クラスタに作成されます。
  • PackageRepository CR：tanzu-addons-manager は、すべてのアドオン コンポーネントの Package CR を参照する PackageRepository CR を作成します（以下を参照）。
  • Package CR：PackageRepository のアドオン コンポーネントごとに、kapp-controller はターゲット クラスタに Package CR を作成します。
  • PackageInstall CR：Package アドオン コンポーネントごとに、tanzu-addons-manager はターゲット クラスタに PackageInstall CR を作成し、どの自動管理パッケージをインストールする必要があるかを kapp-controller に通知します。
  • App CR：PackageInstall ごとに、kapp-controller はターゲット クラスタに App CR を作成します。次に、kapp-controller は CR を調整してパッケージをインストールします。
  • BoM ConfigMap：イメージの場所など、アドオン コンポーネントに関するメタデータ情報を tanzu-addons-manager に提供します。

次のコマンドを使用して、これらのリソースのステータスを監視できます。

コマンド 説明
kubectl get packageinstall PACKAGE-NAME -n tkg-system -o yaml ターゲット クラスタで PackageInstall CR を確認します。たとえば、kubectl get packageinstall antrea -n tkg-system -o yaml などです。
kubectl get app PACKAGE-NAME -n tkg-system -o yaml ターゲット クラスタで App CR を確認します。たとえば、kubectl get app antrea -n tkg-system -o yaml などです。
kubectl get cluster CLUSTER-NAME -n CLUSTER-NAMESPACE -o jsonpath={.metadata.labels.tanzuKubernetesRelease} 管理クラスタで、ターゲット クラスタの TKr ラベルが正しい TKr を参照しているかどうかを確認します。
kubectl get tanzukubernetesrelease TKR-NAME TKr が管理クラスタに存在するかどうかを確認します。
kubectl get configmaps -n tkr-system -l ‘tanzuKubernetesRelease=TKR-NAME’ TKr に対応する BoM ConfigMap が管理クラスタに存在するかどうかを確認します。
kubectl get app CLUSTER-NAME-kapp-controller -n CLUSTER-NAMESPACE ワークロード クラスタの場合は、kapp-controller App CR が管理クラスタに存在するかどうかを確認します。
kubectl logs deployment/tanzu-addons-controller-manager -n tkg-system 管理クラスタで tanzu-addons-manager ログを確認します。
kubectl get configmap -n tkg-system | grep ADD-ON-NAME-ctrl アドオン シークレットへの更新が適用されているかどうかを確認します。同期時間は 5 分間です。

自動管理パッケージのライフサイクル管理の一時停止

重要

このセクションのコマンドは、パッケージのライフサイクル管理を無効にします。可能な場合は、上記の「パッケージ構成の更新」で説明されている手順を代わりに使用してください。

自動管理パッケージのライフサイクル管理を一時的に停止する必要がある場合は、次のコマンドを使用できます。

  • シークレットの調整を一時停止するには、管理クラスタに対して次のコマンドを実行します。

    kubectl patch secret/CLUSTER-NAME-ADD-ON-NAME-addon -n CLUSTER-NAMESPACE -p '{"metadata":{"annotations":{"tkg.tanzu.vmware.com/addon-paused": ""}}}' --type=merge

    このコマンドを実行すると、tanzu-addons-manager はシークレットの調整を停止します。

  • PackageInstall CR の調整を一時停止するには、ターゲット クラスタに対して次のコマンドを実行します。

    kubectl patch packageinstall/PACKAGE-NAME -n tkg-system -p '{"spec":{"paused":true}}' --type=merge

    このコマンドを実行すると、kapp-controller は PackageInstall および対応する App CR の調整を停止します。

アドオン コンポーネントのリソースを一時的に変更する場合は、まずシークレット調整を一時停止してから、PackageInstall CR の調整を一時停止します。ライフサイクル管理の一時停止を解除した後、tanzu-addons-manager および kapp-controller はシークレットおよび PackageInstall CR の調整を再開します。

  • シークレットの調整の一時停止を解除するには、シークレット注釈から tkg.tanzu.vmware.com/addon-paused を削除します。

  • PackageInstall CR の調整の一時停止を解除するには、PackageInstall CR を {"spec":{"paused":false}} で更新するか、変数を削除します。

check-circle-line exclamation-circle-line close-line
Scroll to top icon