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

ノード ネットワーク

このトピックでは、ノード IP アドレスのカスタマイズや、vSphere での DHCP 予約、ノード IP アドレス管理、IPv6 の構成など、ワークロード クラスタのノード ネットワークをカスタマイズする方法について説明します。

ノードの DHCP 予約とエンドポイント DNS レコードの構成(vSphere のみ)

vSphere 上の新しいクラスタの場合は、ノードの DHCP 予約を作成する必要があります。また、場合によっては制御プレーン エンドポイントの DNS レコードを作成する必要があります。

  • クラスタ ノードの DHCP 予約:

    複数の制御プレーン ノードが長時間パワーオフまたはオフラインになる可能性がある環境での安全上の予防策として、新しく作成されたクラスタの制御プレーンとワーカー ノードの IP アドレスの DHCP 予約を調整して、アドレスが固定のままになり、リースが期限切れにならないようにします。

    DHCP 予約の構成方法については、DHCP サーバのドキュメントを参照してください。

  • 制御プレーン エンドポイントの DNS レコード:

    制御プレーン エンドポイントに Kube-Vip ではなく NSX Advanced Load Balancer を使用し、VSPHERE_CONTROL_PLANE_ENDPOINT を数値の IP アドレスではなく FQDN に設定する場合は、次のようにアドレスを予約します。

    1. NSX ALB がクラスタに割り当てた制御プレーンの IP アドレスを取得します。

      kubectl get cluster CLUSTER-NAME -o=jsonpath='{.spec.controlPlaneEndpoint} {"\n"}'
      
    2. 出力に "host" と表示されている IP アドレス(192.168.104.107 など)を記録します。

    3. 記録した IP アドレスに FQDN を関連付ける DNS A レコードを作成します。

    4. FQDN をテストするには、NSX ALB の IP アドレスの代わりに FQDN を使用する新しい kubeconfig を作成します。

      1. kubeconfig を生成します。

        tanzu cluster kubeconfig get CLUSTER-NAME --admin --export-file ./KUBECONFIG-TEST
        
      2. kubeconfig ファイルKUBECONFIG-TEST を編集して、IP アドレスを FQDN に置き換えます。たとえば、次の IP アドレスがあるとします。

        server: https://192.168.104.107:443
        

        これを以下に置き換えます。

        server: https://CONTROLPLANE-FQDN:443
        
      3. 変更した kubeconfig を使用してクラスタのポッドを取得します。

        kubectl get pods -A --kubeconfig=./KUBECONFIG-TEST
        

        出力にポッドが一覧表示されている場合、DNS は FQDN に対して機能します。

クラスタ ノードの IP アドレスのカスタマイズ(スタンドアローン MC)

スタンドアローン管理クラスタおよびそれらが展開するワークロード クラスタ内のノードに対して、クラスタ固有の IP アドレス ブロックを構成できます。これを行う方法は、クラスタが実行されているクラウド インフラストラクチャによって異なります。

vSphere

vSphere では、クラスタ構成ファイルの VSPHERE_NETWORK は、Tanzu Kubernetes Grid がクラスタ ノードおよびその他の Kubernetes オブジェクトに使用する、仮想マシン ネットワークを設定します。IP アドレスは、この仮想マシン ネットワークで実行される DHCP サーバによってノードに割り当てられ、Tanzu Kubernetes Grid とは別に展開されます。

NSX ネットワークを使用している場合は、VMware NSX-T Data Center ドキュメントの「セグメントの DHCP 静的バインドの構成」に従って、クラスタ ノードの DHCP バインドを構成できます。

v4.0 以降では、VMware NSX-T Data Center の名前が「VMware NSX」に変更されました。

AWS

