ポッドとコンテナ ネットワーク

このトピックでは、ワークロード クラスタのポッドやコンテナのネットワークをカスタマイズする方法について説明します。これには、デフォルトの Antrea 以外のクラスタ ネットワーク インターフェイス (CNI) の使用や、VMware NSX ネットワークを使用する vSphere 上のワークロード クラスタに対するパブリックにルーティング可能な非 NAT IP アドレスのサポートなどが含まれます。

デフォルト以外の CNI を使用したクラスタの作成

Tanzu CLI を使用してワークロード クラスタを展開すると、クラスタで Antrea クラスタ ネットワーク インターフェイス (CNI) が自動的に有効になります。または、Calico CNI または独自の CNI プロバイダを有効にすることもできます。

自動管理パッケージは Tanzu Kubernetes Grid によって管理されるため、通常はそれらの構成を更新する必要はありません。ただし、Calico などのカスタム CNI を使用するワークロード クラスタを作成することも可能です。以降のセクションでは、Calico などのカスタム CNI を構成する手順について説明します。

スタンドアローン管理クラスタで展開されたクラスタのカスタム CNI

1.2.x より前のバージョンの Tanzu Kubernetes Grid を使用する、スタンドアローン管理クラスタによって展開されたワークロード クラスタを v1.3 にアップグレードしても、引き続き Calico を CNI プロバイダとして使用します。これらのクラスタの CNI プロバイダは変更できません。

構成ファイルで CNI 変数を指定することで、スタンドアローン管理クラスタから展開するワークロード クラスタのデフォルトの CNI を変更できます。CNI 変数は次のオプションをサポートします。

  • （デフォルト）antrea：Antrea を有効にします。
  • calico：Calico を有効にします。「Calico CNI」を参照してください。このオプションは Windows ではサポートされません。
  • none：カスタム CNI プロバイダを有効にできます。「カスタム CNI」を参照してください。

CNI 変数を設定しない場合、Antrea はデフォルトで有効になります。

Calico CNI

ワークロード クラスタで Calico を有効にするには、構成ファイルで次のように指定します。

CNI: calico

クラスタの作成プロセスが完了したら、「ワークロード クラスタへの接続と確認」の説明に従ってクラスタを確認できます。

カスタム CNI

ワークロード クラスタで Calico 以外のカスタム CNI プロバイダを有効にするには、次の手順を実行します。

  1. クラスタを作成するときに、構成ファイルで CNI: none を指定します。例：

    CNI: none

    クラスタに CNI を適用するまで、クラスタの作成プロセスは成功しません。管理クラスタのクラスタ API ログでクラスタ作成プロセスを監視できます。クラスタ API ログにアクセスする方法については、「ログと監視」を参照してください。

  2. クラスタが初期化されたら、CNI プロバイダをクラスタに適用します。

    1. クラスタの admin 認証情報を取得します。例：

      tanzu cluster kubeconfig get my-cluster --admin

    2. kubectl のコンテキストをクラスタに設定します。例：

      kubectl config use-context my-cluster-admin@my-cluster

    3. CNI プロバイダをクラスタに適用します。

      kubectl apply -f PATH-TO-YOUR-CNI-CONFIGURATION/example.yaml
  3. tanzu cluster list コマンドを使用して、クラスタのステータスを監視します。クラスタの作成が完了すると、クラスタのステータスが creating から running に変わります。クラスタの確認方法の詳細については、「ワークロード クラスタへの接続と確認」を参照してください。

スーパーバイザーまたは単一ノードのクラスベースのワークロード クラスタの Calico CNI

スーパーバイザーによって展開された、または単一ノードのワークロード クラスタとしてスタンドアローン管理クラスタによって展開されたクラスベースのクラスタに、antrea の代わりに calico をインストールするには、まず、クラスタの ClusterBootstrap オブジェクトを次のようにカスタマイズする必要があります。

  1. 次の Kubernetes オブジェクトを含む YAML ファイルを作成します。

    apiVersion: cni.tanzu.vmware.com/v1alpha1
kind: CalicoConfig
metadata:
name: CLUSTER-NAME
namespace: CLUSTER-NAMESPACE
spec:
calico:
  config:
    vethMTU: 0
---
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: ClusterBootstrap
metadata:
annotations:
  tkg.tanzu.vmware.com/add-missing-fields-from-tkr: TKR-VERSION
