はじめまして。VMware の伊藤です。Tanzu 製品のプラットフォームアーキテクトとして働いており、開発と運用双方の経験があります。この記事ではロードバランサーとして NSX-ALB（別名Avi）を使って TKG 1.3.0 を vSphere 7.0u2 で構成する手順を紹介します。
TKG 1.3.0 は前バージョンの TKG 1.2.1 に比べて大幅に機能強化されています。たとえば Kubernetes のロードバランサーとして NSX-ALB （通称Avi） を利用できるようになったり、ユーザ認証系の仕組みが導入されたり、HTTP Proxy がある環境での利用が簡単になったといった点が挙げられます。この記事では TKG 1.3.0 を試すための簡易導入手順を紹介します。本番環境での利用を想定した構築ではないため、ご注意ください。
なお、TKG （vSphere 組み込みでない Kubernetes）ではなく vSphere with Tanzu 7.0u2 （vSphere 組み込みの Kubernetes）をインストールしたい場合は以下の記事を参照ください。
vSphere with Tanzu 7.0u2, NSX-ALB LoadBalancer の簡易構成の構築
構築するネットワーク構成
TKG1.3 の構築に入る前に作成する構成を確認します。インフラ面で設定が多いのはネットワークだけであり、それ以外のストレージや vSphere 自体の設定は vSphere の基礎的な知識があれば難しくありません。
以下にこの記事で構築するインフラ構成を記載します。
TKG 1.3 は1つの ESXi ホストと vCenter で構成することが可能ですが、ここでは3台の ESXi で構築します。検証目的の最小構成は1つの ESXi に vCenter も載せる構成で、 NSX-ALB ありでメモリー64GB、なしでメモリー32GB あたりですので、商用のマネージド k8s 環境としては試しやすい部類かと思います。
重要なのは vSphere に2つの Distributed Port が作成されており、「dp-mgmt-64」をマネージメント系として利用し、「dp-data-80」をデータ系として利用します。これらのネットワーク間ではルーティング経由で疎通できる必要があります。この記事の環境では ESXi が接続する物理 L3Switch として Cisco 社の Catalyst を利用しており、必要な VLAN をTrunk で vSphere の物理NIC（vmnic1）に提供しています。vmnic0 は管理用と共有ファイルサーバーへの接続、 vMotion にしか利用していません。
dp-mgmt-64 及び dp-data-80 はともに DHCP が有効化してあり、インターネットへのアクセスに障害となる Firewall や HTTP Proxy がありません。インターネットは TKG が使うコンテナイメージを VMware リポジトリから取得するのに使われます。そのため、Firewall がある場合はポートやアクセス先に穴を開け、Proxy がある場合はそれを利用するように追加設定が必要となります。他には完全にインターネットアクセスがない環境でも TKG は展開可能です。ただ、これらの手法は環境構築の手順が増えるため、この記事では扱いません。
次に管理用ネットワークとデータ用ネットワークを中心にして、TKG に使われるコンポーネント群がどのようにそれらのネットワークに接続されるかを説明します。
まず、vCenter ですが、今回は管理用ネットワークに接続しています。IP 到達性があれば別のネットワークでも構いません。
左から2つめの Bootstrap は右から2つめのマネージメントクラスタ（後述）を展開するマシンです。このマシン上の Docker 上にマネージメントクラスタを展開するアプリケーションを起動して、必要情報を入力することでマネージメントクラスタを作成します。ここでは Ubuntu に Docker をインストールしたものを Bootstrap としていますが、Windows や Mac に Docker Desktop をインストールして Bootstrap として利用することも可能です。
左から3つめの NSX-ALB Controller は K8s が使う L4 LoadBalancer や Ingress のIPを提供するロードバランサー機能のコントローラーとなる VM です。今回は1台のみ展開しますが、クラスタ構成を組むこともできます。これは管理用ネットワークにのみに接続します。
左から4つめの NSX-ALB Service Engine （SE） はロードバランサーとして通信を転送する VM です。NSX-ALBSE は Avi Controller により管理されるため、ユーザーが直接操作することはありません。必要になればコントローラーが勝手に作成（増やす）し、不要になれば勝手に台数を減らします。今回は Active/Standby 構成を組みますが、Active/Active 構成や N+M （必要なN台 + バッファのM台）構成を使うこともできます。図にあるように Avi SE は管理用ネットワークにも、データ用ネットワーク（LoadBalancer として払い出される IP）にも接続します。今回は管理用ネットワークの IP には DHCP のアドレスを利用しますが、IP Pool を使うこともできます。データ用の IP にも DHCP を使えますが、今回はロードバランサーで使う IP アドレスを調整しやすいように IP Pool を定義して、そこから払い出す設定とします。
左から5つめのマネージメントクラスタは、右にあるワークロードクラスタ（Kubernetes）を管理するための Kubernetes となります。このスーパーバイザクラスタにたいして、「ワークロードクラスタ X を作成/スケール/アップグレード/削除/その他してください」と命令を tanzu CLI で投げることにより、ワークロードクラスタを簡単に構成変更することができます。マネージメントクラスタのノードは上のデータ用ネットワークに接続する構成としましたが、下のマネージメント系ネットワークに展開しても構いません。
最後の右端のワークロードクラスタは実際にアプリケーションを動かすクラスタです。ユーザー視点としては一般的な K8s クラスタですが、運用者視点ではマネージメントクラスタによりマネージドされる K8s クラスタとなります。これはデータ用ネットワークにのみ接続されます。
上記のネットワーク利用法をみるとわかりますが、管理用ネットワークに必要な IP 数は少ないのにたいしてデータ用ネットワークでは規模に応じて IP 数が増大します。当然ですがロードバランサーが使う IP レンジとワークロードクラスタの K8s ノードが使う IP レンジが固定 IP や DHCP も含めて重複しないようにする必要があります。検証環境では問題ないかもしれませんが、本番環境ですとプレフィックス「/24」だと IP が不足する可能性が高いので、余裕を持ったネットワーク設計をするように注意してください。
この記事では順に NSX-ALB やマネージメントクラスタのネットワーク設定を実施していきますが、上記図のどこをどの設定項目で設定しているかを意識するようにしてください。
構築前の準備
TKG with NSX-ALB on vSphere の構築手順はおおまかに以下の流れとなります。
- 必要なイメージなどを VMware からダウンロード
- vSphere の準備
- NSX-ALB の展開と設定
- Bootstrapのセットアップ
- マネージメントクラスタの作成
マネージメントクラスタを複数作成する場合、ステップ1-4で構築したものは再利用可能です。そのため、開発や運用チームごとにマネージメントクラスタを用意するといったシナリオでは、2回目以降のマネージメントクラスタ構築は多くの工程をスキップできます。
ここではイメージのダウンロードおよび vSphere の準備について説明します。
まず、最低限必要な4つのイメージを取得します。
Download VMware Tanzu Kubernetes Grid
- Tanzu CLI : VMware Tanzu Kubernetes Grid -> VMware Tanzu CLI for Linux
- VMware kubectl : VMware Tanzu Kubernetes Grid -> kubectl cluster cli v1.20.4 for Linux
- KubernetesノードのOVA: VMware Tanzu Kubernetes Grid -> Ubuntu 2004 Kubernetes v1.20.4 OVA （Photon版でもOK）
- NSX-ALB コントローラのOVA: VMware NSX Advanced Load Balancer -> VMware NSX Advanced Load Balancer （Hosted on Avi Networks Portal） -> 20.1.4 -> VMware Controller OVA
Tanzu CLI や kubectl 及び NSX-ALB OVA は後ほど使うのでおいておき、ここでは3つめの Kubernetesノード OVA を使って vSphere に「k8sノードとなるテンプレート」を作成します。手順としては以下の流れとなります。
- メニュー -> ホスト及びクラスタ -> クラスタを右クリック
- OVFテンプレートのデプロイ -> ダウンロードした上記の Ubuntu（or Photon）の OVA イメージを指定
- 指示されるままに画面を進めてデプロイ （後で変更されるのでネットワーク指定などは重要ではない）
- 作成された仮想マシン（電源 ON しないこと）を右クリック
- テンプレート -> テンプレートに変換
- 画面左上(以下の図の右上のアイコン)からテンプレートページに進み、テンプレートを右クリック -> 権限の追加
- Admin権限を与える
この作業は作成した TKG の k8s ノード（仮想マシン）自体が、vSphere 環境を操作（たとえば k8s ノードを作成したり、k8s の PV 操作でストレージを使ったり）するために必要な権限を与えるために実施します。今回は手間を省くために「テンプレートにAdministrator 権限を与えて、なんでもできるようにする」としてしまいましたが、本番環境では以下のドキュメントの手順にしたがって「TKG を運用するのに必要な最低限の権限を持つロールとユーザを作成して、それをテンプレートに与える」という設定をおこないます。
Prepare to Deploy Management Clusters to vSphere -> Required Permissions for the vSphere Account
ロードバランサー NSX ALB （Avi）の構築
vSphere の準備が整ったため、ロードバランサーの展開をおこないます。ロードバランサーの展開はおおまかに以下の手順となります。
- NSX-ALB Controller の OVA を展開。Controller のネットワーク設定はここで実施
- 展開した NSX-ALB Controller にブラウザでアクセス
- NSX-ALB Controller の初期設定 （Service Engine のマネージメント側の設定）
- SSL証明書の設定
- Service Engine （SE） の設定（ネットワーク以外）
- Service Engine のデータ側ネットワークの設定（複数ページで実施）
以下からスクリーンショットベースで設定をしていきますが、具体的な手順は以下のオリジナルドキュメントをご参照ください。
Install VMware NSX Advanced Load Balancer on a vSphere Distributed Switch
先ほど事前準備でダウンロードした NSX-ALB Controller OVAを以下の図のように vSphere に展開します。
OVAの展開時に NSX-ALB Controller のネットワーク周りのパラメーターの設定が求められます。冒頭の図を参照して管理系ネットワークの設定を実施してください。
今回は以下の設定をしています。
- マネージメントネットワーク: dp-mgmt-64
- IP Address: 192.168.64.19
- サブネットマスク: 20
- Default Gateway: 192.168.64.1
- Sysadmin login authentication key: オプション設定なので設定せず
デプロイが完了したら、電源 ON します。なお、NSX-ALB コントローラーが必要とする CPU /メモリリソースは本番環境を想定して多め（vCPU 8, メモリ24G）になっています。検証環境であれば少し減らしても問題なく、この記事の環境では仮想マシン設定で vCPU 3, メモリ 16G に変更しています。
起動してから5-10分（初起動時のみ、裏側で様々な設定がされるため時間がかかります）ほど待って、ブラウザで NSX-ALB Controller の IP にアクセスをします。今回であれば「http://192.168.64.19」となり、HTTPS にリダイレクトされます。繋がらなかったり白い画面が出る場合は少し待ってからアクセスしてみてください。
初回アクセスすると上記図のようにアラートが表示されるかもしれませんが、証明書に関するものなので無視してください。 Chrome であれば「thisisunsafe」と入力すれば進めますが、具体的な手順はブラウザ次第となります。
アラートページをすぎると図の中央にある admin ユーザの設定を実施、DNS やバックアップのパスフレーズの設定などを実施します。パスフレーズの下に隠れているNTPの設定はインターネットに接続していればそのままで問題ありません。
次にEメールの設定ですが、今回は利用しないので None を指定します。基盤の設定は vSphere を使うので VMware を設定します。基盤に VMware を設定すると vCenter へのアクセス情報を求められるので、入力をおこないます。「Permission は Write」「SDN Intergration はNone」にしてください。両設定ともデフォルトです。
vCenter に接続が成功すると、vSphere のデーターセンターの指定を実施します。データセンター下の2つのチェックボックスは構築するネットワークに依存して設定が変わりますが、今回は NSX-ALB Service Engine からワークロードクラスタのノードにたいしてルーティングが発生しない（両者とも同一ネットワーク dp-data-80 にいるため）のでチェックを外しています。
マネージメントネットワークの設定で dp-mgmt-64 を指定し、Service Engine の IP を DHCP から取得する設定をします。最後のテナントの設定は No としてください。以上で NSX-ALB Controller の初期設定は終了となり、NSX-ALB Controller の管理画面が表示されます。
管理画面での最初の設定はSSL証明書（HTTPS）となります。
管理画面左上のスタックアイコンより、Administration -> Settings -> Access Settings と進みます。右上の鉛筆アイコンから編集に入り、既存の SSL/TLS Certificate を 「x」ボタンで消し、右側の「V」アイコンから「Create Certificate」で新規の証明書の作成を実施します。
証明書のパラメーターは今回は以下としました。
- Name: mycert
- Type: Self Signed
- Algorithm: RSA
- Key Size: 2048
- Common Name: 192.168.64.19 （IPアドレス）
- Subject Alternate Name: 192.168.64.19
きちんとした公式の証明書がある場合はアップロードして利用することも可能です。証明書の更新後におそらくブラウザのリロードが必要になります（証明書が変わったのでアラート画面の再表示が必要なため）。
作成した証明書は以下の図のように「Templates -> Security -> SSL/TLS Certificate」と進み、取得したい証明書をクリックしてダウンロードボタンを押すと表示されます。証明書の鍵（key）と証明書（Certificate）の2つがあるので混同しないように注意してください。後ほど TKG マネージメントクラスタ構築の設定で利用するのは下の Certificate 側です。
次に Service Engine をどのように展開するかを設定します。
Infrastructure -> Service Engine Group と進んでください。
最初から存在する Default-Group の設定を変更し、HA を Active/Standby に設定しました。利用できるライセンスにより利用できる冗長化方式は変わります。その下にある「Virtual Services per Service Engine」は NSX-ALB SE ごとにいくつの仮想サービス（TKGでは k8s の L4LB や Ingress のエントリ）を持てるかという設定です。デフォルトの10だと少ない場合は増やしてください。
ここからは Service Engine のデータ側（ロードバランサーのIP）にたいするネットワーク設定が続きます。
Infrastructure -> Networks と進んで管理画面を開きます。
データ用ネットワーク（今回は dp-data-80）の編集アイコンをクリックし、このネットワークの設定をおこないます。今回は以下の設定をしています。
- DHCP Enabled: IP Pool を使うのでチェックを外す
- もし「Exclude Discovered Subnets…」が表示されていたらチェックをいれる（自動検知したものは無視）
- Add Subnet でサブネット 192.168.80.0/22 を追加
- サブネットとIP Pool （192.168.80.50-192.168.80.255）を設定。IP Pool には K8s のL4LB, Ingress が使うIPを指定
設定して保存すると、図の左下のように設定表示が更新されます。
なお、ここで指定したネットワークとワークロードクラスタのネットワークが異なる場合は、上記図のルーティング（Infrastracture -> Routing）の設定も追加で必要になります。今回は同一ネットワークに両者が存在するのでルーティング設定は不要となるため割愛します。
次にIPAM（IP Address Management）とDNSの設定をします。
Templates -> Profiles -> IPAM/DNS Profiles と進みます。
IPAM では先程設定したネットワークをプロファイル化し、同じように DNS 設定もプロファイル化します。
最後の設定はクラウド設定（vSphere）に先程作成した IPAM と DNS プロファイルを結びつける作業となります。
Infrastructure -> Clouds と進み、Default-Cloud を編集してプロファイルを結びつけています。
以上で NSX-ALB の構築設定は終了となります。
Bootstrapマシンの準備
TKG のマネージメントクラスタを作成するのが Bootstrap マシンの役目です。最初に説明したように Bootstrap マシンは個人の Windows や Mac に Docker Desktop をインストールして利用してもよいのですが、今回は「複数の管理者が Bootstrap マシンを利用する」という想定で Ubuntu の仮想マシンを利用します。Ubuntu 上で Docker などを動かすので、メモリは最低2Gで、できれば4G以上を割り当ててください。今回は OS に Ubuntu 20.04 LTS を利用しています。
ここでは以下の手順で作業を実施します。
- ubuntuのrootユーザになる
- ssh keyがなければ作成
- dockerなどのツールを準備
- tanzu cli や kubectl を準備（今回は外部からscpでホームディレクトリ（/root）に配置）
- tanzu cli のインストール
- kubectl のインストール
以下に実行サンプルを記載します。
後半の tanzu cli および kubectl の準備方法については詳細がドキュメントに記載されていますが、ダウンロードした圧縮ファイルを解凍してバイナリをパスが通ったディレクトリ（/usr/local/bin）に配置し、tanzu cli にプラグインを追加する作業を実施しています。
TKGマネージメントクラスタの構築
準備が整いましたので、いよいよ TKG マネージメントクラスタの構築を開始します。マネージメントクラスタの構築には以下の2つの手法があります。
- tanzu cli にパラメータを渡して構築
- tanzu cli でインストール UI を起動し、それにパラメータを入力して構築
前者は2つめ以降のマネージメントクラスタの構築に便利なのですが、初回は自分でパラメータファイルを用意するのが大変です。そのため後者の UI を使ったインストールをここでは実施します。インストール手順は以下のドキュメントに記載されます。
Deploy Management Clusters with the Installer Interface
構築を開始するまえにネットワーク構成を再確認します。
この図にあるようにマネージメントクラスタはデータ用ネットワークのみを利用します。今回は NSX-ALB や ワークロードクラスタと同じネットワークである dp-data-80 を使います。
まず、tanzu cli のコマンドでインストーラーの画面をたちあげます。コマンドの裏側では Docker 上にウェブサービスとして構築アプリを展開しており、それにブラウザでアクセスします。なお、GUI がある OS でコマンドを発行するとと勝手にブラウザがたちあがり、インストーラー画面が表示されます。ただし、今回は GUI を持たない minimal サーバーの ubuntu を使っているため、バインドオプション（-b）で外部公開IPとPortを指定してウェブサービスをたちあげています。そして、手元の Windows や Mac からブラウザで IP とポートを指定してアクセスします。
TKG は現時点で vSphere 環境に加えて、AWS と Azure での実行をサポートしています。今回は vSphere 上に展開するため、vSphere の Deploy をクリックして最初の設定画面に進みます。
最初の設定は vCenter との接続です。画面上部のクレデンシャルを入力して「Connect」ボタンで接続すると、vSphere7 であれば右のような画面が現れます。これは「vSphere7 は vSphere with Tanzu もサポートしているが、TKG をインストールするか?」と聞いており、今回はインストールするので「Deploy TKG Management Cluster」を選択します。
画面下部の Datacenter の項目では、vSphere の Datacenter を指定し、その右の SSH Public key では、マネージメントクラスタのノードに SSH 接続する端末の SSH 公開鍵を指定します。SSH 接続は通常の操作では必要ないかもしれませんが、トラブルシューティング（サポート）を実施する際などには必要です。今回は bootstrap クラスタから SSH できるようにしたいので、bootstrapクラスタのSSH公開鍵（/root/.ssh/id_rsa.pub）を指定しています。
その次の設定項目はマネージメントクラスタの構成です。ここではマスターノード/ワーカーノードのマシンサイズやノード数、クラスタ名や IP などを指定します。サイズやノード数は今回は最小値を指定していますが、本番構成時は右側の「Production 構成」を選んで、マシンサイズも処理を十分にこなせる大きさを指定してください。サイジングのガイドが必要なお客様は VMware にお問い合わせください。
この設定で気をつける必要があるのが「Control Plane Endpoint」です。これはマネージメントクラスタの代表 IP の設定なので、当然ながらマネージメントクラスタを展開するネットワーク（後で指定）のなかにあるアドレスで、衝突が発生しないものである必要があります。今回は dp-data-80 のネットワークをつかい、NSX-ALB で指定したプール（192.168.80.50 – 192.168.80.255）や、DHCP のレンジ （192.168.83.0 – 192.168.83.250） に衝突しない「192.168.81.0」を指定しています。
次の設定項目は NSX-ALBの設定です。これはオプションですので NSX-ALB を利用しない場合は省略することができます。
画面上部にクレデンシャルを入力して「Verify」ボタンで接続してから、クラウド名やサービスグループを指定します。VIP Network Name および VIP Network CIDR には、NSX-ALB Service Engine のデータ側のネットワークを指定する必要があります。今回は「dp-data-80」と「192.168.80.0/22」となります。その下の証明書の入力はこの記事のAviのセクションで解説した方法で取得した証明書の内容を入力してください。
この次のページに「4. Metadata（メタデータ）」の設定がありますが、オプションなので飛ばします。
その次のページ（5. Resources）では、マネージメントクラスタの展開に使う仮想マシンフォルダー、データストア、クラスタやリソースプールの指定を実施します。お使いの環境に合わせて設定してください。
その次のページ（6. Kubernetes Network）では、マネージメントクラスタが使う vSphere ネットワークを指定します。今回であれば dp-data-80 となります。その右の「Cluster Service CIDR」や「Cluster Pod CIDR」はk8sの中のネットワークですので、このアドレスを組織で利用していなければそのままで問題ありません。画面下部の「Enable Proxy Settings」は、マネージメントクラスタを HTTP Proxy 環境下でデプロイするために必要な設定です。今回は HTTP Proxy がないため、設定を無効化しています。
図に記載はありませんが、この次のページ（7. Identity Management） では、TKG にログインするクレデンシャルを LDAP などで管理する機能を設定します。今回はこの機能は利用しませんので Disable にしています。
次の項目（8. OS Image）は、マネージメントクラスタのノードに使う k8s のイメージ指定です。事前準備でテンプレート化したイメージを選択してください。もしここでイメージが見えてこなければ、テンプレートを再確認してください。たとえば TKG1.3 がサポートしていない古い TKG 向けのイメージなどは表示されません。
このページの次に TMC 及び CEIP Agreement の設定ページがありますが、今回は利用しないので特に設定変更せずにそのまま進めてください。
これですべての項目を設定し終えたので、設定確認後にデプロイボタンでマネージメントクラスタの構築を開始します。
なお、一番下に「CLI Command Equivalent」という項目があり、ここに今回実施した設定内容が書かれたファイルが表示されています。これを改変して別のマネージメントクラスタのインストール作業をGUIなしで実施することが可能です。ただ、それよりも後ほど紹介するワーカークラスタのデフォルトパラメータとして利用するのが便利なので、ファイル名をメモしておいてください（メモしておかなくても ls コマンドで探せますが）。
構成にもよりますが、インストールは約10-20分で終了します。インストールが完了すれば、インストールに使った bootstrap 環境で tanzu cli を使ってマネージメントクラスタを利用することができるようになっています。
Bootstrap によるマネージメントクラスタの構築完了後に vSphere Client を確認すると、以下の図のように仮想マシンとしてマネージメントクラスタのノードが展開されていることが確認できます。
クラスタのデフォルトパラメータ設定の作成と、ワークロードクラスタの作成テスト
ワークロードクラスタの作成と利用方法について扱うと長くなるので別記事としたいですが、この記事の最後に今後作成するクラスタのデフォルト値の設定作業を実施します。ワークロードクラスタを作成する際にはそのパラメータ（名前やネットワーク構成など）を指定する必要があります。パラメータをユーザーがファイルで与えなかった場合はデフォルト値が用いられます。このデフォルト値を設定しておくと、ワークロードクラスタ作成時に毎回必要項目全てを指定するのではなく、差分のみ指定すればよくなるので運用が楽になります。
デフォルト値の定義ファイルは「~/.tanzu/tkg/cluster-config.yaml」になり、初期構築直後はおそらく空です。これに先ほど作成したマネージメントクラスタの設定値を上書きすることでデフォルト値とします。作成したマネージメントクラスタの設定値は「~/.tanzu/tkg/clusterconfigs/」に格納されており、今回は Bootstrap の設定確認ページに表示されていたように「~/.tanzu/tkg/clusterconfigs/mk6v8efkks.yaml」となります。メモし忘れていた場合は「ls -l」コマンドで作成日時から絞り込み、ファイルの中身をチェックして正しい設定ファイルを特定してください。マネージメントクラスタの初期構築直後であれば、1ファイルしか存在しないはずです。
このマネージメントクラスタの内容をデフォルト設定値ファイルに上書きし、デフォルト設定値としてほしくない内容（クラスタ名やクラスタの代表IP）の項目を削除する作業を実施します。以下に実行サンプルを記載します。
似た名前のファイルがいくつか存在するので、間違って別の設定ファイルを上書きしないように注意してください。ここでは上書きしたあとに「CLUSTER_NAME」や「CLUSTER_CONTROL_PLANE_ENDPOINT(代表IP)」といった必ず違う設定が必要な項目の行を sed コマンドで削除しています。必要であれば他の項目も削ったり、パラメータの変更を実施してください。たとえばワークロードクラスタをマネージメントクラスタと異なるネットワークに展開したい場合は「VSPHERE_NETWORK」の項目を変更します。
設定ファイルとそれをワークロードクラスタがどう使うかについては以下のドキュメントを参照ください。
- Create a Management Cluster Configuration File from a Template
- Deploy Tanzu Kubernetes Clusters to vSphere
これでクラスタのデフォルト値を設定できたので、実験的に新規ワークロードクラスタを作成してノードを確認してみます。
「tanzu cluster create」コマンドでクラスタ名と代表IP（vsphere-controlplane-endpoint）を指定してワークロードクラスタ mycluster を作成しました。指定していない「どのネットワークを使うか」といった項目はデフォルト値どおりにマネージメントクラスタと同一のものを使います。ワークロードクラスタの構築にかかる時間はおよそ10-20分程度です。
構築完了後に「tanzu cluster kubeconfig get」コマンドで作成したワークロードクラスタのコンテキストを取得しています。コンテキスト取得後のワークロードクラスタの利用法はバニラk8sとほぼ同じとなります。ここではコンテキストを指定したうえで、ワークロードクラスタのノード一覧を表示させています。
最後に構築した NSX-ALB が動作していることを確認するために、nginx の Pod を作成し、それを Type LoadBalancer のサービスで公開します。
ロードバランサーの実トラフィックを処理する NSX-ALB Service Engine は一番最初に L4LB や Ingress リソースが作成されてから NSX-ALB Controller が仮想マシンとして作成します。そのため、初回のリソース作成時に実際に利用できるようになるのに5-10分ほど時間がかかる点にご注意ください。もちろん、別のワークロードクラスタを含めて2つめ以降の L4LB や Ingress リソースの作成後にアドレスは即利用可能となります。そのため、実運用において大きな問題はないはずです。
上記サンプルのように L4LB サービスのリソース作成をおこなってから wget でアクセスすると、nginx のインデックスページの取得に成功(レスポンスが200)しています。つまり、 LoadBlancer IP で k8s のポッドにアクセスできることが確認できました。