Amazon Web Services (AWS) でクラスタ固有の IP アドレス ブロックを構成するには、「構成ファイル変数リファレンス」の AWS の表に説明されているように、クラスタ構成ファイルに次の変数を設定します。

  • パブリック ノードの IP アドレス範囲を設定するには、AWS_PUBLIC_NODE_CIDR を設定します。
    • AWS_PRIVATE_NODE_CIDR_1 または AWS_PRIVATE_NODE_CIDR_2 を設定して、追加の範囲を使用できるようにします。
  • プライベート ノードの IP アドレス範囲を設定するには、AWS_PRIVATE_NODE_CIDR を設定します。
    • AWS_PRIVATE_NODE_CIDR_1 および AWS_PRIVATE_NODE_CIDR_2を設定して、追加の範囲を使用できるようにします。
  • すべてのノード CIDR 範囲は、クラスタの VPC 範囲内である必要があります。デフォルトは 10.0.0.0/16 です。

Microsoft Azure

Azure でクラスタ固有の IP アドレス ブロックを構成するには、「構成ファイル変数リファレンス」の Microsoft Azure の表の説明に従って、クラスタ構成ファイルに次の変数を設定します。

  • ワーカー ノードの IP アドレスの CIDR ブロックを使用して新しい VNet を作成するには、AZURE_NODE_SUBNET_CIDR を設定します。
  • 制御プレーン ノードの IP アドレスの CIDR ブロックを使用して新しい VNet を作成するには、AZURE_CONTROL_PLANE_SUBNET_CIDR を設定します。
  • 既存の VNet の範囲からワーカー ノードの IP アドレスを割り当てるには、AZURE_NODE_SUBNET_NAME を設定します。
  • 既存の VNet の範囲から制御プレーン ノードの IP アドレスを割り当てるには、AZURE_CONTROL_PLANE_SUBNET_NAME を設定します。

ノード IP アドレス管理 (vSphere)

ノード IP アドレス管理では、クラスタ内 IP アドレス管理プロバイダが、クラスタの作成時やスケーリング中にクラスタ ノードの IP アドレスを割り当てて管理するため、外部 DHCP を構成する必要がなくなります。

vSphere 上のスタンドアローン管理クラスタと、それらが管理するクラスベースのワークロード クラスタに対するノード IP アドレス管理を構成できます。以下の手順では、クラスベースのワークロード クラスタ用にノード IP アドレス管理を構成します。管理クラスタのノード IP アドレス管理を構成するには、「vSphere の管理クラスタ構成」の「ノード IP アドレス管理の構成」を参照してください。

この手順は、vSphere with Tanzu スーパーバイザーを使用する TKG や、AWS または Azure 上のスタンドアローン管理クラスタを使用する TKG には適用されません。

新規または既存のワークロード クラスタのノード IP アドレス管理を構成する場合は、ユーザーが、IP アドレス管理プロバイダによって割り当てられる固定 IP アドレスの取得元の内部 IP アドレス プールと、ゲートウェイ アドレスを指定します。

クラスタ ノードにアドレスを割り当てると、ノード IP アドレス管理は常にプール内で使用可能な最下位アドレスを選択します。

前提条件

  • TKG スタンドアローン管理クラスタ
  • ワークロード クラスタの制御プレーンノードとワーカー ノードのネームサーバ
    • クラスタ ノードが DHCP を介してネームサーバを受信して vCenter Server で名前を解決しなくなったため、必須となります。
  • ローカルにインストールされた kubectl および Tanzu CLI

制限

ノード IP アドレス管理には、TKG v2.4 で次の制限があります。

  • vSphere 上の管理クラスタによって展開された、新しいクラスベースのワークロード クラスタにのみ対応します。
    • 既存の DHCP ベースのクラスタをノード IP アドレス管理に変換することはできません。
  • Windows ノードはサポート対象外です。
  • デュアル スタックではなく、IPv4 または IPv6 環境でのみ使用可能です。
  • 割り当てるのはノードのアドレスのみで、クラスタ制御プレーンのエンドポイントは割り当てません。
  • ノード IP アドレス管理では、IP アドレス プールが他のクラスタですでに使用されている DHCP プールと競合するかどうかは確認されません。

ワークロード クラスタ用のノード IP アドレス管理の構成