name: CLUSTER-NAME
namespace: CLUSTER-NAMESPACE
spec:
additionalPackages: # Customize additional packages
- refName: metrics-server*
- refName: secretgen-controller*
- refName: pinniped*
cni:
  refName: calico*
  valuesFrom:
    providerRef:
      apiGroup: cni.tanzu.vmware.com
      kind: CalicoConfig
      name: CLUSTER-NAME

    ここで、

    • CLUSTER-NAME は、作成しようとしているワークロード クラスタの名前です。
    • CLUSTER-NAMESPACE はワークロード クラスタの名前空間です。

    • TKR-VERSION は、ワークロード クラスタに使用しようとしている Tanzu Kubernetes リリース (TKr) のバージョンです。例：

  2. 単一ノード クラスタの場合は、spec.additionalPackages ブロックを ClusterBootstrap 定義から削除します。単一ノード クラスタには、追加の metrics-server、secretgen-controller、pinniped パッケージがありません。

  3. スーパーバイザー クラスタかスタンドアローン管理クラスタかに関係なく、管理クラスタに対して kubectl apply -f コマンドを実行することでファイルを適用します。

  4. 次の構成を含む、Cluster オブジェクトの YAML ファイルを作成します。

    apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: CLUSTER-NAME
namespace: CLUSTER-NAMESPACE
spec:
clusterNetwork:
  services:
    cidrBlocks: ["SERVICES-CIDR"]
  pods:
    cidrBlocks: ["PODS-CIDR"]
  serviceDomain: "SERVICE-DOMAIN"
topology:
  class: tanzukubernetescluster
  version: TKR-VERSION
  controlPlane:
    replicas: 1
  workers:
    machineDeployments:
      - class: node-pool
        name: NODE-POOL-NAME
        replicas: 1
  variables:
    - name: vmClass
      value: VM-CLASS
    # Default storageClass for control plane and node pool
    - name: storageClass
      value: STORAGE-CLASS-NAME

    ここで、

    • CLUSTER-NAME は、作成しようとしているワークロード クラスタの名前です。
    • CLUSTER-NAMESPACE はワークロード クラスタの名前空間です。
    • SERVICES-CIDR はサービスの CIDR ブロックです。たとえば、198.51.100.0/12です。
    • PODS-CIDR はポッドの CIDR ブロックです。たとえば、192.0.2.0/16です。
    • SERVICE-DOMAIN はサービス ドメイン名です。たとえば、cluster.localです。
    • TKR-VERSION はワークロード クラスタに使用しようとしている TKr のバージョンです。たとえば、v1.23.5+vmware.1-tkg.1です。
    • NODE-POOL-NAME は machineDeployments のノード プールの名前です。
    • VM-CLASS はクラスタに使用する仮想マシン クラスの名前です。たとえば、best-effort-smallです。
    • STORAGE-CLASS-NAME はクラスタに使用するストレージ クラスの名前です。たとえば、wcpglobal-storage-profileです。

    例：

    apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: my-workload-cluster
namespace: my-workload-cluster-namespace
spec:
clusterNetwork:
 services:
   cidrBlocks: ["198.51.100.0/12"]
 pods:
   cidrBlocks: ["192.0.2.0/16"]
 serviceDomain: "cluster.local"
topology:
 class: tanzukubernetescluster
 version: v1.23.5+vmware.1-tkg.1
 controlPlane:
   replicas: 1
 workers:
   machineDeployments:
     - class: node-pool
       name: my-node-pool
       replicas: 1
 variables:
   - name: vmClass
     value: best-effort-small
   # Default storageClass for control plane and node pool
   - name: storageClass
     value: wcpglobal-storage-profile

  5. 上記の手順で作成した Cluster オブジェクト定義ファイルを tanzu cluster create コマンドの -f オプションに渡して、ワークロード クラスタを作成します。

スーパーバイザーで展開された TKC ベースのクラスタの Calico CNI

タイプが TanzuKubernetesCluster の、スーパーバイザーで展開されたワークロード クラスタに antrea ではなく calico をインストールするには、ワークロード クラスタの作成に使用するクラスタ構成ファイルに CNI 構成変数を設定してから、このファイルを tanzu cluster create コマンドの -f オプションに渡します。たとえば、CNI: calico などです。

複数の CNI プロバイダを有効にする

