v1beta1 API を使用して、ルーティング可能なポッド ネットワークが構成されたクラスタを作成できます。そのためには、デフォルト クラスタを AntreaConfig および VSphereCPIConfig のカスタム構成でオーバーライドします。

v1beta1 API を使用したルーティング可能なポッド ネットワークについて

次のサンプル YAML では、v1beta1 API を使用して Antrea のルーティング可能なポッドが有効なクラスタをプロビジョニングする方法を示します。この例は、「v1beta1 の例:デフォルト クラスタ」を基準にしています。

ルーティング可能なポッド機能を有効にするには、特別な構成の AntreaConfigVSphereCPIConfig がクラスタに必要です。

AntreaConfig では、trafficEncapMode: noEncapnoSNAT: true を設定する必要があります。

VSphereCPIConfig では、 antreaNSXPodRoutingEnabled: truemode: vsphereParavirtualCPI、および以下の設定が必要です。
tlsCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

AntreaConfig の名前の形式は、<cluster-name>-antrea-package にする必要があります。VSphereCPIConfig の名前の形式は、<cluster-name>-vsphere-cpi-package にする必要があります。

構成ファイルが作成されたら、構成ファイルを参照するクラスタ仕様オブジェクトを作成します。クラスタの作成時に、構成ファイルを使用してクラスタをプロビジョニングし、デフォルトの構成を上書きします。

ルーティング可能なポッド ネットワークの作成:スーパーバイザー 構成

ルーティング可能なポッド ネットワークを作成するには、 スーパーバイザー と TKG クラスタで構成を行う必要があります。
注: ルーティング可能なポッド ネットワークを使用するには、NSX に スーパーバイザー を構成する必要があります。VDS ネットワークでは、ルーティング可能なポッドを使用することはできません。
ルーティング可能なポッド ネットワークを スーパーバイザー で構成するには、次の手順を実行します。
  1. 新しい vSphere 名前空間 を作成します。

    スーパーバイザー 上の TKG クラスタをホストするための vSphere 名前空間 の作成を参照してください。

  2. [スーパーバイザー ネットワーク設定のオーバーライド] チェックボックスをオンにします。

    詳細については、vSphere 名前空間 の スーパーバイザー ネットワーク設定のオーバーライドを参照してください。

  3. [NAT モード] をオフにします。
  4. [名前空間ネットワーク] に、ルーティング可能なサブネットを入力します。NCP によって、ネットワークに指定された IP ブロックから 1 つ以上の IP プールが作成されます。
  5. ルーティング可能な[名前空間ネットワーク]を追加した後で、それがクラスタ ノードの IP アドレスを割り当てる[サービス CIDR] と重複していないことを確認します。

ルーティング可能なポッド ネットワークの作成:TKG クラスタの構成

次のサンプル YAML は、ルーティング可能なポッド ネットワークを使用して v1beta1 クラスタを構成する方法を示します。

以下の例に示すように、ポッドの IP アドレスは cloud-provider-vsphere によって割り当てられるため、クラスタ仕様から spec.clusterNetwork.pod セクションを削除する必要があります。
注: この例は単一の YAML ファイルとして提供されますが、個別のファイルに分割することができます。分割する場合は、最初に AntreaConfig および VSphereCPIConfig カスタム リソース、次に target-cluster クラスタの順に作成する必要があります。
---
apiVersion: cni.tanzu.vmware.com/v1alpha1
kind: AntreaConfig
metadata:
 name: target-cluster-antrea-package
spec:
 antrea:
   config:
     defaultMTU: ""
     disableUdpTunnelOffload: false
     featureGates:
       AntreaPolicy: true
       AntreaProxy: true
       AntreaTraceflow: true
       Egress: false
       EndpointSlice: true
       FlowExporter: false
       NetworkPolicyStats: false
       NodePortLocal: false
     noSNAT: true
     tlsCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384
     trafficEncapMode: noEncap
---
apiVersion: cpi.tanzu.vmware.com/v1alpha1
kind: VSphereCPIConfig
metadata:
 name: target-cluster-vsphere-cpi-package
spec:
 vsphereCPI:
   antreaNSXPodRoutingEnabled: true
   insecure: false
   mode: vsphereParavirtualCPI
   tlsCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
 name: target-cluster
spec:
 clusterNetwork:
   services:
     cidrBlocks: ["198.51.100.0/12"]
   serviceDomain: "cluster.local"
 topology:
   class: tanzukubernetescluster
   version: v1.25.7---vmware.3-fips.1-tkg.1
   controlPlane:
     replicas: 3
   workers:
     machineDeployments:
       - class: node-pool
         name: node-pool-1
         replicas: 3
   variables:
     - name: vmClass
       value: guaranteed-medium
     - name: storageClass
       value: tkg2-storage-policy