追記: 2026年6月7日の最新情報
2026年6月5日に、Broadcom/VMwareはVKS上でArgo CDによるGitOpsワークフローを扱う公式記事を公開しました。これはVKSマルチネットワークの仕様を置き換える情報ではありませんが、secondary NICを使ったネットワーク分離を確認した後に、VKSクラスタ、Add-on Package、vSphere Namespace、VM Service、アプリケーションをどの単位でGit管理するかを考える材料になります。
- マルチネットワーク検証では、secondary NICを追加してもPod通信が自動でeth1へ流れるわけではない点を引き続き先に確認します。
- GitOps化を考える場合は、ネットワーク分離、Namespace、VKSクラスタ定義、アプリケーション配置を同じ責任範囲で混ぜず、リポジトリ、承認、依存順を分けて設計します。
- ArgoCD Service APIでは、ArgoCDリソースがNamespaceスコープのカスタムリソースとして扱われます。導入時はOIDC/RBAC、LoadBalancer公開、対応バージョンも合わせて確認します。
次に進む場合は、マルチネットワークのPoCだけで完結させず、VKSでArgo CD GitOpsを始める前の確認点と、既存VCF環境から9.1へ移る場合のアップグレード順序も合わせて見ると判断しやすくなります。
3行まとめ
このテーマをもう少し広げて見るなら、VKSでArgo CD GitOpsを始める前に確認する：Supervisor Service、App of Apps、互換性の実務ポイント と VCF 5.2.xから9.1へ移行前に確認する：8ステップ順序、VCF Management Services、NSX経路の実務ポイント も合わせて確認してください。マルチネットワーク確認後に、VKSクラスタやNamespaceをGitOpsでどう管理するかを整理できます。
VKSクラスタのノードへsecondary NICを追加し、ネットワーク分離をクラスタ設計の一部として扱えるようになります。
Podの既定通信はeth0に残るため、eth1を何に使うかを用途ごとに決めてから検証します。
secondary network上のLoadBalancer、NetworkPolicy、SecurityPolicy、Windows node poolなどは導入前チェックに落とします。
まずは「NICが増える」ことと「通信経路が自動で分かれる」ことを分けて読むと、PoCの確認点が明確になります。
- Broadcom/VMwareの公式ブログは2026年6月2日、VMware Cloud Foundation 9.1とVMware vSphere Kubernetes Service 3.6で、VKSクラスタのノードに二つ目以降のNICを宣言的に追加できるマルチネットワーク対応を説明しました。
- ただし、eth1を追加してもPodの通信が自動でそちらへ流れるわけではありません。eth0は管理、サービス発見、LoadBalancer、Pod間通信の基盤として残り、eth1は用途を決めて初めて意味を持つ土台です。
- 導入前は、NSX VPCとVDSのどちらを使うか、secondary network上のLoadBalancerやNetworkPolicyが現時点で使えないこと、primary NICを後から変えられないことを先に確認する必要があります。
VMware Cloud Foundation 9.1の公式更新は、2026年6月第1週にかなり密に出ています。直近のBroadcom Watch Japanでも、VCF Automation 9.1のNamespace BlueprintやVCF 9.1のAPI-first自動化を扱いました。今回見るのは、それらとは別の層です。VKSクラスタのノードがどのネットワークへつながり、どの通信を分けられるのかという、Kubernetes運用チームとネットワークチームの接点です。
今回の需要シグナルは、2026年6月2日のVMware Cloud Foundation Blogに「VCF 9.1 Brings Multi-Network Support to VMware vSphere Kubernetes Service」が出たことです。同じ時期にVCF 9.1関連のTag Management、vCenter Linking、FinOps/FOCUS系の記事も並んでおり、VCF 9.1の導入検討が単なるアップグレード確認から、運用設計の具体論へ移っています。この記事ではコミュニティ投稿や専門メディアを事実認定の根拠にはせず、Broadcom/VMwareの一次情報で確認できる範囲に絞ります。
Broadcom Watch JapanはBroadcom Inc.およびVMware by Broadcomとは非提携の独立した情報整理サイトです。この記事は投資助言、契約判断、公式サポート回答ではありません。導入、アップグレード、サポート条件、ライセンス、対応範囲は、必ずBroadcomの公式資料、サポート窓口、自社契約で確認してください。
VCF 9.1とVKS 3.6のマルチネットワーク対応は何を変えるのか
管理、制御、既定のPod通信、Kubernetes API serverへの到達など、クラスタの基本通信を担います。
ストレージ、マルチキャスト、SR-IOVなど、目的を決めた追加用途のためのネットワーク経路になります。
networks変数でネットワークトポロジーを表し、クラスタライフサイクルの一部として管理します。
二次NICの有無、Podの既定経路、Kubernetes API serverの到達範囲を分けて確認します。
secondary NICの追加は土台です。アプリケーション通信の使い分けは、別の設計項目として確認します。
公式ブログの要点は、VCF 9.1とVKS 3.6で、Kubernetesノードに対する宣言的なmulti-NIC対応がVKSのプラットフォーム機能として扱われるようになったことです。記事はシリーズのPart 1と位置づけられており、まず全ノードへsecondary NICをプロビジョニングする土台を説明しています。
ここで大事なのは、機能名だけで「Podごとに自動でネットワークが分かれる」と読まないことです。公式記事も明確に、secondary NICの追加だけではアプリケーション通信は自動で迂回しないと説明しています。Podは既定ではeth0を使い続けます。eth1にはデフォルトルートがなく、ストレージ、マルチキャスト、SR-IOV、Pod単位の追加NICなど、目的ごとの設定を重ねて初めて効果が出ます。
宣言的multi-NIC対応として読む
根拠
従来、多くのKubernetes環境では、Kubernetes API serverへの通信、アプリケーション通信、ストレージI/O、クラスタ管理が一つのインターフェースに集まりがちでした。NetworkPolicyはクラスタ内のLayer 4制御には役立ちますが、ノードNICのレベルで物理的、あるいはインフラ層の境界を作るものではありません。VCF 9.1のVKSマルチネットワーク対応は、この境界をクラスタ仕様の一部として扱う方向へ寄せています。
公式記事では、ネットワークトポロジーをcluster spec内のnetworks変数で表現すると説明しています。つまり、ノードにどのsecondary interfaceを持たせるかをYAMLで宣言し、クラスタのライフサイクル管理に載せる考え方です。これは、手作業でVMへNICを追加する話ではありません。VKSクラスタの作成、更新、ノード更新と同じ運用文脈でネットワーク構成を扱うところに意味があります。
評価基準
導入企業にとっての変化は、Kubernetes運用チームだけで閉じない点です。ネットワーク分離を要求する監査、ストレージ担当が求めるNFS経路、低遅延ワークロード向けのSR-IOV検証、マルチキャスト連携などを、クラスタ定義の段階でネットワークチームとそろえる必要があります。
eth0は基盤、eth1は追加用途の入口
役割分担
公式記事は、primary interfaceであるeth0をクラスタのbackboneとして説明しています。eth0はLoadBalancer traffic、Kubernetes service discovery、pod-to-pod communication、control plane managementを担います。さらに重要なのは、primary networkはクラスタ作成時に決まり、作成後に変更できないことです。管理ネットワークを後から差し替えることは破壊的な操作になりうるため、設計段階の判断になります。
一方、secondary interfaceはeth1からeth9までの任意追加です。公式記事では、secondary interfaceはクラスタ作成後に追加でき、node poolごとに上書きできるとも説明されています。ラック、ストレージ階層、ワークロード種別でネットワークを分けたい場合に、全クラスタ一律ではなく、node pool単位の違いを持たせられる余地があります。
注意点
ただし、ここでも期待値を下げて読む必要があります。eth1を追加しただけでは、アプリケーションが勝手にeth1を使うわけではありません。公式記事のFAQでは、node secondary NICとpod multi-NICの違いも分けられています。node NICはインフラレベルで、同じノード上のPodが共有する物理的な経路です。pod multi-NICは、個別Podに追加インターフェースと個別IPを持たせるさらに上の機能です。
何を確認できればPoCに進めるか
確認項目
PoC前に見るべき最小条件は三つです。まず、SupervisorでVKSマルチネットワーク機能が利用可能になっているか。公式記事はsupports_vks_multi_networks capability flagを確認対象として挙げています。activatedがtrueになるには、VKS 3.6以上が登録され、VDSならsupports_multiple_vds_networks、NSX VPCならKubernetes 1.30以上を伴うsupports_shared_subnets_with_namespaceが有効である必要があります。
次に、クラスタのprimary networkをどこに置くかです。eth0は後から変えられないので、Kubernetes API server、管理通信、既定Pod通信、LoadBalancerを出すネットワークを先に確定させます。
最後に、eth1の用途です。NFSストレージ分離なのか、マルチキャストなのか、SR-IOVなのか、Pod単位のmulti-NICなのかで、見る設定が変わります。用途が曖昧なまま「secondary NICを足しておく」だけでは、将来の切り分けが難しくなります。
まずNSX VPCかVDSかを決める
この比較は優劣ではなく、利用中のネットワーク基盤と指定対象が公式記事の範囲に入るかを見るための整理です。
公式記事が示す対応バックエンドは、NSX Virtual Private CloudとvSphere Distributed Switchです。名前が似ているからといって、既存のNSX構成なら何でも対象になるわけではありません。特に、レガシーなNSX-T T1トポロジーは現時点でサポート対象外と説明されています。
NSX VPCで見るべきポイント
根拠
NSX VPCを使う場合、公式記事はAPI groupとしてcrd.nsx.vmware.com/v1alpha1、object typeとしてSubnetSetとSubnetを示しています。secondary node vNICを支えるSubnetを作り、そのSubnetをcluster specのsecondary interfaceから参照する流れです。
注意点
ここで見落としやすいのは、Subnet側のIP管理です。公式記事では、secondary node vNICを支えるSubnetでDHCPを無効化し、static IP allocationも無効化する必要があると説明しています。理由はIP枯渇です。static allocationが有効なままだと、ノードのスケールアウトやrolling updateのたびにIPが消費され、完全には解放されない可能性があるため、規模が大きい環境では問題になりやすくなります。
確認項目
NSX VPCの場合は、次の順で設計を確認すると事故を減らせます。
| 確認項目 | 見る場所 | 止める条件 |
|---|---|---|
| secondary NIC用Subnet | NSX VPCのSubnet定義 | DHCPやstatic allocationが公式推奨と合わない |
| primary network | cluster specまたは既定SubnetSet | 管理通信の到達範囲が曖昧 |
| secondary networkの用途 | ストレージ、マルチキャスト、SR-IOVなどの要件 | eth1を何に使うか決まっていない |
| SR-IOV VLAN tagging | VDS/NSX VPC差分 | NSX VPCでSR-IOV VLAN taggingを前提にしている |
NSX VPCは、VCF AutomationやNSX側の設計と結びつきます。Namespace、SubnetSet、Subnet、IP範囲、ルーティング、セキュリティ境界を同じ表で管理しておくと、Kubernetes側のcluster specだけを見て判断してしまう危険を下げられます。
VDSで見るべきポイント
根拠
VDSの場合、公式記事はAPI groupとしてnetoperator.vmware.com/v1alpha1、object typeとしてNetworkを示しています。cluster specにはVLAN IDを直接書くのではなく、namespace内の分散ポートグループ名を参照します。VLANやtrunkの設定は、クラスタ作成前にvSphere側のポートグループで整えておく必要があります。
注意点
VDSで特に重要なのは、分散ポートグループ側の三つの設定です。公式記事は、secondary NICを支えるdistributed port groupでtrunk mode、Forged Transmits、MAC Learning Policyを有効にする必要があると説明しています。三つのうち一つでも欠けると、ノード自体は正常に見えても、後からPodのsecondary NICを作った時に通信できないという厄介な失敗になり得ます。
また、VDSではprimary network customizationがサポートされず、eth0はdefault namespace Networkを使います。primary networkを細かく制御したい読者にとっては、NSX VPCとVDSの違いが導入判断に直結します。
| バックエンド | 参照する主な対象 | 向いている確認 | 注意点 |
|---|---|---|---|
| NSX VPC | SubnetSet、Subnet | NSX VPCでのセグメント分離、管理ネットワーク、Subnet設計 | レガシーNSX-T T1は対象外。SR-IOV VLAN taggingはNSX VPCの場合は未対応 |
| VDS | Network、分散ポートグループ | VLAN、trunk、既存vSphereネットワークとの連携 | primary network customizationは未対応。ポートグループ設定不足が後から通信不具合になる |
「NSXならよい」と読まない
評価基準
既存環境にNSXがある場合でも、この記事の対象はNSX VPCです。公式記事が「NSX-T T1のレガシートポロジーは現在サポートされない」と明記しているため、既存のNSX-T設計をそのままVKS 3.6のmulti-networkへ持ち込めるとは限りません。
導入前レビューでは、ネットワーク担当に「NSXはあるか」ではなく「VKSが参照できるNSX VPCとして設計されているか」を確認してください。ここを曖昧にすると、cluster specを書けても、実際のSubnet、Firewall、外部到達性、運用責任が噛み合いません。
eth0とeth1をどう分けるか
- 1管理と制御
Kubernetes API serverへの到達、control plane management、service discoveryはeth0側の生命線として扱います。
- 2既定のPod通信
Podは既定ではeth0を使います。アプリケーション通信をeth1へ流すには、Pod側の利用設定を別に確認します。
- 3ストレージ経路
NFSなど目的が明確な通信は、eth1に割り当てるsubnet、DNS、到達性、障害時の切り分けを確認します。
- 4マルチキャストとVLAN
VLAN extension subnetやホスト側構成が必要になるため、ネットワーク基盤側の前提と合わせて検証します。
- 5MTUとジャンボフレーム
クラスタだけで決めず、物理ネットワーク、VDS、NSX側の経路まで同じ前提で確認します。
eth1を足す前に、管理通信、既定通信、追加用途、MTUを別々の確認項目にしておくと切り分けしやすくなります。
VKSマルチネットワーク対応を運用設計に落とす時は、eth0とeth1を機能名で分けるより、通信の責任で分ける方が実務的です。eth0はクラスタが成立するための基盤です。eth1は、特定用途のために追加するインフラ経路です。
eth0はクラスタの生命線として扱う
根拠
eth0には、Kubernetes API serverへの到達、control plane management、Kubernetes service discovery、pod-to-pod communication、LoadBalancer trafficが残ります。公式記事では、Kubernetes API serverはeth0のsubnetでlistenし、eth1だけにつながる環境からは物理的に到達できないというトポロジー上の価値も説明されています。
注意点
この性質は、セキュリティの観点では強い材料です。NetworkPolicyが誤設定されても、管理ネットワークが別subnetに閉じていれば、eth1側からAPI serverへ届かない設計にできます。一方で、アプリケーションや運用ツールがAPI serverへどの経路でアクセスするかを把握していない環境では、単純な分離が障害になります。
確認項目
eth0については、少なくとも次を記録しておきます。
| 項目 | 記録する内容 | 理由 |
|---|---|---|
| primary network | SubnetSet、default Network、IP範囲 | 作成後に変更できないため |
| Kubernetes API到達 | 管理端末、CI/CD、監視基盤の到達経路 | eth1側から届かない設計を理解するため |
| LoadBalancer | どのnetworkに出るか | secondary networkにはLoadBalancerを出せないため |
| 既定Pod通信 | Podが既定で使う経路 | eth1追加後も自動では変わらないため |
eth1は「用途」を決めてから足す
条件
eth1にはデフォルトルートがありません。公式記事の表現を実務に置き換えると、eth1は「使える状態にしておく線」ではなく、「用途が決まった時に初めて意味を持つ線」です。
例えばNFSストレージ分離なら、ノードがeth1経由でストレージネットワークへ到達できること、必要なら静的ルートを設計すること、MTUを揃えること、ストレージ側の許可範囲を明確にすることが必要になります。公式記事は、NFS Storage IsolationをシリーズのPart 2として予告しており、Part 1だけで完成手順を断定するべきではありません。
評価基準
pod-level multi-NICを使う場合は、node secondary NICとは別に、Antrea、AntreaIPAM、NetworkAttachmentDefinitionなどの話になります。公式FAQでも、node NICはインフラレベル、pod multi-NICはPodへ専用インターフェースとIPを持たせる上位の使い方として分けています。
MTUとジャンボフレームはクラスタだけで決めない
注意点
公式記事のサンプルでは、secondary interfaceのMTUを1500にし、NFSやストレージ系ワークロードでは9000を検討する文脈が示されています。ここで注意したいのは、MTUはVKSクラスタだけで完結しないことです。
MTU 9000を選ぶなら、VDSまたはNSX側、物理スイッチ、ストレージ、経路上のファイアウォールやルータまで含めて整合を取る必要があります。Kubernetes側のYAMLだけを変えても、途中の装置が対応していなければ、性能劣化や断続的な通信失敗につながります。
確認項目
PoCでは、eth1が見えることだけで終わらせず、次のように分けて確認します。
| 観点 | 最初に確認すること |
|---|---|
| インターフェース | 全ノードにeth1が付き、想定subnetのIPが付いている |
| 経路 | eth1に意図しないdefault routeがない |
| 到達性 | 目的のNFS、VLAN、外部セグメントだけに届く |
| MTU | 物理、仮想、ストレージ側で値が揃っている |
| 障害切り分け | eth0の管理通信とeth1の用途通信を別々に観測できる |
未対応範囲を導入前チェックに落とす
制限事項は勝敗ではなく条件です。代替策で進める範囲と、公式情報を待つ範囲を分けて残します。
今回のVKSマルチネットワーク対応は重要な前進ですが、公式記事は未対応範囲もはっきり挙げています。ここを読み飛ばすと、PoCは通っても、本番設計で止まります。
secondary networkにLoadBalancerを出せない
根拠
現時点では、Service type LoadBalancerはprimary networkにプロビジョニングされます。特定のsecondary subnetへLoadBalancer IPを出したい設計は、公式記事の範囲ではできません。
注意点
これは、IngressやAPI公開経路をsecondary networkへ寄せたい場合に大きな制約です。storage trafficをeth1へ分ける話と、外部公開のLoadBalancerをsecondary subnetへ出す話は別物です。後者を要件にしているなら、VKSマルチネットワーク対応だけでは要件を満たせない可能性があります。
NetworkPolicyとSecurityPolicyの適用範囲に注意する
根拠
公式記事は、Antrea network policiesがsecondary NICにはまだ適用されないと説明しています。つまり、eth1以降の通信はKubernetes policy layerでは未フィルタになる可能性があります。
評価基準
ここはセキュリティレビューで必ず聞かれる点です。ネットワーク分離があるから安全、とだけ言うのでは足りません。secondary network上の通信をどの層で制御するのか、NSX側、物理ネットワーク側、ホスト側、アプリケーション側の責任境界を決める必要があります。
特に規制業種や社内監査の強い環境では、Kubernetes NetworkPolicyを証跡として使っている場合があります。その証跡がsecondary NICには効かないなら、代替のログ、Firewall rule、監査対象を用意しなければなりません。
primary NIC、secondary NIC、Windows node poolの制約
条件
公式記事の未対応リストには、primary NICが永続的で変更できないこと、secondary interfaceは追加のみで削除できないこと、Windows worker nodesがこのリリースではsecondary NICを使えないことも含まれています。
secondary interfaceは既存クラスタに追加できます。公式FAQでは、networks.interfaces.secondaryリストを更新すると、VKSがrolling node updateで反映し、クラスタ全体のダウンタイムなしに適用できると説明しています。ただし、一度追加したinterfaceは削除できません。設定更新はできても、完全に外すにはクラスタの破棄と再作成が必要になります。
導入判断
SR-IOV VLAN taggingも注意点です。公式記事は、SR-IOV with VLAN taggingがVDSのみであり、NSX VPCの場合はまだサポートされないと説明しています。低遅延や高スループットが主目的なら、バックエンド選定の段階でVDS前提かどうかを確認してください。
| 要件 | 現時点の扱い | 導入判断 |
|---|---|---|
| secondary network上のLoadBalancer | 未対応 | 外部公開要件があるなら設計見直し |
| secondary NICへのNetworkPolicy/SecurityPolicy | 未対応 | 別レイヤーの制御と監査を用意 |
| primary network変更 | 作成後変更不可 | クラスタ作成前に確定 |
| secondary interface削除 | 追加後は削除不可 | PoCでも本番に近い設計で試す |
| SR-IOV VLAN tagging | VDSのみ | NSX VPC前提なら要件再確認 |
| Windows node pool | secondary NIC未対応 | Windows混在クラスタでは使い分けが必要 |
ユースケース別に小さく試す
eth1にストレージ系subnetを割り当て、ノードからNFSサーバーへ到達できるかを確認します。
VLAN extension subnet、VDS、ホスト側構成をそろえ、どの通信を分離したいかを先に決めます。
性能要件、物理NIC、ホスト構成、VLAN tagging、Pod側の利用モデルを分けて確認します。
ノードにsecondary NICがあることと、Podが複数NICを使うことを別の検証段階として扱います。
PoCの失敗理由を切り分けるため、最初はNFSのように目的と到達先がはっきりした経路から試すのが現実的です。
公式記事は、今回をPart 1として、後続でNFS Storage Isolation、Pod-Level Multi-NIC with Antrea、Multicast with VLAN Extension Subnets、SR-IOV on VKSを扱うと予告しています。つまり、今すぐ読むべきは「すべての手順が出そろった」という意味ではなく、「node-levelのsecondary NICという土台ができた」という意味です。
NFSストレージ分離から試す場合
条件
最初のPoCに向いているのは、NFSのように目的がはっきりしたストレージ経路の分離です。eth1にストレージ系subnetを割り当て、ノードからNFSサーバーへ到達できるかを確認します。
ただし、NFSが自動でeth1を使うわけではありません。公式記事も、remote subnetへ到達させるには静的ルートなどの設定が必要になる例を挙げ、詳細はPart 2で扱うとしています。この記事の段階では、次の準備項目までを切り出すのが現実的です。
確認項目
| 確認項目 | 見る内容 |
|---|---|
| eth1のIP | 想定したstorage subnetから付与されているか |
| NFSサーバー到達性 | eth1側から到達させる設計になっているか |
| ルート | default routeではなく用途別経路として扱えているか |
| MTU | ストレージ側、ネットワーク側と一致しているか |
| 障害時の復旧 | eth0の管理通信とeth1のストレージ通信を別々に切り分けられるか |
マルチキャストやVLAN連携を見る場合
注意点
マルチキャストやVLAN extensionは、よりネットワークチーム寄りの検証になります。公式記事のシリーズでは、Multicast with VLAN Extension Subnetsが後続テーマとして示されています。ここをPart 1だけで手順化してしまうと、過剰な断定になります。
検討する場合は、VKSクラスタ内だけでなく、外部VLAN、物理ネットワーク、NSX Edgeを経由するかどうか、どの責任範囲でパケットを観測するかを先に決めます。マルチキャストはアプリ側の要件、ネットワーク側の許可、監視側の可視性がずれると、問題の切り分けに時間がかかります。
SR-IOVを検討する場合
評価基準
SR-IOVは、通信性能や低遅延が目的の環境で検討するテーマです。公式記事では、SR-IOV on VKSをPart 5として予告し、SR-IOV VLAN taggingはVDSのみとしています。telco、HPC、高性能データ処理のような用途でなければ、最初からSR-IOVをPoCの中心に置く必要はありません。
確認項目
SR-IOVを検討するなら、VDS、物理NIC、ホスト構成、VLAN tagging、Pod側の利用モデルをまとめて確認します。BroadcomのAIネットワーキングやNVIDIA ConnectX/BlueFieldに関するVCF 9.1の発表文脈と、VKS上のSR-IOV VLAN taggingは近い領域に見えますが、この記事では混ぜません。ここで確認するのは、VKS 3.6のsecondary NICとVDS前提の制約です。
既存のVCF 9.1運用記事とつなげて確認する
primary network、secondary network、Subnet、MTU、到達性をクラスタ作成前の設計項目として確認します。
network topologyがcluster specに入るため、API-first運用、SDK、PowerCLI、仕様管理と合わせて確認します。
VCF 9.1のOAuth 2.0認証や自動化の導線と合わせ、クラスタ操作の権限管理を確認します。
Real-Time Metricsや診断系の更新と合わせ、二つの経路の状態をどこで見分けるかを決めます。
公式発表と同時期の製品更新を追い、未対応範囲や後続シリーズの更新を確認します。
関連記事は回遊先ではなく、導入前に次に確認する作業を選ぶための導線として使います。
VKSマルチネットワーク対応は、単独のニュースとして読むより、VCF 9.1の運用更新の中に置く方が判断しやすくなります。ネットワークをYAMLで宣言するならAPI-first運用が関係します。クラスタやNamespaceの再利用を考えるなら、Namespace Blueprintとの違いも見ておく必要があります。APIやPowerCLIで触るなら、認証方式の確認も避けられません。
YAMLとAPI管理の導線
根拠
VKSのnetwork topologyはcluster specの一部として扱われます。したがって、VCF 9.1のAPI-first自動化を導入前に確認する記事で扱った、SDK、PowerCLI、API specification、Real-Time Metricsのような運用基盤ともつながります。
一方、VCF Automation 9.1のNamespace Blueprintは、実行中のNamespaceを再利用可能な定義にする話です。VKSマルチネットワーク対応は、クラスタのネットワークトポロジーを設計する話です。どちらも「宣言的」に見えますが、対象とリスクは違います。
認証と運用監視の導線
確認項目
VCF 9.1のAPIやPowerCLIを使ってクラスタ仕様を確認する場合、先に認証方式を整理しておくと作業が安定します。VCF PowerCLI 9.1のOAuth 2.0認証では、APIトークンとVCF SSO連携の確認点を扱っています。
導入後の観測では、VCF OperationsやDiagnosticsも関係します。secondary network上の通信は、Kubernetes policy layerだけでは見えない部分が出るため、ネットワーク、vSphere、VCF Operations、アプリログを分けて見る体制が必要です。旧vSphere/NSX環境でDiagnosticsを使う場合は、VCF Operations 9.1 Diagnosticsを旧vSphere/NSX環境で使う前にも合わせて確認してください。
月次Hubで同時期の公式更新を追う
注意点
2026年6月のVCF 9.1関連更新は、個別記事だけを追うと見落としやすくなります。VKS、Tag Management、vCenter Linking、FOCUS/FinOps、PowerCLI、Namespace Blueprintなどが近い時期に出ているため、2026年6月 重要トピックまとめを月次の入口にすると、どの更新が同じリリース文脈にあるかを把握しやすくなります。
導入前チェックリスト
この表の目的は導入を止めることではなく、PoCの失敗理由を機能差、設計不足、前提不足に分けることです。
最後に、VKSマルチネットワーク対応を試す前の確認項目を一枚にまとめます。ここでの目的は、試すこと自体を止めることではありません。PoCの失敗理由が「機能が悪い」のか、「前提を満たしていない」のかを分けることです。
クラスタ作成前に決めること
確認項目
クラスタ作成前に決めるべきことは、primary network、バックエンド、secondary networkの用途です。特にprimary networkは後から変更できません。PoCだからといって仮のsubnetで始めると、本番移行時にクラスタ再作成が必要になります。
| 確認項目 | OKの目安 | 止める条件 |
|---|---|---|
| VKS 3.6以上 | Supervisorでmulti-network capabilityが有効 | capability flagが有効にならない |
| バックエンド | NSX VPCまたはVDSのどちらかを明確化 | レガシーNSX-T T1前提 |
| primary network | 管理、API、LoadBalancerの責任範囲が明確 | 後から変えるつもりで作る |
| secondary network | NFS、マルチキャスト、SR-IOVなど用途が明確 | 何に使うか決まっていない |
| セキュリティ制御 | secondary networkの制御レイヤーを定義 | NetworkPolicyだけで守る前提 |
| Windows node pool | secondary NICを使わない設計 | Windows workerでsecondary NICを前提にする |
PoCで確認すること
評価基準
PoCでは、公式記事に沿ってノード上でeth0とeth1を確認します。kubectl get nodesでnode名を確認し、node debugやvSphere ClientでインターフェースとIPを見ます。公式記事は、VKS namespacesが既定でrestricted Pod Security Standardを使うため、node debugではprivilegedで動くkube-systemを対象にする例も示しています。
ただし、本番記事としては、コマンドの暗記よりも確認観点を残す方が大切です。全ノードにeth1が付いているか。eth0とeth1が別subnetか。eth1にdefault routeがないか。目的の通信だけをeth1へ流す設計になっているか。ここまで見て初めて、secondary NICが「付いた」だけでなく「使える設計になった」と言えます。
本番前に残す運用メモ
確認項目
本番前には、少なくとも次のメモを残してください。
- primary networkを選んだ理由と、変更できないことへの承認。
- NSX VPCまたはVDSを選んだ理由。
- secondary interfaceの名前、subnet、MTU、用途。
- VDSの場合はtrunk mode、Forged Transmits、MAC Learningを確認した記録。
- LoadBalancer、NetworkPolicy/SecurityPolicy、SR-IOV、Windows node poolの未対応範囲。
- secondary interfaceを追加後に削除できないことへの運用判断。
- 後続の公式シリーズ記事が出た時に更新する確認箇所。
VCF 9.1は、Broadcomの公式発表でも、AI、コンテナ、VMを同じ基盤で動かす方向性が強調されています。VKSのマルチネットワーク対応は、その中でKubernetes運用をよりインフラ設計に近づける機能です。便利なチェックボックスではなく、クラスタ作成前のネットワーク設計として扱うことで、導入後の切り分けと監査がかなり楽になります。
まとめ：VKSマルチネットワーク対応は「二つ目のNIC」より設計境界が重要
secondary NICを宣言的に追加し、ネットワーク分離をVKSのクラスタ設計に入れられるようになります。
Podの既定通信、管理、制御、LoadBalancerなど、クラスタの基本通信はeth0側の前提で確認します。
NFS、マルチキャスト、SR-IOVなど、目的を一つずつ選び、subnet、MTU、到達性を小さく検証します。
secondary network上のLoadBalancer、NetworkPolicy、SecurityPolicy、Windows node poolの扱いを導入判断に残します。
「二つ目のNICがある」だけでなく、どの通信を分け、どの範囲をまだ使わないかを決めることが本番設計の要点です。
今回の公式更新は、VKSクラスタのノードにsecondary NICを宣言的に追加できるようにし、VKSのネットワーク分離をプラットフォーム機能として扱う第一歩です。eth1からeth9までのsecondary interface、NSX VPCとVDSの対応、cluster spec内のnetworks変数、node poolごとの上書きは、Kubernetes運用チームにとってかなり大きな材料になります。
一方で、実務の判断は「NICが増えた」だけでは済みません。Podの既定通信はeth0に残ります。secondary network上のLoadBalancerは現時点で使えません。NetworkPolicyやSecurityPolicyはsecondary NICへまだ適用されません。primary NICは変更できず、secondary interfaceは追加後に削除できません。VDSの場合はポートグループ設定、NSX VPCの場合はSubnetとIP管理が導入前の落とし穴になります。
今すぐ試すなら、まずは目的を一つに絞るのがよいです。NFSストレージ分離、マルチキャスト、SR-IOV、Pod単位のmulti-NICを同時に試すと、どこで詰まったか分からなくなります。最初のPoCでは、eth0とeth1の役割、Subnet、MTU、到達性、未対応範囲を小さく確認し、後続の公式シリーズ記事が出たら運用メモを更新する進め方が現実的です。
次に読むなら
参照した主な情報源
- VMware Cloud Foundation Blog「VCF 9.1 Brings Multi-Network Support to VMware vSphere Kubernetes Service」（2026年6月2日公開、2026年6月4日参照）
https://blogs.vmware.com/cloud-foundation/2026/06/02/vcf-9-1-brings-multi-network-support-to-vsphere-kubernetes-service/
- VMware Cloud Foundation Blog「Deploy Modern Apps Faster, Scale Smarter, and Lower Your TCO with VMware vSphere Kubernetes Service in VCF 9.1」（2026年5月5日公開、2026年6月4日参照）
https://blogs.vmware.com/cloud-foundation/2026/05/05/deploy-modern-apps-faster-scale-smarter-and-lower-your-tco-with-vks-on-vcf-9-1/
- VMware Cloud Foundation Blog「VMware vSphere Kubernetes Service 3.6: Making Enterprise Kubernetes Safer, More Flexible, and Easier to Operate」（2026年2月11日公開、2026年6月4日参照）
https://blogs.vmware.com/cloud-foundation/2026/02/11/vmware-vsphere-kubernetes-service3-6-making-enterprise-kubernetes-safer-more-flexible-and-easier-to-operate/
- Broadcom News「Broadcom Announces VMware Cloud Foundation 9.1, Enabling Secure and Cost-Effective Infrastructure for Production AI」（2026年5月5日公開、2026年6月4日参照）
https://news.broadcom.com/emea/releases/broadcom-announces-vmware-cloud-foundation-9-1