macvlan、ipvlan、SR-IOV または DPDK など、ワークロード クラスタで複数の CNI プロバイダを有効にするには、Antrea または Calico CNI がすでに実行されているクラスタに Multus パッケージをインストールし、CNI 用の追加の NetworkAttachmentDefinition リソースを作成します。その後、異なるアドレス範囲に異なるネットワーク インターフェイスを使用する新しいポッドをクラスタに作成できます。

詳細については、「ワークロード クラスタへの Multus の展開」を参照してください。

ルーティング可能な非 NAT IP アドレス (NSX) を使用したポッドのデプロイ

NSX ネットワークと Antrea コンテナ ネットワーク インターフェイス (CNI) を使用する vSphere では、ワーカー ポッドに対してルーティング可能な IP アドレスを使用してワークロード クラスタを構成できます。これにより、ポッドとの間の外部要求に対するネットワーク アドレス変換 (NAT) をバイパスします。

ポッドのルーティング可能な IP アドレスを使用すると、以下が可能になります。

  • 共通の共有サービスへの送信要求を追跡します。これは、送信元 IP アドレスが NAT アドレスではなくルーティング可能なポッド IP アドレスであるためです。
  • NAT をバイパスし、外部インターネットから直接ポッドに入る認証済みの受信要求をサポートします。

ルーティング可能な IP ポッドの NSX の構成

ワーカー ポッドに対してルーティング可能な IP アドレスをサポートするように NSX を構成するには、次の手順を実行します。

  1. NSX サーバを参照し、ネットワーク タブを開きます。

  2. [接続] > [Tier-1 ゲートウェイ] で、[Tier-1 ゲートウェイの追加] をクリックし、ルーティング可能な IP ポッド専用の新しい Tier-1 ゲートウェイを構成します。

    • 名前：ルーティング可能なポッド T1 ゲートウェイの名前を構成します。
    • リンクされた Tier-0 ゲートウェイTanzu Kubernetes Grid の他の Tier-1 ゲートウェイで使用する Tier-0 ゲートウェイを選択します。
    • Edge クラスタ：既存の Edge クラスタを選択します。
    • ルート アドバタイズ：すべてのスタティック ルート、すべての NAT IP アドレス、および 接続されているすべてのセグメントとサービス ポート を有効にします。

    保存 をクリックしてゲートウェイを保存します。

  3. [接続] > [セグメント] で、[セグメントの追加] をクリックし、ルーティング可能なポッドを含むワークロード クラスタ ノードの新しい NSX セグメント（論理スイッチ）を構成します。

    • 名前：ワークロード クラスタ ノードのネットワーク セグメントの名前を構成します。
    • 接続：作成した Tier-1 ゲートウェイを選択します。
    • トランスポート ゾーン：tz-overlay などのオーバーレイ トランスポート ゾーンを選択します。
    • サブネット：クラスタ ノードの IP アドレス範囲を選択します（195.115.4.1/24 など）。この範囲は、DHCP プロファイルの サーバの IP アドレス 値と重複しないようにしてください。
    • ルート アドバタイズ：すべてのスタティック ルート、すべての NAT IP アドレス、および 接続されているすべてのセグメントとサービス ポート を有効にします。

    保存 をクリックしてゲートウェイを保存します。

ルーティング可能な IP アドレスを持つスーパーバイザーによって展開された TKC ポッド

ルーティング可能な非 NAT IP アドレスを持つワーカー ポッドを使用して TKC クラスタを展開する方法については、「v1beta1 の例：ルーティング可能なポッド ネットワークを使用するクラスタ」を参照してください。

ルーティング可能な IP アドレスを持つスタンドアローン管理クラスタで展開されたポッド

