はじめまして。VMware の伊藤です。Tanzu 製品のプラットフォームアーキテクトとして働いており、開発と運用双方の経験があります。この記事ではロードバランサーとして NSX-ALB（別名Avi）を使って TKG 1.4.0 を vSphere 7.0u2 で構成する手順を紹介します。
Tanzu Kubernetes Grid （以下 TKG）のバージョン 1.4.0 はいくつかの機能が追加されているものの、基本機能に限定すれば TKG 1.3 と大きな違いはありません。この記事では以前の TKG を知らないことを想定した TKG 1.4.0 をシンプルなネットワーク構成でインストールする手順を紹介します。
なお、すでに TKG 1.3 のインストールを知っているかたむけに違いの要約をすると以下となります。
- NSX-ALB が TKG 1.3 がサポートしていた 20.1.3 に加えて、20.1.6 がサポートされた。20.1.6 と 20.1.3 は UI が少し異なるが、設定項目は同じ
- Management Cluster や Workload Cluster の代表 IP が以前は固定 IP だけだったが、追加で NSX-ALB の払い出し IP を利用できるようになった
公式ドキュメントのトップページは以下となります。
また、NSX-ALB の構成はこの記事では最小としています。これは独立記事を用意しているので、概要がつかめたらこちらも参照ください。結論から言うと、この記事の 3 ネットワーク構成を推奨します。
具体的なインストール手順に入る前に、TKG の概要とインストールする vSphere 環境を紹介します。
以下に概要図を記載します。
TKG はマルチクラウド環境で利用することを想定した KaaS （Kubernetes as a Service） 製品です。OSS の K8s を仮想マシンやベアメタル上に構築するのであれば、構築だけでなくスケール（増築）/アップグレード/障害時の復旧/破棄などの作業を全てエンジニアが手で実施する必要があります。一方、TKG をはじめとする KaaS 製品を導入した場合は上記のようなライフサイクル管理操作を KaaS 基盤側が面倒をみてくれるため、K8s クラスタの利用者や管理者の負担が大幅に減り、管理性も増します。
図にあるように TKG は「Management Cluster」を様々な IaaS 上に構築します。この Management Cluster を操作することで、実際にアプリケーションを動かす「Workload Cluster」のライフサイクル管理を実現します。ユーザーとして K8s を使う場合は、標準的な kubectl などによる操作ができるため、k8s クラスタ自体には VMware 色はほとんどありません。
この記事で扱う TKG のインストール作業はこのマネージメントクラスタの構築作業にあたります。ワーカーノードの構築はインストールではなく、tanzu コマンドを発行することで実現します。
次に TKG をインストールする vSphere 基盤のネットワーク構成について確認します。
TKG 1.4 は1つの ESXi ホストと vCenter で構成することが可能ですが、ここでは3台の ESXi で構築します。検証目的の最小構成は1つの ESXi に vCenter も載せる構成で、 NSX-ALB ありでメモリー64GB、なしでメモリー32GB あたりですので、商用のマネージド k8s 環境としては試しやすい部類かと思います。
vSphere に1つの「dp-mgmt-32」という Distributed Port が作成されております。この記事の環境では ESXi が接続する物理 L3Switch として Cisco 社の Catalyst を利用しており、VLAN なども適切に設定されています。ただ、1つのネットワークしか利用しないため家庭用のホームルーターとスイッチングハブなどでも問題なくこの構成を作れます。
dp-mgmt-32 は DHCP が有効化してあり、インターネットへのアクセスに障害となる Firewall や HTTP Proxy がありません。インターネットは TKG が使うコンテナイメージを VMware リポジトリから取得するのに使われます。そのため、Firewall がある場合はポートやアクセス先に穴を開け、Proxy がある場合はそれを利用するように追加設定が必要となります。他には完全にインターネットアクセスがない環境でも TKG は展開可能です。ただ、これらの手法は環境構築の手順が増えるため、この記事では扱いません。
なお、この構成はネットワークセキュリティなどを全く考慮しておらず、「公開しているアプリケーションと基盤の重要なコンポーネント（vCenter や NSX-ALB、k8sノードなど）が同一ネットワークにある」という問題があります。つまり、外部に公開するべきアプリと、内部に隠すべき基盤が同一ネットワークに存在しているので攻撃に弱いネットワークの構成ですし、アプリレベルの問題が基盤に波及しやすい構成でもあります。
次にTKG に使われるコンポーネント群がどのようにそれらのネットワークに接続されるかを説明します。
まず、右下の vCenter ですが、今回は管理用ネットワークに接続しています。IP 到達性があれば別のネットワークでも構いません。
右下の Bootstrap は右上のマネージメントクラスタ（後述）を展開するマシンです。このマシン上の Docker 上にマネージメントクラスタを展開するアプリケーションを起動して、必要情報を入力することでマネージメントクラスタを作成します。ここでは Ubuntu 20.04 に Docker をインストールしたものを Bootstrap としていますが、Windows や Mac に Docker Desktop をインストールして Bootstrap として利用することも可能です。
左端の NSX-ALB Controller は K8s が使う L4 LoadBalancer や Ingress のIPを提供するロードバランサー機能のコントローラーとなる VM です。また、展開する k8s クラスタ自体の代表IPに利用することも可能です（利用しない場合は固定IPの設定が必要です）。今回はコントローラーを1台のみ展開しますが、クラスタ構成を組むこともできます。
左から2つめの NSX-ALB Service Engine （SE） はロードバランサーとして通信を転送する VM です。NSX-ALB SE は NSX-ALB Controller により管理されるため、ユーザーが直接操作することはありません。必要になればコントローラーが勝手に作成（増やす）し、不要になれば勝手に台数を減らします。今回は Active/Standby 構成を組みますが、Active/Active 構成や N+M （必要なN台 + バッファのM台）構成を使うこともできます。本来は管理用ネットワークとデータ用ネットワークの2つに接続されますが、今回は同じネットワークで管理用とデータ用の通信をおこないます。
右上のマネージメントクラスタは、右にあるワークロードクラスタ（Kubernetes）を管理するための Kubernetes となります。このスーパーバイザクラスタにたいして、「ワークロードクラスタ X を作成/スケール/アップグレード/削除/その他してください」と命令を tanzu CLI で投げることにより、ワークロードクラスタを簡単に構成変更することができます。
最後の右端のワークロードクラスタは実際にアプリケーションを動かすクラスタです。ユーザー視点としては一般的な K8s クラスタですが、運用者視点ではマネージメントクラスタによりマネージドされる K8s クラスタとなります。
上記のネットワーク利用法をみるとわかりますが、規模に応じて必要な IP 数が増大します。また、当然ですがロードバランサーが使う IP レンジとワークロードクラスタの K8s ノードが使う IP レンジが固定 IP や DHCP も含めて重複しないようにする必要があります。検証環境では問題ないかもしれませんが、本番環境ですとプレフィックス「/24」だと IP が不足する可能性が高いので、余裕を持ったネットワーク設計をするように注意してください。
この記事では順に NSX-ALB やマネージメントクラスタのネットワーク設定を実施していきますが、上記図のどこをどの設定項目で設定しているかを意識するようにしてください。
事前準備
TKG および NSX-ALB をインストールするための事前準備をします。
実施することは少なく、必要なイメージのダウンロードと、vSphere への TKG K8s ノードのイメージ登録だけです。
まず、NSX-ALB 以外の全てのTKGの必要ファイルを以下のページのリンクからダウンロードします。
必要なファイルは bootstrap 上に展開する、Tanzu CLI と kubectl コマンドおよび、k8s のノードイメージです。前者は動かすホストごとにファイルが異なります。今回は ubuntu 20.04 上に bootstrap を構築するので、Linux 用のイメージを入手します。
次に NSX-ALB のイメージを入手します。利用できるイメージは TKG のバージョンごとに異なりますので、最新の TKG リリースノートでサポートバージョンを確認してください。今回は 20.1.6 を利用します。
NSX-ALB のダウンロードページは上記の TKG からは辿れないので、MyVMware の検索窓などを使ってページに進んでください。上記図の Download Now をクリックするとバージョンごとの NSX-ALB のダウンロードページに進めますので、そこで正しいバージョン（20.1.6）とプラットフォーム（vSphere）を指定して OVA イメージを入手してください。
必要な4つのファイルが揃えられたら、次に K8s のノードイメージを vSphere に用意します。
以下に設定概要図を記載します。
vSphere で OVA を展開するには、クラスタやリソースプールを右クリックして、「OVF テンプレートのデプロイ」から開始できます。VM を展開する際に指定する細かいパラメーター（データストアやネットワークなど）は、最終的にテンプレート化されてしまうので細かく考えずにデフォルト値をそのまま指定して問題ありません。K8s の展開時にどのデータストアやネットワークを使うかと言った設定は TKG のインストール時などに指定します。
テンプレートには権限設定が必要です。本来（公式ドキュメントの手法）は必要最低限の権限をつけるためにユーザーを作成して絞った権限の付与操作などをしますが、今回は admin 権限を与えることでテンプレートに十分すぎる権限を与えます。
NSX-ALB の展開
vSphere の準備ができたので、NSX-ALB の展開を実施します。
公式ドキュメントとしては以下となりますが、こちらは 20.1.3 で記載されていますので、20.1.6 を使うこの記事の内容と若干異なります。
もし NSX-ALB 20.1.3 のインストール解説記事を見たい場合は、TKG 1.3 のインストール記事を参照ください。
構成に対応する NSX-ALB の設定項目を赤字で記載します。
この作業の起点は NSX-ALB Controller の展開です。さきほどダウンロードした OVA から、仮想マシンを展開します。ネットワーク構成を考えた上でVM展開時に IP などを与えてください。
NSX-ALB Controller の仮想マシンが電源 ON になってから、5-10 分ほど待つと利用可能になります。電源 ON 直後にアクセスしても、レスポンスが返ってこないか、構築中のメッセージが表示されます。
以下に NSX-ALB の設定の全体の流れを記載します。
矢印は各設定の依存関係を示しています。たとえば、IPAM/DNS 設定では Network 設定で作成した項目を利用するので、Network 設定をしてから IPAM/DNS 設定をする必要があります。この矢印の流れに沿って、具体的な設定をほどこしていきます。
まず、NSX-ALB の初期設定です。VM 展開時に指定した IP にブラウザでアクセスします。HTTP でアクセスすると HTTPS にリダイレクトされます。
図の左にあるように、管理者の初期パスワードを設定します。そして、バックアップなどに利用するパスフレーズやEメールの設定、マルチテナントの設定が促されます。今回はパスフレーズとDNSの設定のみ実施し、EmailやMulti-Tenantの設定はしていません。
これらの初期設定を完了すると、NSX-ALB の管理画面に遷移します。
管理画面に移ったら、まず最初に NSX-ALB を vSphere に接続します。これをしないと、vSphere のネットワークなどを NSX-ALB が認識できません。設定は「Infrastructure -> Clouds -> デフォルトのクラウド -> 編集ボタン」と進みます。
クラウドの種類に VMware vSphere を選択すると、vCenter の IP やクレデンシャル情報などが聞かれるので、アドミニストレーターの情報を与えてください。
その際に続けて DataCenter （vSphere のデータセンタの指定）と Network で NSXALB SE のネットワークの指定などもしてしまいます。ここで NSX-ALB の管理用ネットワークの設定もできますので、今回利用する「192.168.32.0/20」のネットワークの基本情報と、IP Pool の範囲「192.168.33.0 – 192.168.33.255」も指定します。
次に、ロードバランサーの設定の根幹となるネットワークの設定をします。
今回は全てが同一ネットワークにあるので、そのネットワーク（dp-mgmt-32）の設定のみをしています。とは言っても、すでにクラウドの設定で IP Pool などを設定したためすでに必要な設定は全ておこなわれています。複数のネットワークを使う構成であれば、ここでそのネットワークのサブネットや IP Pool を指定します。
次にルーティングの設定です。以下の概念図をご確認ください。
NSX-ALB のルーティングはおおよその構成では以下の設定をすれば動作します。
- データ通信用のデフォルトゲートウェイをアプリのロードバランサーのインターフェースに設定
- マネージメント通信用のデフォルトゲートウェイをマネージメントインターフェースに設定（Done）
NSX-ALB は SE が直接接続するネットワークへのパケット転送は自動で設定されます。多くの場合、NSX-ALB を展開した vSphere 上に TKG のノードはいるでしょうから、その TKG のネットワークを NSX-ALB できちんと設定すれば直接接続ネットワークにたいしてルーティングしてくれます。つまり「クライアント -> ロードバランサー -> k8s 上のアプリ」の通信はルーティング設定は必要ない場合が多いです。
一方、問題となるのは「k8s 上のアプリ -> ロードバランサー -> クライアント」という戻りのトラフィックです。図にあるように、通信を送り返すクライアントはインターネット上の様々な場所に存在します。そのような場合は「NSX-ALB が知らない通信は、このルーターに転送します」とデフォルトゲートウェイの設定をいれて上位のネットワーク機器にルーティングを実施してもらいます。この設定を NSX-ALB に設定します。
「Infrastracture -> Routing」と進んで、データ用のネットワークが属する dp-mgmt-32 のゲートウェイ（192.168.32.1）にたいして、Prefix 0.0.0.0/0 を設定しています。ルーティングの詳細は「Infrastracture -> Cloud」でも設定できますが、通常は設定不要です。
ルーティングの詳細は以下の記事を参照ください。
次に IPAM（IP Address Management の略）の設定をします。ここで、NSX-ALB のロードバランサーが動作するネットワークを指定するのですが、今回は全て同じネットワークを使うので「dp-mgmt-32」を指定しています。
IPAM の作成は「Templates -> Profiles -> IPAM/DNS Profiles」と進み、右上の Create ボタンから実施します。
次に Service Engine をどのように展開するかを「Service Engine Group」で設定します。
設定は「Infrastructure -> Service Engine Group」と進み、最初から作成されているデフォルト設定を編集します。今回は HA を Active/Standby にし、SE ごとに展開できる Virtual Service （k8sのL4LBやIngressが使うIP相当）を 10 から 100 に変更しました。性能が必要な場合は下のスペックを増やすか、NSX-ALB の上位ライセンス（Advanced）を購入して、SEあたりの Virtual Service 数を減らして展開する SE 台数を「N + M （buffer）」モードでスケールするようにしてください。
つぎに NSX-ALB の証明書の設定をします。この設定は必須ではありませんが、TKG から NSX-ALB を登録する際に証明書の参照などを実施しますので、システムが最初から持つものではなく自分で設定したものを使うことが推奨されます。今回は IP でアクセスするための自己証明書を作成します。
図にあるように「Administration -> Settings -> Access Settings」と進み、右上の編集ボタンをクリックします。すると左下の設定画面が現れますので、「SSL/TLS Certificate」にある既存のエントリを「x」ボタンで消し、右にある下矢印から「Create Certificate」で証明書を作成します。
図の右下のポップアップが現れますので、Name（好きなものでよい）、Common Name（IPを指定。今回は192.168.32.19）、Subject Alternate Name（IPを指定。今回は192.168.32.19）を指定し、残りの Algorithm などの項目はデフォルト値をそのまま使います。長く使う予定であれば「Days Util Expiration」は伸ばしてもよいかもしれません。
証明書を作成したら、ブラウザにサーバーの証明書の変更を適用させるためにブラウザの画面をリロードしてください。
最後に冒頭に設定したクラウド設定に、IPAM の設定を追加します。
以上で NSX-ALB の設定は完了です。
NSX-ALB SE は必要になったタイミングで作成されますので、現時点では構築されていないはずです。
Bootstrapの準備
TKG のマネージメントクラスタを作成/管理/利用するのが Bootstrap マシンの役目です。最初に説明したように Bootstrap マシンは個人の Windows や Mac に Docker Desktop をインストールして利用してもよいのですが、今回は「複数の管理者が同一の Bootstrap マシンを利用する」という想定で Ubuntu の仮想マシンを利用します。Ubuntu 上で Docker などを動かすので、メモリは最低2Gで、できれば4G以上を割り当ててください。今回は OS に Ubuntu 20.04 LTS を利用しています。
Bootstrap 構築の公式資料は先ほど紹介したドキュメントの後半になります。
ここでは以下の手順で作業を実施します。
- 必要なファイル（tanzu-cli とkubectl）をホスト上に配置
- ubuntu の root ユーザになる
- ssh key がなければ作成
- docker などのツールを準備
- kubectl をインストール
- tanzu cli のインストール
- tanzu cli のプラグインのインストール
以下にステップ5までの実行サンプルを記載します。
次にステップ6-7の実行サンプルを記載します。
以上で bootstrap の準備は完了です。
Management Cluster の構築
マネージメントクラスタは先程インストールした Tanzu CLI コマンドで構築します。具体的な構築方法は以下の2つのどちらかです。
- 構築用のユーザーインターフェースをたちあげて、パラメーターを入力しながら構築
- パラメーターファイルを用意して、それを指定して構築
今回は前者で作成しますが、構築時に指定したパラメーターがパラメーターファイルとして自動生成されますので、2回目以降はそれを少し変更してファイルベースで別のマネージメントクラスタを作成できます。
公式ドキュメントでは以下のページが該当します。
以下に構築ユーザーインターフェースを立ち上げるコマンド例を記載します。
これを実行すると、構築アプリが Docker として展開されます。指定されたアドレスに手元のPCなどのブラウザでアクセスすると、構築のためのブラウザアプリにアクセスできます。
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 公開鍵を指定します。K8s ノードへの SSH 接続は通常の操作では必要ないかもしれませんが、トラブルシューティング（サポート）を実施する際などには必要です。今回は bootstrap クラスタから SSH できるようにしたいので、bootstrapクラスタのSSH公開鍵（/root/.ssh/id_rsa.pub）を指定しています。
その次の設定項目はマネージメントクラスタの構成です。
ここではマスターノード/ワーカーノードのマシンサイズやノード数、クラスタ名や IP などを指定します。サイズやノード数は今回は最小値を指定していますが、本番構成時は右側の「Production 構成」を選んで、マシンサイズも処理を十分にこなせる大きさを指定してください。サイジングのガイドが必要なお客様は VMware にお問い合わせください。
この設定で気をつける必要があるのが「Control Plane Endpoint」です。これはマネージメントクラスタの代表 IP の設定なので、当然ながらマネージメントクラスタを展開するネットワーク（後で指定）のなかにあるアドレスで、衝突が発生しないものである必要があります。今回は左側にある「Control Plan End Point Provider」で NSX-ALB を指定しているので、NSX-ALB が提供するデータ用 IP が与えられます。右側のIP（オプション）を省いているので、NSX-ALBが空いているIPを自動で与えます。
この IP に NSX-ALB を使わない（つまり kube-vip を使う）場合は、dp-data-80 のネットワークをつかい、NSX-ALB で指定したプール（192.168.80.50 – 192.168.80.255）や、DHCP のレンジ （192.168.83.0 – 192.168.83.250） に衝突しないアドレスを指定してあげる必要があります。
次の設定項目は NSX-ALBの設定です。これはオプションですので NSX-ALB を利用しない場合は省略することができます。
画面上部にクレデンシャルと NSX-ALB の証明書を入力して「Verify」ボタンで接続してから、クラウド名やサービスグループを指定します。NSX-ALB の証明書は以下の図のように「Templates -> Security -> SSL/TLS Certificate」と進み、該当する証明書（今回は mycert）の右にあるダウロードボタンをクリックすることで取得できます。ここで得た値をコピペして貼り付けてください。
1つ前の図のTKG インストーラー側の設定に戻ると、Cloud Name や Service Engine Group Name には NSX-ALB で設定したものを指定してください。
そして、注意が必要なのは Workload VIP Network Name と Management VIP Network Name です。これは「NSX-ALB のマネージメントネットワークとワークロードネットワークを指定してください」ということではなく、「TKG 上に展開するワークロードの VIP （つまり L4LB と Ingress に割り当てる VIP）に、どの NSX-ALB のネットワークを指定しますか」および「TKG を展開するときのマネージメントに使う VIP （つまり k8s クラスタ自体が持つ VIP）に、どの NSX-ALB のネットワークを指定しますか」という質問です。
いずれにせよ今回は「dp-mgmt-32」しか存在しませんが、複数のネットワークを展開するときは注意してください。
次のページに「4. Metadata（メタデータ）」の設定がありますが、オプションなので飛ばします。
その次のページ（5. Resources）では、マネージメントクラスタの展開に使う仮想マシンフォルダー、データストア、クラスタやリソースプールの指定を実施します。お使いの環境に合わせて設定してください。
その次のページ（6. Kubernetes Network）では、マネージメントクラスタが使う vSphere ネットワークを指定します。今回であれば dp-mgmt-32 となります。その右の「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 の設定ページがありますが、今回は利用しないので特に設定変更せずにそのまま進めてください。
以上で設定は終了です。
設定確認ページの内容に問題なければ、デプロイボタンを押して構築を開始してください。ボタンを押すと以下の図のように構築の進捗状況とログが表示されます。
この構築でつまずきがちな箇所は2つあります。1つめは「Setup bootstrap cluster」で、Docker上のクラスタ構築アプリが正常に動作できていないと止まる場合があります。ネットワーク的な問題（たとえばHTTP Proxy などが存在する）でアプリを動かすためのコンテナイメージの取得に失敗したり、bootstrap の Linux のセキュリティ設定に起因して失敗している場合はここで止まります。
2つめのつまずきポイントは「Create management cluster」の項目で、NSX-ALB もしくは TKG インストール時の設定にネットワーク的な誤りがあると通信できずに構築が中断されてここで止まります。設定を見直して解決できない場合は切り分けのために NSX-ALB なしの最小構成でデプロイしてみるのがよいと思います。デプロイに成功すれば NSX-ALB の設定を疑ってください。NSX-ALB なしでもデプロイに失敗する場合は基盤ネットワークの DHCP や疎通性といった基本的な項目をチェックしてください。
もし今回の例のようにマネージメントクラスタの代表IP に NSX-ALB を利用していれば、このインストール中に IP を提供するために NSX-ALB SE（Service Engine） が展開されているはずです。
インストールに成功すれば上記のようにインストールステップの最後までグリーンチェックが表示されます。
最後に tanzu コマンドでマネージメントクラスタが構築できているか確認してみます。
上記のようにきちんと表示されれば構築に成功しています。
せっかくなので、NSX-ALB SE と Virtual Service（払い出したIP）の状態についても確認します。
vSphere 上で SE の仮想マシンが2台（active/standby）が作成され、それが NSX-ALB のコントローラー上でも確認できます。K8s に割り当てている IP アドレスも Virtual Service VIP という項目に「tkg-system-mgmt-1-4-0」というマネージメントクラスタ名を持つエントリがあることから確認できます（右下にある IP がプールのレンジから外れた 192.168.32.50 となっていますが、写真を取り忘れたので別の構成の写真を使ったためです。本来は 192.168.33.0 – 255 の間にあります）。
マネージメントクラスタの利用法については TKG 1.4.0 のライフサイクル管理の記事で扱います。ご拝読ありがとうございました。
