ノードネットワーク

このトピックでは、ノード 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 アドレス管理

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

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

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

IP アドレスプールは、サブネット CIDR 内のアドレス範囲を制限するために、オプションの start および end アドレスを使用した subnet として構成されます。

次の図は、ノード IP アドレス管理で CAPV がどのように IP アドレスプールから固定ノードアドレスを構成できるかを示しています。ノード IP アドレス管理に固有のコンポーネント（実線の枠線）とリソース定義（破線の枠線）が、緑色で示されます。

ノード IP アドレス管理のボックスと線

前提条件

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

制限

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

vSphere 上の管理クラスタによって展開された、クラスベースのワークロードクラスタにのみ対応します。
Windows ノードはサポート対象外です。
IPv6 やデュアルスタックではなく、IPv4 環境でのみ使用可能です。
割り当てるのはノードのアドレスのみで、クラスタ制御プレーンのエンドポイントは割り当てません。
既存のクラスタのノード IP アドレス管理を構成する場合に、その IP アドレスプールと、クラスタですでに使用されている DHCP プールが競合しているかどうかを確認しません。
設計上、IP アドレスプールは名前空間に固有のものであり、複数の名前空間にわたって共有することはできません。
- 複数の名前空間にわたって実行されるクラスタでは、アドレス範囲が重複していない IP アドレスプールが各名前空間に必要です。
- IP アドレスプールのその他の制限については、以下の「プールのルール」を参照してください。

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

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

ワークロードクラスタに固定 IP アドレスを割り当てるために TKG が使用できるサブネットからの IP アドレスの範囲を設定する、InClusterIPPool オブジェクト定義を作成します。たとえば、default 名前空間内のクラスタ用に 10.10.10.200 から 10.10.10.250 までを予約するオブジェクト inclusterippool を作成します。

---
apiVersion: ipam.cluster.x-k8s.io/v1alpha1
kind: InClusterIPPool
metadata:
  name: inclusterippool
  # the namespace where the workload cluster is deployed
  namespace: default
spec:
  # replace the IPs below with what works for your environment
  subnet: 10.10.10.0/24
  gateway: 10.10.10.1
  # start and end are optional fields that restrict the allocatable address range
  # within the subnet
  start: 10.10.10.200
  end: 10.10.10.250

InClusterIPPool オブジェクトを作成します。
```
kubectl apply -f my-ip-pool.yaml
```
Tanzu CLI 構成でカスタムネームサーバ機能を有効にします。
```
tanzu config set features.cluster.custom-nameservers true
```

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

例：

フラットな構成ファイル（新しいクラスタを作成する場合）：

# The name of the InClusterIPPool object specified above
NODE_IPAM_IP_POOL_NAME: inclusterippool
CONTROL_PLANE_NODE_NAMESERVERS: 10.10.10.10
WORKER_NODE_NAMESERVERS: 10.10.10.10

オブジェクト仕様（新しいクラスタを作成または既存のクラスタを変更する場合）：

---
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]
  - name: worker
    value:
      network:
        nameservers: [10.10.10.10]

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

プールのルール

IP アドレスプールの範囲の重複を避ける
- プールが重複すると、障害が発生する可能性があります。TKG では、プール範囲の検証や重複の検出は行われません。
アクティブな InClusterIPPool オブジェクトを新しいプールで更新しない
- 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 スーパーバイザークラスタ、または vSphere 8 のスタンドアローン管理クラスタを使用して IPv6 クラスタを作成することはできません。Tanzu Mission Control に IPv6 クラスタを登録することはできません。NSX Advanced Load Balancer サービスとデュアルスタック IPv4/IPv6 ネットワークは現在サポートされていません。

前提条件:

ブートストラップクラスタからアクセス可能な IPv6 アドレスの vSphere を構成します。
ブートストラップクラスタからアクセス可能な IPv6 アドレスを使用して、Docker デーモンで DNS リゾルバを構成します。
IPv6 クラスタが IPv4 ネットワークにアクセスする必要がある場合は、一般的に、「プロキシ設定」の説明に従って HTTP プロキシを構成します。

IPv6 管理クラスタの展開

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

ルーターのアドバタイズを受け入れるように Linux を構成し、Docker サービスの起動時にデフォルトの IPv6 ルートがルーティングテーブルから削除されないようにします。詳細については、「Docker CE が IPv6 のデフォルトルートを削除する」を参照してください。sudo sysctl net.ipv6.conf.eth0.accept_ra=2
ブートストラップクラスタから送信トラフィックを送信するためのブートストラップクラスタのマスカレードルールを作成します。sudo ip6tables -t nat -A POSTROUTING -s fc00:f853:ccd:e793::/64 ! -o docker0 -j MASQUERADE マスカレードルールの詳細については、「MASQUERADE」を参照してください。
管理クラスタに対して、以下の構成ファイルの変数を設定します。
- TKG_IP_FAMILYを ipv6 に設定します。
- VSPHERE_CONTROL_PLANE_ENDPOINT を固定 IPv6 アドレスに設定します。
- （オプション）CLUSTER_CIDR and SERVICE_CIDR を設定します。デフォルトでは、それぞれ fd00:100:64::/48 および fd00:100:96::/108 になります。
「構成ファイルからの管理クラスタの展開」の説明に従って、tanzu mc create を実行して管理クラスタを展開します。
- IPv6 をサポートするには、インストーラのインターフェイスではなく、構成ファイルから管理クラスタを展開する必要があります。

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

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

ワークロードクラスタに対して、以下の構成ファイルの変数を設定します。
- TKG_IP_FAMILYを ipv6 に設定します。
- VSPHERE_CONTROL_PLANE_ENDPOINT を固定 IPv6 アドレスに設定します。
- （オプション）CLUSTER_CIDR and SERVICE_CIDR を設定します。デフォルトでは、それぞれ fd00:100:64::/48 および fd00:100:96::/108 になります。
「ワークロードクラスタの作成」の説明に従って、ワークロードクラスタを展開します。

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

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

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

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

デュアルスタック機能は、vSphere を唯一の IaaS (Infrastructure as a Service) 製品としてサポートします。
Photon OS ノードを使用するクラスタでは、デュアルスタックを構成できません。ubuntu の OS_NAME で構成されたクラスタのみがサポートされます。
vSphere with Tanzu スーパーバイザークラスタまたはそれらによって作成されるワークロードクラスタに対しては、デュアルスタックネットワークを構成できません。
インストーラインターフェイスを使用してデュアルスタック管理クラスタを展開することはできません。
NSX Advanced Load Balancer (ALB) によって提供されるロードバランササービスでは、デュアルスタックサービスまたは IPv6 サービスを使用できません。kube-vip は、デュアルスタッククラスタの制御プレーンエンドポイントプロバイダとして使用できます。デュアルスタッククラスタの制御プレーンエンドポイントプロバイダとして NSX ALB を使用することは未検証です。
今回のリリースでは、Antrea、Calico、CSI、CPI、Pinniped などの主要なアドオンコンポーネントのみがデュアルスタックサポートに対して検証されています。

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

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

a. 管理クラスタでこの機能を有効にするには、次のコマンドを実行します。
```
tanzu config set features.management-cluster.dual-stack-ipv4-primary true
```
b. ワークロードクラスタでこの機能を有効にするには、次のコマンドを実行します。
```
tanzu config set features.cluster.dual-stack-ipv4-primary true
```
必要に応じて、管理クラスタの展開またはワークロードクラスタの作成を行います。

クラスタ構成ファイルで、次の手順を実行します。
- 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 のデュアルスタック機能のエンドツーエンドのテストが失敗することがあります。

ノード ネットワーク