スタンドアローン管理クラスタを使用して、ルーティング可能な NAT なしの IP アドレスを持つワーカー ポッドを含むワークロード クラスタを展開するには、次の手順を実行します。クラスタの CLUSTER_CIDR 設定は、パブリックにルーティング可能な IP アドレスの範囲を構成します。

  1. 「ワークロード クラスタ構成ファイルの作成」の説明に従って、次のようにワークロード クラスタ構成ファイルを作成します。

    • ワーカー ポッドに割り当てられたルーティング可能な IP アドレスのブロックを設定するには、次のいずれかを実行します。
      • ワークロード クラスタ構成ファイルで CLUSTER_CIDR を設定します。または
      • 次の手順に示すように、tanzu cluster create コマンドの先頭に CLUSTER_CIDR= 設定を追加します。
    • NSXT_POD_ROUTING_ENABLEDを "true" に設定します。
    • NSXT_MANAGER_HOST を NSX Manager の IP アドレスに設定します。
    • ルーティング可能な IP アドレスに対して新しく追加された Tier-1 ゲートウェイのインベントリ パスに、NSXT_ROUTER_PATH を設定します。これは、ゲートウェイ名の左側にあるメニュー アイコン (縦の省略符号アイコンの分かりやすい表示) をクリックし、クリップボードにパスをコピー をクリックして、[NSX Manager] > [接続] > [Tier-1 ゲートウェイ] から取得します。名前は "/infra/tier-1s/ で始まります
    • 「構成ファイル変数リファレンス」の NSX ポッド ルーティング テーブルに従って、NSX にアクセスするためのその他の NSXT_ 文字列変数を設定します。ポッドは、次の 4 つの方法のいずれかで NSX を使用して認証できます。ここでは、安全性が最も高いものから低いものへと順に表示しています。
      • 証明書：NSXT_CLIENT_CERT_KEY_DATA、NSXT_CLIENT_CERT_KEY_DATA を設定し、CA によって発行された証明書に対して NSXT_ROOT_CA_DATA_B64 を設定します。
      • VMware Cloud (VMC) 上の VMware Identity Manager トークン：NSXT_VMC_AUTH_HOST と NSXT_VMC_ACCESS_TOKEN を設定します。
      • Kubernetes シークレットに保存された ユーザー名/パスワード。NSXT_SECRET_NAMESPACE、NSXT_SECRET_NAME、NSXT_USERNAME、およびNSXT_PASSWORD を設定します。
      • 構成ファイル内のプレーンテキストとしてのユーザー名/パスワード：NSXT_USERNAME と NSXT_PASSWORD を設定します。

  2. 「ワークロード クラスタの作成」の説明に従って、tanzu cluster create を実行します。例：

    $ CLUSTER_CIDR=100.96.0.0/11 tanzu cluster create my-routable-work-cluster -f my-routable-work-cluster-config.yaml
Validating configuration...
Creating workload cluster 'my-routable-work-cluster'...
Waiting for cluster to be initialized...
Waiting for cluster nodes to be available...

ルーティング可能な IP アドレスの検証

ワークロード ポッドのルーティング可能な IP アドレスをテストするには：

  1. ルーティング可能なワークロード クラスタに Web サーバを展開します。

  2. kubectl get pods --o wide を実行して、ルーティング可能なポッドの NAME、INTERNAL-IP および EXTERNAL-IP の値を取得し、リストされた IP アドレスが同一であり、ルーティング可能な CLUSTER_CIDR 範囲内にあることを確認します。

  3. kubectl get nodes --o wide を実行して、ルーティング可能な IP ポッドを含むワークロード クラスタ ノードの NAME、INTERNAL-IP および EXTERNAL-IP の値を取得します。

  4. 別のワークロード クラスタの制御プレーン ノードにログインします。

    1. kubectl config use-context CLUSTER-CONTEXT を実行して、コンテキストを別のクラスタに変更します。
    2. kubectl get nodes を実行して、現在のクラスタの制御プレーン ノードの IP アドレスを取得します。
    3. 取得した IP アドレスを使用して、ssh capv@CONTROLPLANE-IP を実行します。
    4. ping を実行して、curl 要求を Web サーバを展開したルーティング可能な IP アドレスに送信し、応答を確認します。
      • ping 出力には、Web サーバのルーティング可能なポッド IP アドレスがソース アドレスとして一覧表示されます。

  5. ブラウザから NSX にログインし、ルーティング可能な IP ポッド用に作成した Tier-1 ゲートウェイに移動します。

  6. [スタティック ルート] をクリックし、ルーティング可能な CLUSTER_CIDR 範囲内に次のルートが作成されていることを確認します。

    1. ワークロード クラスタの制御プレーン ノード内のポッドのルート。制御プレーン ノード自体のアドレスとして ネクスト ホップ が表示されます。
    2. ワークロード クラスタのワーカー ノード内のポッドのルート。ワーカー ノード自体のアドレスとして ネクスト ホップ が表示されます。

ルーティング可能な IP アドレスの削除

