vSphere の管理クラスタ構成

クラスタ構成ファイルを作成するには、以前の展開の既存の構成ファイルを vSphere にコピーして更新します。また、空のテンプレートを使用してファイルを最初から作成することもできます。

管理クラスタ構成テンプレート

次に示すテンプレートには、vSphere への管理クラスタの展開に関連するすべてのオプションが含まれています。このテンプレートをコピーして使用し、管理クラスタを vSphere に展開できます。

すべてのターゲットプラットフォームに共通の設定を更新する方法については、「管理クラスタ構成ファイルの作成」を参照してください。
すべての構成ファイル変数の詳細については、「構成ファイル変数リファレンス」を参照してください。
vSphere 設定の構成方法の例については、テンプレートの下にあるセクションを参照してください。

必須オプションはコメント解除されています。オプションの設定はコメントアウトされています。必要に応じて、デフォルト値が含まれています。

#! ---------------------------------------------------------------------
#! Basic cluster creation configuration
#! ---------------------------------------------------------------------

CLUSTER_NAME:
CLUSTER_PLAN: dev
INFRASTRUCTURE_PROVIDER: vsphere
# CLUSTER_API_SERVER_PORT: # For deployments without NSX Advanced Load Balancer
ENABLE_CEIP_PARTICIPATION: true
ENABLE_AUDIT_LOGGING: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13
# CAPBK_BOOTSTRAP_TOKEN_TTL: 30m

#! ---------------------------------------------------------------------
#! vSphere configuration
#! ---------------------------------------------------------------------

VSPHERE_SERVER:
VSPHERE_USERNAME:
VSPHERE_PASSWORD:
VSPHERE_DATACENTER:
VSPHERE_RESOURCE_POOL:
VSPHERE_DATASTORE:
VSPHERE_FOLDER:
VSPHERE_NETWORK: VM Network
# VSPHERE_CONTROL_PLANE_ENDPOINT: # Required for Kube-Vip
# VSPHERE_CONTROL_PLANE_ENDPOINT_PORT: 6443
VIP_NETWORK_INTERFACE: "eth0"
# VSPHERE_TEMPLATE:
VSPHERE_SSH_AUTHORIZED_KEY:
# VSPHERE_STORAGE_POLICY_ID: ""
VSPHERE_TLS_THUMBPRINT:
VSPHERE_INSECURE: false
DEPLOY_TKG_ON_VSPHERE7: false
ENABLE_TKGS_ON_VSPHERE7: false

#! ---------------------------------------------------------------------
#! Node configuration
#! ---------------------------------------------------------------------

# SIZE:
# CONTROLPLANE_SIZE:
# WORKER_SIZE:
# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""
# VSPHERE_NUM_CPUS: 2
# VSPHERE_DISK_GIB: 40
# VSPHERE_MEM_MIB: 4096
# VSPHERE_MTU:
# VSPHERE_CONTROL_PLANE_NUM_CPUS: 2
# VSPHERE_CONTROL_PLANE_DISK_GIB: 40
# VSPHERE_CONTROL_PLANE_MEM_MIB: 8192
# VSPHERE_WORKER_NUM_CPUS: 2
# VSPHERE_WORKER_DISK_GIB: 40
# VSPHERE_WORKER_MEM_MIB: 4096

#! ---------------------------------------------------------------------
#! VMware NSX specific configuration for enabling NSX routable pods
#! ---------------------------------------------------------------------

# NSXT_POD_ROUTING_ENABLED: false
# NSXT_ROUTER_PATH: ""
# NSXT_USERNAME: ""
# NSXT_PASSWORD: ""
# NSXT_MANAGER_HOST: ""
# NSXT_ALLOW_UNVERIFIED_SSL: false
# NSXT_REMOTE_AUTH: false
# NSXT_VMC_ACCESS_TOKEN: ""
# NSXT_VMC_AUTH_HOST: ""
# NSXT_CLIENT_CERT_KEY_DATA: ""
# NSXT_CLIENT_CERT_DATA: ""
# NSXT_ROOT_CA_DATA: ""
# NSXT_SECRET_NAME: "cloud-provider-vsphere-nsxt-credentials"
# NSXT_SECRET_NAMESPACE: "kube-system"

