はじめまして。VMware の伊藤です。Tanzu 製品のプラットフォームアーキテクトとして働いており、開発と運用双方の経験があります。今回は「触りながら学ぶ vSphere with Tanzu」シリーズの第四回として vSphere with Tanzu のネットワーク構成について学びます。利用者視点ではネットワーク構成を把握しなくてもKubernetesを使えますが、運用者視点では構築や維持のために理解が必要です。
第三回までで ハンズオンラボ「HOL-2113-01-SDC – vSphere with Tanzu」の演習は完了しています。第一回でユーザーとして Tanzu の Kubernetes（K8s） のクラスタである 「Tanzu Kubernetes Cluster（TKC） 」を学び、第二回で ESXi 上で直接動かす特殊なポッドである「vSphere Pod」 の利用方法を学び、第三回で管理者としてネームスペースの操作方法を学びました。
第四回は演習環境で最初から準備されている vSphere with Tanzu のネットワークがどのように構成されているかという点について扱います。ネットワークは一度構築されてしまえば気にすることなく利用することができますが、構築する際の設計やプラットフォームの運用をおこなうには理解が必要です。詳細は以下の公式ドキュメントに記載されていますので、この記事ではその知識がほとんどないかたむけに噛み砕いた概要をご紹介いたします。
NSX-T or HA-Proxy ネットワーク
K8sのポッドに対してネットワークを提供するために「サービス」という K8s リソースがあり、そのサービスを外部に公開するための種類（タイプ）として LoadBalancer があります。vSphere with Tanzu では多くのマネージド K8s が LoadBalancer を提供するように、LoadBalancer 機能を vSphere with Tanzu が基盤として提供しています。つまり、ユーザーがサービスリソースのLoadBalancerをyamlに定義して適用すると、vSphere with Tanzu が事前にプールされたIP範囲から外部向け IP を払い出し、その IP 向けに来た通信が yaml 定義により結び付けられたポッドに対して転送されるようになります。
記事執筆時点の最新版である vSphere 7.0 u1 で vSphere with Tanzu はこの LoadBalancer の機能を NSX-T もしくは HA-Proxy で実現しており、これは vSphere with Tanzu のインストール時に設定します（将来的には他のロードバランサーも追加される予定です）。1つの vSphere クラスタでは両者のどちらかを選択する必要があり、併用はできません。第一回から第三回で操作したHOLの環境はNSX-Tの構成となっています。
以下にネットワーク構成の概要図を記載します。
図の左側が HOL で操作していた NSX-T の構成です。vSphere with Tanzu の構築時に事前に用意していた NSX-T と連携をおこない、NSX-T が vSphere with Tanzu の Kubernetes（vSphere PodとTanzu Kubernetes Clusterの両方）にたいしてロードバランサー機能を提供できるようになります。
図の赤い矢印がNSX-Tが管理する通信で、vSphere Pod においてはロードバランサーから ESXi 上に直接展開される Pod にたいしてまで NSX-T が通信を一貫して提供しています。一方、Tanzu Kubernetes Cluster（TKC）の構成においては、NSX-Tはロードバランサーまでの通信の管理（IP 払い出しとエンドポイントの提供）をおこなうだけで、K8s 内部の通信（ワーカーノードからPodまで）は一般的な K8s と同様に CNI プラグインである Calico や Antrea（デフォルト）を使います。
次に図の右側が HA-Proxy の構成です。HA-Proxy 構成では vSphere Pod をサポートしていないため、TKC しか利用できません。HA-Proxy 構成における TKC の通信は NSX-T 構成とほとんど変わらず、ロードバランサー機能を NSX-T の代わりに HA-Proxy が提供するようになります。K8s 内部の通信は NSX-T 構成と同様に一般的な CNI プラグインを利用しています。TKC においては NSX-T でも HA-Proxy でも K8s のロードバランサー機能に大きな違いはありませんが、NSX-Tを使った場合はポッドが動く K8s のノードが NSX-T により保護されている論理ネットワークに展開され、HA-Proxy は指定した物理ネットワーク（VLAN）上に直接ノードが展開されるという違いがあります。
以下にロードバランサーからPodまでの通信を図にまとめます。TKCでは2段階のネットワーク構成になっていることがわかります。
NSX-T と HA-Proxy のどちらのネットワーク構成を選ぶかは「要件（vSphere Pod が必要か、NSX-T 機能が必要か）」や「既に NSX-T を利用しているか」などにより決めます。NSX-T に慣れておらず、とりあえず vSphere with Tanzu を試してみたい場合はシンプルな HA-Proxy で利用してみて、必要性に応じて NSX-T に変更（再構築が必要）するのがよいかもしれません。お客様の利用法次第ですので詳しくは VMware にご相談ください。
ネットワークスタック
最後に vSphere with Tanzu を構成するネットワークスタックについてまとめます。
vSphere Pod においては K8s 内の通信（L2, L3機能）および、ロードバランサーや Ingress（K8s のリソース）の機能を全て NSX-T が提供しています。vSphere Pod は HA-Proxy 構成で利用できないのは、NSX-T の機能に依存しているためです。第二回で説明したように vSphere Pod の独自性は「性能やセキュリティ」といった強みを生みますが、その独自性が「複雑な利用法に向いていない。可搬性が落ちる（VMware以外のK8sへのアプリ移植性が下がる）」という弱みにも繋がります。使い所に応じてご利用ください。
一方、TKC においては K8s 内の通信は一般的な K8s のものです。ロードバランサーは NSX-T 構成であれば NSX-T を利用し、HA-Proxy 構成であれば HA-Proxy を利用します。ロードバランサーの利用法は標準的なK8sと同様に yaml で宣言するだけなので、別の種類のロードバランサーを使う他の K8s への移行はおそらく難しくありません。なお、図にあるように現時点では Ingress は TKC ごとにマニュアルに沿って展開する必要があります。将来的に Ingress 機能の組み込みは計画されています。
Contour を使用した Tanzu Kubernetes Ingress の例
Nginx を使用した Tanzu Kubernetes Ingress の例
一番右は参考情報であり、vSphere with Tanzu ではなく、もうひとつの Tanzu Kubernetes Grid の製品である TKG multi-cloud の現時点のネットワークスタックです。詳細は TKGm の解説で取り扱います。
以上で 「触りながら学ぶ vSphere with Tanzu」の連載を終えます。次回以降はこれまでと同様のコンセプトで TKG multi-cloud を HOL 環境で操作しながら学んでもらう連載をおこなう予定です。ご拝読ありがとうございました。