ルーティング可能な IP ポッドを含むワークロード クラスタを削除した後、ルーティング可能な IP アドレスを T1 ルーターから削除して解放する必要がある場合があります。

  1. [NSX Manager] > [接続] > [Tier-1 ゲートウェイ] でルーティング可能な IP ゲートウェイを選択します。

  2. [スタティック ルート] でリストを開くルートの数をクリックします。

  3. 削除されたクラスタ名を含むルートを検索し、ルート名の左側にあるメニュー アイコン (縦の省略符号アイコンの分かりやすい表示) から各ルートを削除します。

    1. 権限のエラーにより、メニューからルートを削除できない場合（ルートが証明書によって作成された場合に発生する可能性があります）、API を介してルートを削除します。
      1. ルート名の横にあるメニューから、[クリップボードにパスをコピー] を選択します。
      2. curl -i -k -u 'NSXT_USERNAME:NSXT_PASSWORD' -H 'Content-Type: application/json' -H 'X-Allow-Overwrite: true' -X DELETE https://NSXT_MANAGER_HOST/policy/api/v1/STATIC-ROUTE-PATH を実行します。
        • NSXT_MANAGER_HOST、NSXT_USERNAME、およびNSXT_PASSWORD は、NSX Manager の IP アドレスと認証情報です
        • STATIC_ROUTE_PATH は、クリップボードにコピーしたパスです。名前は /infra/tier-1s/ で始まり、/static-routes/ が含まれます。

CNI のネットワーク ポリシーの設定

ワークロード クラスタが VMware vCenter Server 管理インターフェイスにアクセスできないようにするには、Antrea と Calico CNI に適切なネットワーク ポリシーを設定します。これらのポリシーを構成すると、コンテナ ネットワークから送信されるトラフィックのみがフィルタリングされます。このポリシーは、コンテナ ストレージ インターフェイス (CSI) ポッドとクラウド プロバイダ インターフェイス (CPI) ポッドからのトラフィックを除く、すべてのポッドからのトラフィックをブロックします。

Antrea のクラスタ ネットワーク ポリシーの設定

Antrea のクラスタ ネットワーク ポリシーは、ワークロード クラスタの antrea-policy-csi-cpi.yaml ファイルを使用して設定します。これを行うには、次の手順を実行します。

  1. Tanzu CLI で、ワークロード クラスタのコンテキストに切り替えます。

    kubectl config use-context WORKLOAD-CLUSTER-CONTEXT

  2. 次の例に示すように、antrea-policy-csi-cpi.yaml ファイルを作成します。

    apiVersion: crd.antrea.tanzu.vmware.com/v1alpha1
kind: TierEntitlement
metadata:
  name: edit-system-tiers
spec:
  permission: edit
  tiers:
  - emergency
  - securityops
  - networkops
  - platform
# application and baseline Tiers are not restricted
---
apiVersion: crd.antrea.tanzu.vmware.com/v1alpha1
kind: TierEntitlementBinding
metadata:
  name: admin-edit-system-tiers
spec:
  # Allow only admin to attach Antrea ClusterNetworkPolicy and NetworkPolicy to system Tiers
  subjects:
  - kind: User
    name: admin
  tierEntitlement: edit-system-tiers
---
apiVersion: crd.antrea.io/v1alpha3
kind: ClusterGroup
metadata:
  name: vc-ip
spec:
  ipBlocks:
  - cidr: VC_IP_CIDR # Enter the IP CIDR of vCenter Server, for example 192.168.1.1/3.
---
apiVersion: crd.antrea.io/v1alpha3
kind: ClusterGroup
metadata:
  name: csi-cpi-pods
spec:
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: kube-system
    podSelector:
      matchExpressions:
      - key: k8s-app
        operator: In
        values: [vsphere-cloud-controller-manager]
---
apiVersion: crd.antrea.io/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: allow-csi-cpi-egress-vc
spec:
  priority: 5
  tier: emergency
  appliedTo:
  - group: csi-cpi-pods
  egress:
  - action: Pass
    to:
    - group: vc-ip
---
apiVersion: crd.antrea.io/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: drop-egress-vc
spec:
  priority: 10
  tier: emergency
  appliedTo:
  - namespaceSelector: {}  # Selects all Namespaces in the cluster
  egress:
  - action: Drop
    to:
    - group: vc-ip
    注

    cidr: フィールドに、vCenter Server の IP CIDR を入力します（例：192.168.1.1/32）。

  3. ファイルを適用します。

    kubectl apply -f antrea-policy-csi-cpi.yaml