#! ---------------------------------------------------------------------
#! NSX Advanced Load Balancer configuration
#! ---------------------------------------------------------------------

AVI_ENABLE: false
AVI_CONTROL_PLANE_HA_PROVIDER: false
# AVI_NAMESPACE: "tkg-system-networking"
# AVI_DISABLE_INGRESS_CLASS: true
# AVI_AKO_IMAGE_PULL_POLICY: IfNotPresent
# AVI_ADMIN_CREDENTIAL_NAME: avi-controller-credentials
# AVI_CA_NAME: avi-controller-ca
# AVI_CONTROLLER:
# AVI_USERNAME: ""
# AVI_PASSWORD: ""
# AVI_CLOUD_NAME:
# AVI_SERVICE_ENGINE_GROUP:
# AVI_NSXT_T1LR: # Required for NSX ALB deployments on NSX Cloud.
# AVI_MANAGEMENT_CLUSTER_SERVICE_ENGINE_GROUP:
# AVI_DATA_NETWORK:
# AVI_DATA_NETWORK_CIDR:
# AVI_MANAGEMENT_CLUSTER_VIP_NETWORK_NAME:
# AVI_MANAGEMENT_CLUSTER_VIP_NETWORK_CIDR:
# AVI_CA_DATA_B64: ""
# AVI_LABELS: ""
# AVI_DISABLE_STATIC_ROUTE_SYNC: true
# AVI_INGRESS_DEFAULT_INGRESS_CONTROLLER: false
# AVI_INGRESS_SHARD_VS_SIZE: ""
# AVI_INGRESS_SERVICE_TYPE: ""
# AVI_INGRESS_NODE_NETWORK_LIST: ""

#! ---------------------------------------------------------------------
#! Image repository configuration
#! ---------------------------------------------------------------------

# TKG_CUSTOM_IMAGE_REPOSITORY: ""
# TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: ""

#! ---------------------------------------------------------------------
#! Proxy configuration
#! ---------------------------------------------------------------------

# TKG_HTTP_PROXY: ""
# TKG_HTTPS_PROXY: ""
# TKG_NO_PROXY: ""

#! ---------------------------------------------------------------------
#! Machine Health Check configuration
#! ---------------------------------------------------------------------

ENABLE_MHC:
ENABLE_MHC_CONTROL_PLANE: true
ENABLE_MHC_WORKER_NODE: true
MHC_UNKNOWN_STATUS_TIMEOUT: 5m
MHC_FALSE_STATUS_TIMEOUT: 12m

#! ---------------------------------------------------------------------
#! Identity management configuration
#! ---------------------------------------------------------------------

IDENTITY_MANAGEMENT_TYPE: "none"

#! Settings for IDENTITY_MANAGEMENT_TYPE: "oidc"
# CERT_DURATION: 2160h
# CERT_RENEW_BEFORE: 360h
# OIDC_IDENTITY_PROVIDER_CLIENT_ID:
# OIDC_IDENTITY_PROVIDER_CLIENT_SECRET:
# OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM: groups
# OIDC_IDENTITY_PROVIDER_ISSUER_URL:
# OIDC_IDENTITY_PROVIDER_SCOPES: "email,profile,groups,offline_access"
# OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: email

#! The following two variables are used to configure Pinniped JWTAuthenticator for workload clusters
# SUPERVISOR_ISSUER_URL:
# SUPERVISOR_ISSUER_CA_BUNDLE_DATA:

#! Settings for IDENTITY_MANAGEMENT_TYPE: "ldap"
# LDAP_BIND_DN:
# LDAP_BIND_PASSWORD:
# LDAP_HOST:
# LDAP_USER_SEARCH_BASE_DN:
# LDAP_USER_SEARCH_FILTER:
# LDAP_USER_SEARCH_ID_ATTRIBUTE: dn
# LDAP_USER_SEARCH_NAME_ATTRIBUTE:
# LDAP_GROUP_SEARCH_BASE_DN:
# LDAP_GROUP_SEARCH_FILTER:
# LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: dn
# LDAP_GROUP_SEARCH_USER_ATTRIBUTE: dn
# LDAP_ROOT_CA_DATA_B64:

