3行まとめ
このテーマをもう少し広げて見るなら、VCF 9.1 Private AI Servicesを導入前に確認する：NSX/VDS、Supervisor、VCF Automationの実務ポイント と VCF 9.1でIaCを始める前に確認する：SDDC Manager API、Terraform、組織/プロジェクトの実務ポイント も合わせて確認してください。VKSのSupervisor、NSX/VDS、ロードバランサ設計をAIワークロード側のSupervisor構成とつなげて確認できるため。
vSphere Zone、ESXホスト、ストレージ、ネットワーク、障害境界を、クラスタ作成前に確認します。
VDSとNSX-VPC、Antrea、Foundation Load Balancer、Avi Load Balancerを、運用境界で切り分けます。
KubernetesのHAだけでなく、vSAN File Services、外部ストレージ、バックアップ、アプリケーション復旧を別の層として見ます。
クラスタのYAMLへ進む前に、配置、IP、ロードバランサ、ストレージ、復旧の未決事項を洗い出すと設計レビューが進めやすくなります。
VKS on VCF 9.1を設計する前に、まず3つのvSphere Zoneへ置けるか、Supervisorとworkload clusterの配置を混同していないかを確認したい。
ネットワークは、VDSとNSX-VPCのどちらを採るか、Antreaを既定CNIとして運用するか、Foundation Load BalancerとAvi Load Balancerをどこで切り分けるかが判断点になる。
PVC、RWX、DRはKubernetesのHAだけでは閉じない。vSAN File Services、外部ストレージ、Velero、アプリケーションやDB側の復旧設計を分けて見る必要がある。
VKS on VCF 9.1は「3ゾーンで置けるか」から確認する
ゾーンごとのホスト、電源、ネットワーク、ストレージの分離を確認し、同じ障害に巻き込まれない構成にします。
各ゾーンでESXホスト数、vSAN、HAの前提を確認し、標準構成と既存環境の差分を把握します。
VCF管理面の配置、ストレッチクラスタ、障害時の管理経路を、Workload Domainとは分けて確認します。
VKS workload clusterを置くドメインで、ゾーン分散、ネットワーク到達性、ストレージポリシーをそろえます。
3ゾーン構成は、3つのラベルを作る作業ではありません。ゾーンごとの障害境界と運用責任を先に見ます。
VMware Cloud Foundation Blogは2026年6月9日、VKS on VCFに関するWebinarと現場Q&Aをまとめた記事を公開した。新機能の単純な発表というより、設計前に聞かれやすい質問へ答える内容で、VKSをVCF 9.1の上で使う読者には実務的な需要シグナルになっている。
この記事で最初に見るべきなのは、Kubernetesクラスタを作るYAMLではなく、vSphere Zoneをどう置くかだ。公式ブログは、vSANとHAを支えるESXホストクラスタの標準的な最小要件として3ホストを挙げ、VCFにおけるAvailability Zoneは独立した物理障害ドメインを表す論理構成だと説明している。つまり、3ゾーン構成を検討するなら、単に「3つの名前を作る」のではなく、ゾーンごとのホスト、ストレージ、ネットワーク、障害境界を先に確認する。
3-Zone Deployment Modelが設計の出発点になる理由
公式ブログは、VCF 9.xでストレッチクラスタがManagement DomainとWorkload Domainの両方でサポートされるとしつつ、VCF 9.1ではKubernetes HAの現代的な標準として3-Zone Deployment Modelを強く推す、と説明している。ここは「ストレッチクラスタは使ってはいけない」という話ではない。設計レビューでは、既存の2サイト構成で本当に十分か、3つの障害ドメインを作れるか、ワークロードの復旧目標がどちらのモデルに合うかを分けて確認する。
確認項目
- 各ゾーンに最低限必要なESXホストを置けるか。
- vSAN、HA、DRS、共有ストレージ、ネットワークの前提がゾーン単位でそろうか。
- 物理障害ドメインが、ラック、部屋、データセンター、電源、ToRスイッチのどこで分かれているか。
- Management DomainとWorkload DomainのどちらにVKSを置くのか。
- 1つのゾーン障害時に、control planeとworker nodeの復旧順を説明できるか。
3ゾーンを採る場合、読者が最初に作るべきものは完成構成図ではなく、未決の表でよい。ホスト数が足りない、ストレージが伸ばせない、ネットワーク担当がゾーンごとのVIP範囲を持っていない。そうした空欄が見えれば、まだクラスタ作成に進むタイミングではない。
ストレッチクラスタ前提で見落としやすいこと
既存の2サイト構成をそのまま使いたい組織ほど、3ゾーン推奨を「新規構築向けの理想論」として読み飛ばしやすい。だが、VKSの設計では、Kubernetes node poolをどの障害ドメインへ散らすか、ストレージとIPがどこまで伸びているか、障害時にどの層が自動復旧するかが効いてくる。
注意点
ストレッチクラスタは、インフラ層では便利でも、アプリケーションやDBが同じ前提で復旧するとは限らない。split-brain、低遅延要件、DNS切替、VIPの生存範囲、PVCの整合性を別々に確認する必要がある。3ゾーンを採らない場合でも、「なぜ採らないのか」を設計書に残す価値はある。
SupervisorとWorkload Clusterの配置を混同しない
ESXは共通基盤ですが、Supervisorとworkload clusterは責務が違います。どの層の問題かを分けると切り分けが速くなります。
VKS on VCFの設計でありがちな混乱は、vSphere Supervisor、VKS workload cluster、Kubernetes control plane、worker nodeを同じ言葉の束として扱ってしまうことだ。公式ブログは、VKSではvSphere Supervisor control planeもworkload clusterのcontrol planeやworker nodeも、最終的にはESX上のVMとして動くと説明している。違うのは、管理主体、責務、配置の決め方である。
TechDocsでも、VKSはvSphere Supervisorと統合され、vCenter、ESX、仮想ネットワーク、クラウドネイティブストレージと連携する自己サービス型のKubernetes workload clusterライフサイクル管理として説明されている。これは、VKSを「外部Kubernetesサービス」としてではなく、VCFの基盤上に載る宣言的なクラスタ運用面として見る、という意味だ。
ESXは共通基盤、役割は別物として見る
vSphere Supervisor control plane VMは、Supervisorが有効化されたvSphereクラスタに配置され、vCenterとVCFの管理下に入る。workload clusterを作ると、そのKubernetes control plane nodeとworker nodeもESX上にプロビジョニングされる。DRSやHA、配置ルール、ゾーン分散の影響を受けるため、Kubernetes設計者だけで閉じる話ではない。
根拠
公式ブログのQ&Aは、worker nodeがESXホスト上にある場合、Supervisor control plane VMとworkload cluster control plane VMもどこにあるのか、という質問に答えている。答えは、どちらもESX基盤上にある。ただし、Supervisorはプラットフォーム側の制御面で、workload clusterはテナントやアプリケーション側のKubernetesクラスタである。
Node poolをゾーン分散の単位として見る
VCF 9.1では、node poolをvSphere Zoneへ分散できると公式ブログは説明している。これは、Kubernetesの可用性を「クラスタ全体」だけで考えるのではなく、node pool、VM class、storageClass、ゾーン容量を合わせて見る必要があるということだ。
確認項目
| 項目 | 設計前に確認すること |
|---|---|
| control plane | 何台構成で、どのゾーンへ置くか |
| worker node pool | アプリ種別ごとに分けるか、ゾーンへ散らすか |
| VM class | CPU、メモリ、GPUなどの制約がゾーンごとに同じか |
| storageClass | 使えるストレージポリシーがゾーン間で一致するか |
| メンテナンス | 1ゾーン停止時に退避先容量が残るか |
ここを曖昧にしたままGitOpsへ進むと、YAMLはきれいでも実際の配置が狙いどおりにならない。VKS上のArgo CDやApp of Appsを検討する段階では、先にこの配置単位を固めておきたい。GitOps側の詳細は、既存のVKSでArgo CD GitOpsを始める前に確認する記事へ回すと読みやすい。
IPブロックは「同じ親サブネットでも非重複」で管理する
- 1親サブネット
最初に大きなIP範囲を台帳で管理し、誰が変更できるか、どこまで予約済みかを明確にします。
- 2Supervisor External IP Block
Supervisorやクラスタ接続に使う範囲として切り出し、他の用途と重ならないようにします。
- 3Organization IP Space
VCF Automationの組織向け範囲として管理し、テナントやセルフサービスの境界と合わせます。
- 4LB/VPC/将来拡張
VIP、VPC用サブブロック、将来拡張用の余白を別枠で残し、NATやDNSの管理と合わせます。
重要なのは、同じ親サブネットを使えるかではなく、Supervisor、Automation、VPC、VIPの実割り当てを重複させないことです。
公式ブログのQ&Aで実務的に重要なのが、vSphere SupervisorのExternal IP Blockと、VCF AutomationのOrganization IP SpaceまたはExternal IP Blockの関係だ。回答では、必ずしも完全に別のルーティングネットワークである必要はなく、同じ大きな親サブネットから切り出すことはできる、と説明されている。一方で、実際に各利用者へ割り当てる範囲は重複させない、という線引きがある。
これは地味だが、VKS導入時の障害原因になりやすい。Supervisor、workload cluster、Service type LoadBalancer、Ingress、VCF Automation、VPC、NAT、DNSが同じIP計画の中に入ってくるからだ。
External IP BlockとOrg IP Spaceを分けて考える
同じ親サブネットを使えるという説明を、「誰でも同じ範囲を使ってよい」と読んではいけない。実務では、親サブネットを台帳で管理し、Supervisor用、Automation organization用、VPC用、LB用、将来拡張用へ切り分ける。
注意点
- IPAMの管理主体が、vCenter、VCF Automation、NSX、外部IPAMのどれか。
- Supervisor External IP BlockとVKS Service/Ingress用のVIP範囲が重ならないか。
- Organization IP SpaceやVPCのNAT範囲が、既存の業務ネットワークと衝突しないか。
- DNS登録、証明書、監視、ファイアウォール申請で同じVIPを二重に使っていないか。
VKS導入前に作るIP台帳
IP台帳は、設計書の付録ではなく、クラスタ作成前のゲートにしたい。VKSではネットワーク選択とロードバランサ選択がIP計画に直結するため、後から直すほど影響が大きい。
評価基準
| 領域 | 台帳に入れる項目 | 未決なら止める理由 |
|---|---|---|
| Supervisor | External IP Block、管理ネットワーク | control planeやAPI接続が不安定になる |
| Workload cluster | Service、Ingress、frontend network | 開発者の接続経路が決まらない |
| VCF Automation | Organization IP Space、外部IP範囲 | セルフサービス払い出しと衝突する |
| NSX-VPC | subnet、NAT、TGW接続 | テナント分離や経路制御が曖昧になる |
| LB | Foundation LB、Avi、NSX LBのVIP | 証明書、DNS、監視の責任が分かれない |
VPCやTransit Gatewayの範囲設計まで進む読者は、既存のVCF 9.1のVPC Network Span確認記事も合わせて見ると、クラスタ境界とネットワーク境界を分けて考えやすい。
VPC/VDSとAntreaは、対応可否より運用境界で決める
VDSとNSX-VPCは単純な優劣ではありません。誰が払い出し、誰が監視し、誰が障害対応するかで選び方が変わります。
VKSのネットワーク設計では、「VPCが使えるか」「VDSが使えるか」という対応可否だけでなく、誰が払い出し、誰が見て、誰が障害対応するかを先に決める。公式ブログは、VPCはパブリッククラウドに近い構成概念で、テナント分離、セルフサービス、ルーティング、NAT、サブネットを開発者向けに扱いやすくすると説明している。
一方で、VCF 9.1以降のVKSでは、設計対象としてVDS networkingとNSX-VPCが中心になる、という記述がある。過去バージョンや既存環境のNSX Classic構成を背景として理解することは大切だが、新規の設計レビューではVCF 9.1の前提に寄せて整理したい。
VDSとNSX-VPCの分岐
TechDocsの参照アーキテクチャでは、VDS topologyはSupervisor control plane VM用のmanagement network、VKS cluster用のworkload network、開発者が接続するfrontend networkを分けて説明している。NSX networkingの構成では、Tier-1 gateway、segment、load balancer server、VKS control plane向けvirtual server、Kubernetes service load balancer向けvirtual serverが登場する。
条件
| 選択肢 | 向く判断 | 先に確認すること |
|---|---|---|
| VDS | 既存VLAN設計を活かし、比較的シンプルに始めたい | 外部LB、frontend network、IP払い出し |
| NSX-VPC | テナント分離、セルフサービス、NAT、VPC単位の境界を重視する | VPC範囲、TGW、NAT、運用権限 |
| 既存NSX Classic | 既存環境の継続や移行中の制約がある | 対象VCFバージョンとサポート範囲 |
既存のVKSマルチネットワーク記事では、二つ目のNIC、NSX VPC、VDSの具体的な確認点を扱っている。この記事では、その手前の設計判断として、ネットワーク方式をどう選ぶかに絞る。
Antrea既定をどう扱うか
公式ブログは、VKS clustersの既定CNIとしてAntreaを挙げ、VCF 9.1ではAntrea-NSX Adapterを通じたNSX stackとの統合に触れている。CalicoやCiliumのような別CNIについては、CNCF-conformantであることやVKS 3.6以降のbring your own CNIに触れつつ、Antreaがもっとも自然に可視性へつながる、という読み方ができる。
注意点
別CNIを入れられることと、企業運用として選んでよいことは同じではない。サポート境界、NSXとの可視性、NetworkPolicyの調査、アップグレード時の責任、障害時の切り分けを確認する必要がある。既存Kubernetes運用と統一したい事情が強いなら、BYO CNIを評価する意味はある。ただし、VCF上の標準運用に寄せるなら、まずAntreaを軸に評価した方が話が早い。
ロードバランサはL4/L7と運用機能で切り分ける
L4だけで足りるか、L7やWAFまで必要か、運用ログをどこで見るかによって選択肢が変わります。
ロードバランサは、VKS導入前に最も誤解されやすい領域の一つだ。公式ブログは、Foundation Load BalancerをVDS networking向けの既定のLayer 4ロードバランサとして説明し、より単純な環境やPoC用途での利用に触れている。一方、Layer 7、WAF、DNS連携、Avi Kubernetes Operatorを含むIngress連携が必要な重いワークロードでは、Avi Load Balancerを推奨する流れになる。
Foundation Load Balancerをどこまで使うか
Foundation Load Balancerは、VDS構成でVKSを始めるときの入口として分かりやすい。Service type LoadBalancerの払い出し、開発者の接続確認、PoCでの基本検証には向く。ただし、これを「本番でも常に十分」と読んではいけない。
確認項目
- L4だけで足りるアプリケーションか。
- Ingress Controller、証明書、DNS、WAFをどこで扱うか。
- VIPをどのIPブロックから払い出すか。
- 監視ログと障害調査の起点がどこにあるか。
- 将来Aviへ移る場合の名前解決、証明書、アプリ側影響を説明できるか。
Avi、NSX LB、in-guest LBの使い分け
公式ブログは、Avi Load BalancerをLayer 7、WAF、DNS統合、AKOによるIngress Controller連携が必要な場面で推奨している。NSX Load BalancerはVCF構成でLayer 4ロードバランサとして扱われる。kube-vipやMetalLBのようなin-guestの選択肢も使えるが、VCFファブリック側の集中分析、自動化、IPAMの利点を失う面がある。
評価基準
| 候補 | まず見る用途 | 注意点 |
|---|---|---|
| Foundation Load Balancer | VDS構成のL4、簡易用途、PoC | L7、WAF、DNS統合が必要なら不足する |
| Avi Load Balancer | L7、Ingress、WAF、DNS、AKO | 設計と運用の責任範囲を広めに見る |
| NSX Load Balancer | NSX構成内のL4 | アプリ要件がL7へ寄るなら再評価する |
| kube-vip、MetalLB | ゲスト側で完結したい特殊事情 | VCF側のIPAM、可視化、自動化から外れやすい |
選定の順番は、好きな製品名から入らないことだ。アプリが必要とするレイヤー、証明書、DNS、Ingress、監視、障害対応者を先に書き、その後にLBを選ぶ。
PVCとDRはKubernetesだけで完結させない
- 1RWO/RWX要件
アプリケーションが本当にRWXを必要とするか、RWOや外部DB、オブジェクトストレージで足りるかを先に確認します。
- 2ストレージポリシー
vSAN、vSAN File Services、外部NFS、Portworxなど、既存ストレージとサポート範囲を見ます。
- 3バックアップ
Velero、Supervisorバックアップ、アプリケーション側バックアップを分け、復旧対象と保管先を決めます。
- 4DR設計
ストレージ層、アプリケーション層、DB層の復旧順を確認し、3ゾーン構成だけに期待しない設計にします。
Kubernetesの可用性、PVの永続化、アプリケーションデータの復旧は別の話です。復旧テストの単位も分けて考えます。
3ゾーン構成にすると、読者はつい「Kubernetesがうまく分散してくれる」と考えがちだ。だが、ストレージとDRは別の層である。公式ブログは、statelessまたはnon-persistentなストレージは標準的なvSANやブロックストレージポリシーで扱われ、VCF 9.1ではvSphere Namespaceレベルでstorage quotaを扱うと説明している。
さらに、ReadWriteManyをネイティブに使うにはvSAN File Servicesが必要とされる。一方、vSANを使わない環境ではPortworxのようなCNCF-conformantなサードパーティストレージオーバーレイをVKS clusters内に入れる選択肢も説明されている。ここは「どれが正解か」ではなく、既存ストレージ、RWX要件、サポート、運用負荷を見て分岐させるところだ。
RWXとストレージポリシーを先に確認する
アプリケーションが本当にRWXを必要としているのか、RWOで足りるのか、オブジェクトストレージや外部DBへ逃がせるのかを先に決める。Kubernetesマニフェストの前に、データのライフサイクルを確認する。
条件
- vSAN File Servicesを使えるなら、ネイティブRWXの候補に入る。
- 既存ブロックストレージ中心なら、RWO前提の設計を確認する。
- 外部NFSやPortworxを使うなら、誰が運用し、誰が障害を切り分けるかを決める。
- Namespace quota、storage policy、reclaim policyをアプリチームと共有する。
3ゾーンDRはアプリケーション層の設計も見る
公式ブログは、標準的なblock PVC、つまりReadWriteOnceのPVCを3ゾーン間で同期レプリケーションする前提にしないよう示唆している。3ゾーンでの高可用性は、主にアプリケーションやDB側のレプリケーション、場合によってはvSAN Data Persistence Platformのような仕組みと合わせて考える。
注意点
Veleroはworkload cluster内のKubernetes workloadバックアップで使われるが、Supervisorそのもののバックアップとは分けて考える、という説明も公式ブログにある。Supervisorはインフラ側、workload clusterはアプリケーション側という境界を崩すと、復旧手順が曖昧になる。
PVCを削除したときのreclaim policy、CSIによるVMDKやvolumeの削除、復旧時にどの名前で戻すかも事前に確認したい。障害はきれいな単体故障ではなく、IP、DNS、LB、PVC、DBが同時に絡むことがある。
宣言的クラスタ管理へ進む前に変数を棚卸しする
クラスタ全体の形、ゾーン、バージョン、アップグレード方針を、設計書の変数として整理します。
worker nodeの数、VM class、ゾーン分散、スケール方針を、アプリケーション要件と合わせます。
namespace、PVC、quota、RWO/RWXの前提を変数として扱える粒度に分けます。
VDS、NSX-VPC、IPブロック、VIP、Antrea、Ingressの前提をクラスタ作成前にそろえます。
GitOpsやNamespace Blueprintへ進む前に、変数へ入れる内容と、運用チームが管理する境界をそろえておきます。
Broadcom Developer PortalのVKS APIドキュメントは、VKSがVCF Private Cloud内でKubernetes clustersを宣言的に作成、設定、管理するAPIであると説明している。Cluster APIを使い、cluster topology、node pools、VM classes、storage policies、networking settingsを定義し、provisioning、scaling、upgrading、cluster health managementを自動化する、という位置づけだ。
これは、設計レビューにおいて非常に大切なポイントになる。VKSでは、クラスタ作成を手作業の一回限りの作業としてではなく、変数と宣言的な構成として扱える。だからこそ、変数へ何を入れるかを、ネットワーク、ストレージ、運用担当と一緒に決めておく必要がある。
Cluster API変数は設計書の材料になる
Cluster Configuration Variablesのドキュメントは多い。本文で全項目を列挙する必要はない。設計前に棚卸しするなら、まずカテゴリで見る。
確認項目
| 変数カテゴリ | 設計レビューで見ること |
|---|---|
| topology | どのクラスタ形にするか |
| node pool | 役割、数、ゾーン分散、スケール単位 |
| VM class | CPU、メモリ、GPU、ゾーンごとの在庫 |
| storageClass | RWO/RWX、ポリシー、quota |
| networks | VDS、NSX-VPC、VIP、pod/service範囲 |
| labels/taints | ワークロードの配置制約 |
| upgrade strategy | 手動、計画停止、検証クラスタの扱い |
GitOpsやNamespace Blueprintへ進む前の境界
VKSを宣言的に扱えると、すぐGitOpsやセルフサービス化へ進みたくなる。だが、Argo CD、Namespace Blueprint、App Stack Formationは、設計の次の段階だ。VKSクラスタのゾーン、ネットワーク、ストレージ、LBが決まっていない状態でアプリ配信を自動化すると、後戻りが大きくなる。
VCF AutomationのNamespace BlueprintやAPI-first運用に広げる場合は、既存のVCF Automation 9.1 Namespace Blueprint確認記事や、VCF 9.1 API-first自動化の記事を後段で読むとよい。この記事の役割は、その前にVKSの土台を固めることにある。
設計レビュー用チェックリスト
未決なら、インフラ、ネットワーク、IPAM、Kubernetes運用、アプリ、セキュリティの誰に確認するかまで書き出します。
VKS on VCF 9.1の設計レビューでは、次の10項目を最初に確認したい。これは推奨構成の押し付けではなく、未決事項を見つけるための表である。
最初に確認する10項目
| 領域 | 確認すること | 未決なら誰に聞くか |
|---|---|---|
| 3ゾーン | 3つの物理障害ドメインを作れるか | インフラ設計、データセンター運用 |
| ホスト数 | ゾーンごとのESX、vSAN、HA前提 | vSphere、サーバー担当 |
| Supervisor | control plane VMの配置と管理境界 | VCF管理者 |
| node pool | worker nodeのゾーン分散とVM class | Kubernetes基盤担当 |
| IPレンジ | External IP、Org IP Space、VIPの非重複 | ネットワーク、IPAM担当 |
| ネットワーク方式 | VDSかNSX-VPCか | ネットワーク、VCF Automation担当 |
| CNI | Antrea標準か、BYO CNIか | Kubernetes運用、セキュリティ担当 |
| LB | Foundation LB、Avi、NSX LB、in-guestの分岐 | アプリ、ネットワーク、セキュリティ担当 |
| PVC | RWO/RWX、storageClass、quota | ストレージ、DB担当 |
| DR | Velero、Supervisor backup、DB復旧順 | 運用、DR、アプリ担当 |
進めてよいケース
3ゾーンまたは採用しない理由が説明でき、VKSの配置、IP、ネットワーク、CNI、LB、PVC、DRの未決事項が担当者つきで整理されているなら、PoCやクラスタ作成へ進みやすい。VCF 9.1を触って確認したい場合は、VCF 9.1 Hands-on LabsをPoC前に使う記事が次の入口になる。
先に止めるケース
IPレンジが重複している、Foundation Load BalancerとAviの役割が決まっていない、RWX要件だけが先に出ていてストレージ方式が未定、3ゾーンとストレッチクラスタのどちらを採るかを誰も説明できない。こうした状態なら、クラスタ作成より設計レビューを先に戻した方がよい。
次に読むなら
参照した主な情報源
- VMware Cloud Foundation Blog, "Architecting VMware vSphere Kubernetes Service on VCF: Top Webinar and Field Questions Answered", 2026年6月9日公開、2026年6月11日確認
https://blogs.vmware.com/cloud-foundation/2026/06/09/architecting-vmware-vsphere-kubernetes-service-on-vcf-top-webinar-and-field-questions-answered/
- Broadcom TechDocs, "VKS Components", 2026年6月11日確認
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-service-administration-and-development/9-0/managing-vsphere-kubernetes-service/running-tkg-service-clusters/tkg-service-components.html
- Broadcom TechDocs, "Reference Architectures for VKS Clusters", 2026年6月11日確認
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-service-administration-and-development/9-0/managing-vsphere-kubernetes-service/running-tkg-service-clusters/reference-architectures-for-tkg-service-clusters.html
- Broadcom Developer Portal, "VMware vSphere Kubernetes Service", 2026年6月11日確認
https://developer.broadcom.com/xapis/vmware-vsphere-kubernetes-service/latest
- Broadcom Developer Portal, "Cluster Configuration Variables", 2026年6月11日確認
https://developer.broadcom.com/xapis/vmware-vsphere-kubernetes-service/latest/variable-docs.html