ワークロード クラスタのノード IP アドレス管理プールは、そのアドレスが他のクラスタとどのように共有されているかに応じて、2 つの異なるオブジェクト タイプによって定義できます。

  • InClusterIPPool は、default など、同じ管理クラスタ名前空間内のワークロード クラスタでのみ使用できる IP アドレス プールを構成します。
    • これは、TKG v2.1 および v2.2 では使用可能な唯一のタイプでした。
  • GlobalInClusterIPPool は、複数の名前空間にまたがるワークロード クラスタに割り当てることができるアドレスを使用して IP アドレス プールを構成します。

ノード IP アドレス管理を使用して新規または既存のクラスタを構成するには、次の手順を実行します。

  1. ワークロード クラスタに固定 IP アドレスを割り当てるために TKG が使用できるサブネットからの IP アドレスの範囲を設定する、IP アドレス プール オブジェクト定義ファイル my-ip-pool.yaml を作成します。IP アドレス プールの範囲を設定する方法に基づいて、オブジェクトを InClusterIPPool または GlobalInClusterIPPool として定義します。例:

    • InClusterIPPool10.10.10.2-10.10.10.100 の範囲に加えて 10.10.10.10210.10.10.104 を含む名前空間 default にワークロード クラスタの IP アドレス プール inclusterippool を作成します:

      apiVersion: ipam.cluster.x-k8s.io/v1alpha2
      kind: InClusterIPPool
      metadata:
        name: inclusterippool
        namespace: default
      spec:
        gateway: 10.10.10.1
        addresses:
        - 10.10.10.2-10.10.10.100
        - 10.10.10.102
        - 10.10.10.104
        prefix: 24
      

      以前の TKG バージョンでは、InClusterIPPool オブジェクトの valpha1 バージョンが使用されていました。これは、TKG v2.1 のドキュメントで説明するように、startend で指定された連続する IP アドレス プール範囲のみをサポートしていました。クラスタを v2.4 にアップグレードすると、IP アドレス プールが新しい構造に変換されます。

    • GlobalInClusterIPPool:上記の InClusterIPPool と同じアドレスを含む名前空間間で共有する IP アドレス プール inclusterippool を作成します。

      apiVersion: ipam.cluster.x-k8s.io/v1alpha2
      kind: GlobalInClusterIPPool
      metadata:
        name: inclusterippool
      spec:
        gateway: 10.10.10.1
        addresses:
        - 10.10.10.2-10.10.10.100
        - 10.10.10.102
        - 10.10.10.104
        prefix: 24
      
  2. IP アドレス プール オブジェクトを作成します。

    kubectl apply -f my-ip-pool.yaml
    
  3. 構成ファイル」の説明に従って、フラットなクラスタ構成ファイルまたは Kubernetes スタイルのオブジェクト仕様内で IP アドレス プールを使用するようにワークロード クラスタを構成します。

    例:

    • フラットな構成ファイル(新しいクラスタを作成する場合):

      # The name of the InClusterIPPool object specified above
      NODE_IPAM_IP_POOL_NAME: inclusterippool
      CONTROL_PLANE_NODE_NAMESERVERS: 10.10.10.10,10.10.10.11
      WORKER_NODE_NAMESERVERS: 10.10.10.10,10.10.10.11
      
    • オブジェクト仕様(新しいクラスタを作成または既存のクラスタを変更する場合):

      ---
      apiVersion: cluster.x-k8s.io/v1beta1
      kind: Cluster
      spec:
      topology:
        variables:
        - name: network
          value:
            addressesFromPools:
            - apiGroup: ipam.cluster.x-k8s.io
              kind: InClusterIPPool
              name: inclusterippool
        - name: controlplane
          value:
            network:
              nameservers: [10.10.10.10,10.10.10.11]
        - name: worker
          value:
            network:
              nameservers: [10.10.10.10,10.10.10.11]
      

これで、ワークロード クラスタを展開できるようになります。