#! ---------------------------------------------------------------------
#! Antrea CNI configuration
#! ---------------------------------------------------------------------

# ANTREA_NO_SNAT: true
# ANTREA_NODEPORTLOCAL: true
# ANTREA_NODEPORTLOCAL_ENABLED: true
# ANTREA_NODEPORTLOCAL_PORTRANGE: 61000-62000
# ANTREA_TRAFFIC_ENCAP_MODE: "encap"
# ANTREA_PROXY: true
# ANTREA_PROXY_ALL: true
# ANTREA_PROXY_LOAD_BALANCER_IPS: false
# ANTREA_PROXY_NODEPORT_ADDRS:
# ANTREA_PROXY_SKIP_SERVICES: ""
# ANTREA_POLICY: true
# ANTREA_TRACEFLOW: true
# ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD: false
# ANTREA_ENABLE_USAGE_REPORTING: false
# ANTREA_EGRESS: true
# ANTREA_EGRESS_EXCEPT_CIDRS: ""
# ANTREA_FLOWEXPORTER: false
# ANTREA_FLOWEXPORTER_COLLECTOR_ADDRESS: "flow-aggregator.flow-aggregator.svc:4739:tls"
# ANTREA_FLOWEXPORTER_POLL_INTERVAL: "5s"
# ANTREA_FLOWEXPORTER_ACTIVE_TIMEOUT: "5s"
# ANTREA_FLOWEXPORTER_IDLE_TIMEOUT: "15s"
# ANTREA_IPAM: false
# ANTREA_KUBE_APISERVER_OVERRIDE: ""
# ANTREA_MULTICAST: false
# ANTREA_MULTICAST_INTERFACES: ""
# ANTREA_NETWORKPOLICY_STATS: true
# ANTREA_SERVICE_EXTERNALIP: true
# ANTREA_TRANSPORT_INTERFACE: ""
# ANTREA_TRANSPORT_INTERFACE_CIDRS: ""

一般的な vSphere 構成

Tanzu Kubernetes Grid が vSphere にログインできるように情報を指定し、Tanzu Kubernetes Grid が使用できるリソースを指定します。

VSPHERE_SERVER、VSPHERE_USERNAME、および VSPHERE_PASSWORD の設定を、vCenter Server インスタンスの IP アドレスまたは FQDN、およびログインに使用する認証情報で更新します。
管理クラスタを展開する vSphere データセンター、リソースプール、データストア、およびフォルダへのフルパスを指定します。
- VSPHERE_DATACENTER: /<MY-DATACENTER>
- VSPHERE_RESOURCE_POOL: /<MY-DATACENTER>/host/<CLUSTER>/Resources
- VSPHERE_DATASTORE: /<MY-DATACENTER>/datastore/<MY-DATASTORE>
- VSPHERE_FOLDER: /<MY-DATACENTER>/vm/<FOLDER>.
クラスタの制御プレーン API の HA プロバイダに応じて、VSPHERE_CONTROL_PLANE_ENDPOINT を設定するか、空白のままにします。
- Kube-VIP：固定仮想 IP アドレスに設定するか、仮想 IP アドレスアドレスにマッピングされた完全修飾ドメイン名 (FQDN) に設定します。
- NSX Advanced Load Balancer：エンドポイントを指定する必要がない限り、空白のままにします。その場合は、固定 IP アドレスプールに手動で追加した IP アドレス管理プロファイルの仮想 IP アドレスネットワーク範囲内の固定アドレスを使用するか、固定アドレスにマッピングされた FQDN を使用します。
VSPHERE_NETWORK および VIP_NETWORK_INTERFACE でネットワークとネットワークインターフェイスを指定します。
オプションで、同じ Kubernetes バージョンに複数のカスタム OVA イメージを使用している場合は、VSPHERE_TEMPLATE のコメントを解除して更新し、OVA ファイルへのパスを指定します。/MY-DC/vm/MY-FOLDER-PATH/MY-IMAGE の形式を使用します。詳細については、『Tanzu CLI を使用した TKG 2.4 ワークロードクラスタの作成と管理』の「カスタム OVA イメージを使用したクラスタの展開」を参照してください。
VSPHERE_SSH_AUTHORIZED_KEY オプションに SSH キーを指定します。SSH キーを取得する方法については、「vSphere への管理クラスタの展開の準備」を参照してください。
VSPHERE_TLS_THUMBPRINT 変数に TLS サムプリントを指定するか、VSPHERE_INSECURE: true を設定してサムプリントの検証をスキップします。
必要に応じて、VSPHERE_STORAGE_POLICY_ID をコメント解除し、管理クラスタで使用するために vCenter Server で構成した仮想マシンのストレージポリシーの名前を指定します。

