このトピックでは、ノード IP アドレスのカスタマイズや、vSphere での DHCP 予約、ノード IP アドレス管理、IPv6 の構成など、ワークロード クラスタのノード ネットワークをカスタマイズする方法について説明します。
vSphere 上の新しいクラスタの場合は、ノードの DHCP 予約を作成する必要があります。また、場合によっては制御プレーン エンドポイントの DNS レコードを作成する必要があります。
クラスタ ノードの DHCP 予約:
複数の制御プレーン ノードが長時間パワーオフまたはオフラインになる可能性がある環境での安全上の予防策として、新しく作成されたクラスタの制御プレーンとワーカー ノードの IP アドレスの DHCP 予約を調整して、アドレスが固定のままになり、リースが期限切れにならないようにします。
DHCP 予約の構成方法については、DHCP サーバのドキュメントを参照してください。
制御プレーン エンドポイントの DNS レコード:
制御プレーン エンドポイントに Kube-Vip ではなく NSX Advanced Load Balancer を使用し、VSPHERE_CONTROL_PLANE_ENDPOINT
を数値の IP アドレスではなく FQDN に設定する場合は、次のようにアドレスを予約します。
NSX ALB がクラスタに割り当てた制御プレーンの IP アドレスを取得します。
kubectl get cluster CLUSTER-NAME -o=jsonpath='{.spec.controlPlaneEndpoint} {"\n"}'
出力に "host"
と表示されている IP アドレス(192.168.104.107
など)を記録します。
記録した IP アドレスに FQDN を関連付ける DNS A
レコードを作成します。
FQDN をテストするには、NSX ALB の IP アドレスの代わりに FQDN を使用する新しい kubeconfig を作成します。
kubeconfig を生成します。
tanzu cluster kubeconfig get CLUSTER-NAME --admin --export-file ./KUBECONFIG-TEST
kubeconfig ファイルKUBECONFIG-TEST
を編集して、IP アドレスを FQDN に置き換えます。たとえば、次の IP アドレスがあるとします。
server: https://192.168.104.107:443
これを以下に置き換えます。
server: https://CONTROLPLANE-FQDN:443
変更した kubeconfig を使用してクラスタのポッドを取得します。
kubectl get pods -A --kubeconfig=./KUBECONFIG-TEST
出力にポッドが一覧表示されている場合、DNS は FQDN に対して機能します。
スタンドアローン管理クラスタおよびそれらが展開するワークロード クラスタ内のノードに対して、クラスタ固有の IP アドレス ブロックを構成できます。これを行う方法は、クラスタが実行されているクラウド インフラストラクチャによって異なります。
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」に変更されました。
Amazon Web Services (AWS) でクラスタ固有の IP アドレス ブロックを構成するには、「構成ファイル変数リファレンス」の AWS の表に説明されているように、クラスタ構成ファイルに次の変数を設定します。
AWS_PUBLIC_NODE_CIDR
を設定します。
AWS_PRIVATE_NODE_CIDR_1
または AWS_PRIVATE_NODE_CIDR_2
を設定して、追加の範囲を使用できるようにします。AWS_PRIVATE_NODE_CIDR
を設定します。
AWS_PRIVATE_NODE_CIDR_1
および AWS_PRIVATE_NODE_CIDR_2
を設定して、追加の範囲を使用できるようにします。10.0.0.0/16
です。Azure でクラスタ固有の IP アドレス ブロックを構成するには、「構成ファイル変数リファレンス」の Microsoft Azure の表の説明に従って、クラスタ構成ファイルに次の変数を設定します。
AZURE_NODE_SUBNET_CIDR
を設定します。AZURE_CONTROL_PLANE_SUBNET_CIDR
を設定します。AZURE_NODE_SUBNET_NAME
を設定します。AZURE_CONTROL_PLANE_SUBNET_NAME
を設定します。ノード IP アドレス管理では、クラスタ内 IP アドレス管理プロバイダが、クラスタの作成時やスケーリング中にクラスタ ノードの IP アドレスを割り当てて管理するため、外部 DHCP を構成する必要がなくなります。
vSphere 上のスタンドアローン管理クラスタと、それらが管理するクラスベースのワークロード クラスタに対するノード IP アドレス管理を構成できます。以下の手順では、クラスベースのワークロード クラスタ用にノード IP アドレス管理を構成します。管理クラスタのノード IP アドレス管理を構成するには、「vSphere の管理クラスタ構成」の「ノード IP アドレス管理の構成」を参照してください。
注この手順は、vSphere with Tanzu スーパーバイザーを使用する TKG や、AWS または Azure 上のスタンドアローン管理クラスタを使用する TKG には適用されません。
新規または既存のワークロード クラスタのノード IP アドレス管理を構成する場合は、ユーザーが、IP アドレス管理プロバイダによって割り当てられる固定 IP アドレスの取得元の内部 IP アドレス プールと、ゲートウェイ アドレスを指定します。
クラスタ ノードにアドレスを割り当てると、ノード IP アドレス管理は常にプール内で使用可能な最下位アドレスを選択します。
kubectl
および Tanzu CLIノード IP アドレス管理には、TKG v2.3 で次の制限があります。
ワークロード クラスタのノード IP アドレス管理プールは、そのアドレスが他のクラスタとどのように共有されているかに応じて、2 つの異なるオブジェクト タイプによって定義できます。
InClusterIPPool
は、default
など、同じ管理クラスタ名前空間内のワークロード クラスタでのみ使用できる IP アドレス プールを構成します。
GlobalInClusterIPPool
は、複数の名前空間にまたがるワークロード クラスタに割り当てることができるアドレスを使用して IP アドレス プールを構成します。ノード IP アドレス管理を使用して新規または既存のクラスタを構成するには、次の手順を実行します。
ワークロード クラスタに固定 IP アドレスを割り当てるために TKG が使用できるサブネットからの IP アドレスの範囲を設定する、IP アドレス プール オブジェクト定義ファイル my-ip-pool.yaml
を作成します。IP アドレス プールの範囲を設定する方法に基づいて、オブジェクトを InClusterIPPool
または GlobalInClusterIPPool
として定義します。例:
InClusterIPPool
10.10.10.2-10.10.10.100
の範囲に加えて 10.10.10.102
と 10.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 のドキュメントで説明するように、start
とend
で指定された連続する IP アドレス プール範囲のみをサポートしていました。クラスタを v2.3 にアップグレードすると、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
IP アドレス プール オブジェクトを作成します。
kubectl apply -f my-ip-pool.yaml
「構成ファイル」の説明に従って、フラットなクラスタ構成ファイルまたは 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 アドレスが割り当てられているかどうかを確認するには、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
Ubuntu ベースのノードを使用して、Kube-Vip を使用する vSphere 上の IPv6 のみの単一スタック ネットワーク環境で管理クラスタとワークロード クラスタを実行できます。
注 vSphere with Tanzu スーパーバイザー クラスタを使用して IPv6 クラスタを作成することはできません。Tanzu Mission Control に IPv6 クラスタを登録することはできません。NSX Advanced Load Balancer サービスとデュアル スタック IPv4/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 ワークロード クラスタを展開します。
ワークロード クラスタに対して、以下の構成ファイルの変数を設定します。
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
必要に応じて、管理クラスタの展開またはワークロード クラスタの作成を行います。
クラスタ構成ファイルで、次の手順を実行します。
TKG_IP_FAMILY: ipv4,ipv6
を設定します。注変数ごとに 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 のデュアルスタック機能のエンドツーエンドのテストが失敗することがあります。