プールのルール

  • IP アドレス プールの範囲の重複を避ける
    • プールが重複すると、障害が発生する可能性があります。TKG では、プール範囲の検証や重複の検出は行われません。
  • 現在割り当てられている IP アドレスを IP アドレス プールから削除しないでください。

ノード IP アドレス管理のトラブルシューティング

  • クラスタ ノードに IP アドレスが割り当てられているかどうかを確認するには、kubectl get を実行して、IaaS 固有のマシン オブジェクト vspherevms を一覧表示し、それらの IPAddressClaimed ステータスを確認します。True は、ノードのアドレス要求が成功したことを意味します。ステータスが False の場合は、コマンド出力に条件が整っていないことの Reason がレポートされます。

    kubectl -n CLUSTER-NAMESPACE get vspherevms
    
  • IP アドレス要求を表示するには、ipaddressclaims を一覧表示します。マシンごとに、addressesFromPools エントリにより 1 つのIPAddressClaim が作成されます。

    kubectl -n CLUSTER-NAMESPACE get ipaddressclaims
    
  • IP アドレスを表示するには、ipaddress を一覧表示します。クラスタ内の IP アドレス管理プロバイダは、各 IPAddressClaim を検出し、対応する IPAddress オブジェクトを作成する必要があります。

    kubectl -n CLUSTER-NAMESPACE get ipaddress
    
  • 特定の仮想マシンのすべての要求が IP アドレスと一致すると、CAPV は割り当てられた IP アドレスを仮想マシンの cloud-init メタデータに書き込み、仮想マシンを作成します。IP アドレスの調整手順を確認するには、次の CAPV およびクラスタ API IP アドレス管理プロバイダ (CAIP) のログを参照してください。

    kubectl logs -n capv-system capv-controller-manager
    kubectl logs -n caip-in-cluster-system capi-in-cluster-controller-manager
    

IPv6 ネットワーク (vSphere)

Ubuntu ベースのノードを使用して、Kube-Vip を使用する vSphere 上の IPv6 のみの単一スタック ネットワーク環境で管理クラスタとワークロード クラスタを実行できます。

vSphere with Tanzu スーパーバイザー クラスタを使用して IPv6 クラスタを作成することはできません。Tanzu Mission Control に IPv6 クラスタを登録することはできません。NSX Advanced Load Balancer サービスとデュアル スタック IPv4/IPv6 ネットワークは現在サポートされていません。

前提条件:

IPv6 管理クラスタの展開

ブートストラップ マシンで次の手順を実行して、管理クラスタを IPv6 ネットワーク環境に展開します。

  1. ルーターのアドバタイズを受け入れるように Linux を構成し、Docker サービスの起動時にデフォルトの IPv6 ルートがルーティング テーブルから削除されないようにします。詳細については、「Docker CE が IPv6 のデフォルト ルートを削除する」を参照してください。sudo sysctl net.ipv6.conf.eth0.accept_ra=2

  2. ブートストラップ クラスタから送信トラフィックを送信するためのブートストラップ クラスタのマスカレード ルールを作成します。sudo ip6tables -t nat -A POSTROUTING -s fc00:f853:ccd:e793::/64 ! -o docker0 -j MASQUERADE マスカレード ルールの詳細については、「MASQUERADE」を参照してください。

  3. 管理クラスタに対して、以下の構成ファイルの変数を設定します。

    • TKG_IP_FAMILYipv6 に設定します。
    • VSPHERE_CONTROL_PLANE_ENDPOINT を固定 IPv6 アドレスに設定します。
    • (オプション)CLUSTER_CIDR and SERVICE_CIDR を設定します。デフォルトでは、それぞれ fd00:100:64::/48 および fd00:100:96::/108 になります。
  4. 構成ファイルからの管理クラスタの展開」の説明に従って、tanzu mc create を実行して管理クラスタを展開します。

    • IPv6 をサポートするには、インストーラのインターフェイスではなく、構成ファイルから管理クラスタを展開する必要があります。