例：

#! ---------------------------------------------------------------------
#! vSphere configuration
#! ---------------------------------------------------------------------

VSPHERE_SERVER: 10.185.12.154
VSPHERE_USERNAME: [email protected]
VSPHERE_PASSWORD: <encoded:QWRtaW4hMjM=>
VSPHERE_DATACENTER: /dc0
VSPHERE_RESOURCE_POOL: /dc0/host/cluster0/Resources/tanzu
VSPHERE_DATASTORE: /dc0/datastore/sharedVmfs-1
VSPHERE_FOLDER: /dc0/vm/tanzu
VSPHERE_NETWORK: "VM Network"
VSPHERE_CONTROL_PLANE_ENDPOINT: 10.185.11.134
VIP_NETWORK_INTERFACE: "eth0"
VSPHERE_TEMPLATE: /dc0/vm/tanzu/my-image.ova
VSPHERE_SSH_AUTHORIZED_KEY: ssh-rsa AAAAB3[...]tyaw== [email protected]
VSPHERE_TLS_THUMBPRINT: 47:F5:83:8E:5D:36:[...]:72:5A:89:7D:29:E5:DA
VSPHERE_INSECURE: false
VSPHERE_STORAGE_POLICY_ID: "My storage policy"

ノードサイズの構成

Tanzu CLI は、構成ファイルで指定した設定に従って、管理クラスタとワークロードクラスタの個々のノードを作成します。vSphere では、すべてのノード仮想マシンに同じ事前定義済み構成を適用することも、制御プレーンノードとワーカーノードにそれぞれ異なる事前定義済み構成を設定することも、ノードの構成をカスタマイズすることもできます。これらの設定を使用すると、管理クラスタノードにそれぞれ異なる構成のノードを持つクラスタを作成できます。また、制御プレーンノードとワーカーノードの構成が異なるクラスタを作成することもできます。

事前定義されたノードサイズ

Tanzu CLI は、クラスタノードに対して次の事前定義された構成を提供します。

small：2 個の CPU、4 GB のメモリ、20 GB のディスク
medium：2 個の CPU、8 GB のメモリ、40 GB のディスク
large：4 個の CPU、16 GB のメモリ、40 GB のディスク
extra-large：8 個の CPU、32 GB のメモリ、80 GB のディスク

すべての制御プレーンとワーカーノードの仮想マシンのサイズが同じクラスタを作成するには、SIZE 変数を指定します。SIZE 変数を設定すると、設定した構成を使用してすべてのノードが作成されます。

SIZE: "large"

制御プレーンとワーカーノードの仮想マシンのサイズが異なるクラスタを作成するには、CONTROLPLANE_SIZE および WORKER_SIZE オプションを指定します。

CONTROLPLANE_SIZE: "medium"
WORKER_SIZE: "extra-large"

CONTROLPLANE_SIZE オプションと WORKER_SIZE オプションを SIZE オプションと組み合わせることができます。たとえば、SIZE: "large" と WORKER_SIZE: "extra-large" を指定すると、制御プレーンノードは large に設定され、ワーカーノードは extra-large に設定されます。

SIZE: "large"
WORKER_SIZE: "extra-large"

カスタムノードサイズ

事前定義済みの構成を使用するのではなく、ノードの構成をカスタマイズできます。