Calico のネットワーク ポリシーの設定

Calico のクラスタ ネットワーク ポリシーは、ワークロード クラスタの gnp.yaml ファイルを使用して設定します。これを行うには、次の手順を実行します。

  1. オペレーティング システムの calicoctl ユーティリティ バイナリを Github の場所からダウンロードします。

  2. システムにユーティリティをインストールします。たとえば、Linux システムにユーティリティをダウンロードしてインストールするには、次を実行します。

    wget https://github.com/projectcalico/calico/releases/download/CALICO-VERSION/calicoctl-linux-amd64
mv calicoctl-linux-amd64 calicoctl
chmod +x calicoctl

  3. Tanzu CLI で、ワークロード クラスタのコンテキストに切り替えます。

    kubectl config use-context WORKLOAD-CLUSTER-CONTEXT

  4. 次の例に示すように、gnp.yaml ファイルを作成します。

    apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: vcenter-egress-deny-all
spec:
order: 1000
types:
  - Egress
egress:
  - action: Allow
    destination:
      notNets:
      -  VC_IP_CIDR # Enter the IP CIDR of vCenter Server, for example 192.168.1.1/32.

---
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: vcenter-egress-allow-csi-cpi
spec:
order: 0
types:
  - Egress
egress:
  - action: Allow
    source:
      selector: app == 'vsphere-csi-node' || app == 'vsphere-csi-controller' || k8s-app == 'vsphere-cloud-controller-manager'
    destination:
      nets:
      - VC_IP_CIDR # Enter the IP CIDR of vCenter Server, for example 192.168.1.1/32.
    注

    notNets: フィールドと nets: フィールドに、vCenter Server の IP CIDR（192.168.1.1/32 など）を入力します。

  5. ファイルを適用します。

    ./calicoctl apply -f gnp.yaml

Calico のセレクタ オプションの詳細については、Calico ドキュメントの「EntityRule」を参照してください。

ポッド セキュリティ アドミッション コントローラ（テクニカル プレビュー）

Kubernetes v1.23 以降を実行しているクラスタ内の名前空間の場合、TKG は Kubernetes ドキュメントの「ポッドのセキュリティ標準」で説明するように、ポッド セキュリティ アドミッション (PSA) コントローラを介して privileged、baseline、restricted タイプのポッド セキュリティ ポリシーの適用をサポートします。

注

この機能は、サポートされていない「テクニカル プレビュー」状態です。「TKG の機能状態」を参照してください。

ノードのポッド セキュリティ ポリシー (PSP) は、Kubernetes において廃止されたことを踏まえて、TKG v2.1 では廃止になります。ポッドを PSP から PSA コントローラに移行する方法については、「PodSecurityPolicy から組み込みのポッド セキュリティ アドミッション コントローラへの移行」を参照してください。

デフォルトでは、Kubernetes v1.24 クラスタ名前空間のポッド セキュリティ warn および audit のモードが baseline に設定されています。これは、強制力のない設定です。つまり、PSA コントローラに移行することにより、ポリシーに違反しているポッドに関する警告が生成される可能性がありますが、ポッドは実行し続けることができます。

一部の TKG パッケージとコンポーネントが baseline モードに準拠しないことは既知の問題です。このような場合の最速の回避策は、影響を受ける名前空間のラベル audit=privileged および warn=privileged を設定して、違反監査のメッセージと警告を表示しないようにすることです。

kubectl label --overwrite ns NAMESPACE pod-security.kubernetes.io/audit=privileged
kubectl label --overwrite ns NAMESPACE pod-security.kubernetes.io/warn=privileged

ここで、NAMESPACE は、以下に一覧表示されているインストール済みパッケージまたはその他のコンポーネントの名前空間です。

名前空間 パッケージまたはコンポーネント
avi-system AKO (load-balancer-and-ingress-service)
cert-manager Cert Manager
pinniped-concierge Pinniped
sonobuoy Sonobuoy
tanzu-auth Auth サービス（スタンドアローン管理クラスタの場合）
tanzu-system-ingress Contour、Envoy
tanzu-system-logging Fluent Bit
tanzu-system-monitoring Prometheus
velero Restic、Velero
vmware-system-auth Auth サービス（スーパーバイザーの場合）

これらの名前空間には、パッケージ自体がインストールされる、ユーザーが選択した名前空間や default とは異なるパッケージ コンポーネントが含まれます。

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