IPv6 ワークロード クラスタの展開

IPv6 管理クラスタを展開している場合は、次のように IPv6 ワークロード クラスタを展開します。

  1. ワークロード クラスタに対して、以下の構成ファイルの変数を設定します。

    • TKG_IP_FAMILYipv6 に設定します。
    • VSPHERE_CONTROL_PLANE_ENDPOINT を固定 IPv6 アドレスに設定します。
    • (オプション)CLUSTER_CIDR and SERVICE_CIDR を設定します。デフォルトでは、それぞれ fd00:100:64::/48 および fd00:100:96::/108 になります。
  2. ワークロード クラスタの作成」の説明に従って、ワークロード クラスタを展開します。

デュアルスタック クラスタ(テクニカル プレビュー)

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

デュアルスタック機能を使用すると、IPv4 および IPv6 IP ファミリを使用してクラスタを展開できます。ただし、プライマリ IP ファミリは IPv4 です。この機能を試験的に使用する前に、IPv4 と IPv6 の両方の接続をサポートするように vCenter Server を構成します。

このリリースのデュアルスタック機能の制限は次のとおりです。

  • デュアルスタック機能は、vSphere を唯一の IaaS (Infrastructure as a Service) 製品としてサポートします。

  • Photon OS ノードを使用するクラスタでは、デュアル スタックを構成できません。ubuntuOS_NAME で構成されたクラスタのみがサポートされます。

  • vSphere with Tanzu スーパーバイザー クラスタまたはそれらによって作成されるワークロード クラスタに対しては、デュアル スタック ネットワークを構成できません。

  • インストーラ インターフェイスを使用してデュアルスタック管理クラスタを展開することはできません。

  • NSX Advanced Load Balancer (ALB) によって提供されるロード バランサ サービスでは、デュアル スタック サービスまたは IPv6 サービスを使用できません。kube-vip は、デュアルスタック クラスタの制御プレーン エンドポイント プロバイダとして使用できます。デュアルスタック クラスタの制御プレーン エンドポイント プロバイダとして NSX ALB を使用することは未検証です。

  • 今回のリリースでは、Antrea、Calico、CSI、CPI、Pinniped などの主要なアドオン コンポーネントのみがデュアルスタック サポートに対して検証されています。

クラスタでデュアルスタックを構成するには、次の手順を実行します。

  1. デュアルスタック機能フラグを設定します。

    a. 管理クラスタでこの機能を有効にするには、次のコマンドを実行します。

    tanzu config set features.management-cluster.dual-stack-ipv4-primary true
    

    b. ワークロード クラスタでこの機能を有効にするには、次のコマンドを実行します。

    tanzu config set features.cluster.dual-stack-ipv4-primary true
    
  2. 必要に応じて、管理クラスタの展開またはワークロード クラスタの作成を行います。

    クラスタ構成ファイルで、次の手順を実行します。

    • IP ファミリの構成変数 TKG_IP_FAMILY: ipv4,ipv6 を設定します。
    • オプションで、サービス CIDR とクラスタ CIDR を設定します。

    変数ごとに 2 つの CIDR があります。これらの CIDR の IP ファミリは、構成された TKG_IP_FAMILY の順序に従います。IPv4 アドレスに許可される最大の CIDR 範囲は /12 で、最大の IPv6 SERVICE_CIDR 範囲は /108 です。CIDR を設定しない場合は、デフォルト値が使用されます。

    • クラスタの CNI として Antrea を使用している場合は、次の構成ファイル パラメータを設定します。

      ANTREA_ENDPOINTSLICES: true
      

    PreferDualStack または RequireDualStack の仕様で指定されている ipFamilyPolicy があるサービスは、IPv4 または IPv6 経由でアクセスできるようになりました。

クラスタ ノードがプライマリ IP アドレス(この場合は IPv4 アドレス)のみを IP アドレスとして広報するため、アップストリーム Kubernetes のデュアルスタック機能のエンドツーエンドのテストが失敗することがあります。

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