すべてのノードに同じカスタム構成を使用するには、VSPHERE_NUM_CPUS、VSPHERE_DISK_GIB、および VSPHERE_MEM_MIB オプションを指定します。

VSPHERE_NUM_CPUS: 2
VSPHERE_DISK_GIB: 40
VSPHERE_MEM_MIB: 4096

制御プレーンノードとワーカーノードに異なるカスタム構成を定義するには、VSPHERE_CONTROL_PLANE_* オプションと VSPHERE_WORKER_* オプションを指定します。

VSPHERE_CONTROL_PLANE_NUM_CPUS: 2
VSPHERE_CONTROL_PLANE_DISK_GIB: 20
VSPHERE_CONTROL_PLANE_MEM_MIB: 8192
VSPHERE_WORKER_NUM_CPUS: 4
VSPHERE_WORKER_DISK_GIB: 40
VSPHERE_WORKER_MEM_MIB: 4096

これらの設定は、SIZE、CONTROLPLANE_SIZE、および WORKER_SIZE オプションを使用してオーバーライドできます。

NSX Advanced Load Balancer の構成

NSX Advanced Load Balancer を使用するには、まず vSphere 環境に展開する必要があります。NSX Advanced Load Balancer のインストールに関する説明を参照してください。NSX Advanced Load Balancer を展開したら、ロードバランサを使用するように vSphere 管理クラスタを構成します。

例：

AVI_ENABLE: true
AVI_CONTROL_PLANE_HA_PROVIDER: true
AVI_NAMESPACE: "tkg-system-networking"
AVI_DISABLE_INGRESS_CLASS: true
AVI_AKO_IMAGE_PULL_POLICY: IfNotPresent
AVI_ADMIN_CREDENTIAL_NAME: avi-controller-credentials
AVI_CA_NAME: avi-controller-ca
AVI_CONTROLLER: 10.185.10.217
AVI_USERNAME: "admin"
AVI_PASSWORD: "<password>"
AVI_CLOUD_NAME: "Default-Cloud"
AVI_SERVICE_ENGINE_GROUP: "Default-Group"
AVI_NSXT_T1LR:""
AVI_DATA_NETWORK: nsx-alb-dvswitch
AVI_DATA_NETWORK_CIDR: 10.185.0.0/20
AVI_MANAGEMENT_CLUSTER_VIP_NETWORK_NAME: ""
AVI_MANAGEMENT_CLUSTER_VIP_NETWORK_CIDR: ""
AVI_CA_DATA_B64: LS0tLS1CRU[...]UtLS0tLQo=
AVI_LABELS: ""
AVI_DISABLE_STATIC_ROUTE_SYNC: true
AVI_INGRESS_DEFAULT_INGRESS_CONTROLLER: false
AVI_INGRESS_SHARD_VS_SIZE: ""
AVI_INGRESS_SERVICE_TYPE: ""
AVI_INGRESS_NODE_NETWORK_LIST: ""

デフォルトでは、管理クラスタとそれが管理するすべてのワークロードクラスタが、ロードバランサを使用します。NSX Advanced Load Balancer の変数の構成方法については、「構成ファイル変数リファレンス」の「NSX Advanced Load Balancer」を参照してください。

制御プレーンエンドポイントプロバイダとしての NSX Advanced Load Balancer

NSX ALB は、Tanzu Kubernetes Grid の制御プレーンエンドポイントプロバイダとして使用できます。次の表では、NSX ALB と Tanzu Kubernetes Grid のデフォルトの制御プレーンエンドポイントプロバイダである Kube-Vip の違いについて説明します。

	Kube-Vip	NSX ALB
トラフィックの送信先	単一の制御プレーンノード	複数の制御プレーンノード
エンドポイント仮想 IP アドレスの構成が必要	はい	いいえ NSX ALB 固定 IP アドレスプールから仮想 IP アドレスを割り当て

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

vSphere 環境で NSX を使用している場合は、ルーティング可能な (NO_NAT) ポッドを実装するように構成できます。

注
NSX ルーティング可能なポッドは、このリリースの試験的な機能です。NSX ルーティング可能なポッドを実装する方法については、近日中にこのドキュメントに追加される予定です。

