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

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

このトピックの手順の一部では、imgpkg を使用します。imgpkg のダウンロードおよびインストール方法については、「Carvel ツールのインストール」を参照してください。

パッケージの構成の表示

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.27.5---vmware.2-tkg.1 などです。
  3. kubectl get tkr TKR-VERSION を実行します。ここで、TKR-VERSION は上記で取得した値です。例：
```
kubectl get tkr v1.27.5---vmware.2-tkg.1 -o yaml
```
  4. 出力で、packages/core/antrea にあるバージョンタグを見つけます。
2. パッケージ構成ファイルをダウンロードします。例：
```
imgpkg pull -b projects.registry.vmware.com/tkg/packages/core/antrea:v1.11.2_vmware.1-tkg.1-advanced -o antrea
```
3. antrea に移動し、ファイルを確認します。

Antrea コンテナネットワーク機能の詳細については、『VMware Container Networking with Antrea 1.6.0 リリースノート』を参照してください。

Antrea コンテナクラスタと VMware NSX の統合の詳細については、「Kubernetes クラスタと Antrea CNI の統合」を参照してください。

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

自動管理パッケージは 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 要求マッピング。
vSphere CSI	`vsphereCSI.provisionTimeout`	デフォルトの設定は `300s` です。
vSphere CSI	`vsphereCSI.attachTimeout`	デフォルトの設定は `300s` です。
vSphere CSI	`vsphereCSI.netPermissions`	デフォルトの設定は `null` です。

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

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

管理クラスタに対して 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
```
values.yaml セクションを更新します。上記の表に記載されている値を更新できます。

編集した 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

シークレットを更新したら、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           1.11.1+vmware.4-tkg.1           Reconcile succeeded          7d14h

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

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

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

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

管理クラスタに対して 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
```
overlays.yaml セクションを stringData に追加します。

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

シークレットを更新した後、「自動管理パッケージの 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}} で更新するか、変数を削除します。