#! ---------------------------------------------------------------------
#! NSX specific configuration for enabling NSX routable pods
#! ---------------------------------------------------------------------

# NSXT_POD_ROUTING_ENABLED: false
# NSXT_ROUTER_PATH: ""
# NSXT_USERNAME: ""
# NSXT_PASSWORD: ""
# NSXT_MANAGER_HOST: ""
# NSXT_ALLOW_UNVERIFIED_SSL: false
# NSXT_REMOTE_AUTH: false
# NSXT_VMC_ACCESS_TOKEN: ""
# NSXT_VMC_AUTH_HOST: ""
# NSXT_CLIENT_CERT_KEY_DATA: ""
# NSXT_CLIENT_CERT_DATA: ""
# NSXT_ROOT_CA_DATA: ""
# NSXT_SECRET_NAME: "cloud-provider-vsphere-nsxt-credentials"
# NSXT_SECRET_NAMESPACE: "kube-system"

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 になります。

複数のアベイラビリティゾーンの構成

「複数のアベイラビリティゾーンにまたがるクラスタの実行」の説明に従って、複数のアベイラビリティゾーン (AZ) のノードで実行される管理クラスタまたはワークロードクラスタを構成できます

前提条件

「vSphere でのリージョンおよび AZ の準備」の説明に従って、作成およびタグ付けされた AZ 用の vSphere オブジェクト。
「Kubernetes での FailureDomain および Deployment Zone オブジェクトの作成」の説明に従って作成された、AZ 用の Kubernetes オブジェクト

複数の AZ にまたがって展開されたノードを使用してクラスタを構成するには、次の手順を実行します。

VSPHERE_REGION および VSPHERE_ZONE をリージョンとゾーンのタグカテゴリ（k8s-region および k8s-zone）に設定します。
マシンを展開する必要がある VsphereDeploymentZone オブジェクトの名前を使用して、VSPHERE_AZ_0、VSPHERE_AZ_1、VSPHERE_AZ_2 を設定します。
- VSPHERE_AZ_0 に関連付けられた VsphereDeploymentZone は、md-0 で終わるマシン展開が展開される VSphereFailureDomain です。同様に、VSPHERE_AZ_1 は、md-1 で終わるマシン展開が展開される VSphereFailureDomain、VSPHERE_AZ_2 は、md-2 で終わるマシン展開が展開される VSphereFailureDomain です。
- AZ 構成のいずれかが定義されていない場合、そのマシン展開は VSphereFailureDomain なしで展開されます。
WORKER_MACHINE_COUNT は、クラスタのワーカーの合計数を設定します。ワーカーの合計数は、指定された AZ の数に対してラウンドロビン方式で分散されます。
VSPHERE_AZ_CONTROL_PLANE_MATCHING_LABELS は、クラスタノードが展開できる AZ のキー/値セレクタラベルを設定します。これにより、たとえば、リージョンおよび環境のすべての AZ を個別に一覧表示することなく指定できます。"region=us-west-1,environment=staging"。
SKIP_MULTI_AZ_VERIFY を true に設定すると、参照されるすべての vSphere ゾーンとリージョンが存在し、一貫して指定され、同じレベルにあることのチェックがスキップされます。

クラスタを vSphere に展開するときに指定する必要があるオプションの完全なリストについては、「構成ファイル変数リファレンス」を参照してください。

ノード IP アドレス管理の構成

TKG は、vSphere 上のスタンドアローン管理クラスタと、それらが管理するクラスベースのワークロードクラスタに対するクラスタ内ノード IP アドレス管理をサポートします。詳細と現在の制限については、『Tanzu CLI を使用した TKG 2.4 ワークロードクラスタの作成と管理』の「ノード IP アドレス管理」を参照してください。

ノード IP アドレス管理を使用して管理クラスタをインストーラインターフェイスから直接展開することはできません。構成ファイルから展開する必要があります。ただし、インストーラインターフェイスを実行し、[構成の確認 (Review Configuration)] > [構成のエクスポート (Export Configuration)] をクリックし、以下で説明するように生成された構成ファイルを編集することで、構成ファイルを作成できます。

クラスタ内 IP アドレス管理をノードに使用する管理クラスタを展開するには、次の手順を実行します。

前提条件として、クラスタの制御プレーンノードとワーカーノードに使用するネームサーバの IP アドレスを収集します。これは、クラスタノードが DHCP を介してネームサーバを受信して vCenter Server で名前を解決しなくなったため、必須となります。
管理クラスタ構成ファイルを編集し、「構成ファイル変数リファレンス」の「ノード IP アドレス管理」の表の説明に従って、次のような設定を含めます。
```
MANAGEMENT_NODE_IPAM_IP_POOL_GATEWAY: "10.10.10.1"
MANAGEMENT_NODE_IPAM_IP_POOL_ADDRESSES: "10.10.10.2-10.10.10.100,10.10.10.105"
MANAGEMENT_NODE_IPAM_IP_POOL_SUBNET_PREFIX: "24"
CONTROL_PLANE_NODE_NAMESERVERS: "10.10.10.10,10.10.10.11"
WORKER_NODE_NAMESERVERS: "10.10.10.10,10.10.10.11"
```
ここで、CONTROL_PLANE_NODE_NAMESERVERS と WORKER_NODE_NAMESERVERS は、使用するネームサーバのアドレスです。単一のネームサーバまたは 2 つのカンマ区切りのネームサーバのいずれかを指定できます。冗長性が必要な環境では、複数のネームサーバが必要になる場合があります。この場合、ノード仮想マシンは一度に 1 つのネームサーバのみを使用し、最初のネームサーバが解決に失敗した場合は 2 番目のネームサーバが使用されます。また、複数のネームサーバを指定して、制御プレーンノードとワーカーノードのネームサーバをそれぞれ個別に変更して、異なるタイプのノードでサービス解決を制御することもできます。

クラスタノード MTU の構成

vSphere 標準スイッチ上の管理クラスタとワークロードクラスタの最大転送ユニット (MTU) を構成するには、VSPHERE_MTU 変数を設定します。VSPHERE_MTU の設定は、管理クラスタとワークロードクラスタの両方に適用されます。

指定しない場合、デフォルトの vSphere ノード MTU は 1500 です。最大値は 9000 です。MTU の詳細については、vSphere 8 のドキュメントの「vSphere ネットワークについて」を参照してください。

vSphere with Tanzu 上の管理クラスタ

vSphere 7 および vSphere 8 の場合、vSphere with Tanzu は、管理クラスタとして機能する組み込みのスーパーバイザーを提供し、スタンドアローン管理クラスタよりも優れたエクスペリエンスを提供します。スーパーバイザーが存在しない場合の Tanzu Kubernetes Grid 管理クラスタの vSphere 7 または vSphere 8 への展開はサポートされていますが、推奨されるのは、可能であれば vSphere with Tanzu を有効にしてスーパーバイザーを使用することです。Azure VMware Solution はスーパーバイザークラスタをサポートしていないため、管理クラスタを展開する必要があります。詳細については、「vSphere with Tanzu スーパーバイザーが管理クラスタである」を参照してください。

vSphere with Tanzu が有効になっている場合、インストーラインターフェイスには、Kubernetes ワークロードを実行するための優先方法として TKG サービスを使用できることが示されます。この場合、スタンドアローン管理クラスタは必要ありません。次の選択肢が表示されます。

[vSphere with Tanzu の構成 (Configure vSphere with Tanzu)] を選択すると、vSphere Client が開き、スーパーバイザーを構成できます。これについては、vSphere 8 ドキュメントの「スーパーバイザーの構成と管理」で説明されています。
[TKG 管理クラスタの展開 (Deploy TKG Management Cluster)] を選択すると、vSphere 7 または vSphere 8 に対して、および（必要に応じて）Azure VMware Solution に対してスタンドアローン管理クラスタの展開を続行できます。

次の手順

管理クラスタ構成ファイルの更新が完了したら、「構成ファイルからの管理クラスタの展開」の手順に従って管理クラスタを作成します。