2022 年3 月に VMware Tanzu Kubernetes Grid 1.5 （以下TKG 1.5）がリリースされました。TKG 1.5 では、Tanzu Application Platform のインストールへの対応や、vSphere 上でのWindows クラスタのサポートなどの新機能が含まれます。
この記事では、ロードバランサーとしてVMware NSX Advanced Load Balancer を使用して、TKG 1.5.1 をvSphere上にシンプルなネットワークで構成する手順を紹介します。なお、本記事の目的はなるべく簡単にTKG をデプロイすることに焦点を当てているため、簡易的な手順となっております。
デプロイ手順はTKG 1.4.0 のデプロイの手順とほぼ同じです。以下のTKG 1.4.0 の展開に関する記事も併せてご参照ください。
vSphere環境への TKG 1.4.0 with NSX-ALB の簡易展開手順
また、3 月末にTKG 1.5.2 がリリースされました。こちらのリリースではノードプールに関するバグ修正などが行われており、TKG 1.5.1 とデプロイ手順は変わらないため、デプロイする際はTKG 1.5.2 の利用を推奨します。
今回の構成
TKG 1.4.0 の記事とは異なり、 今回はトラフィックを受けるVIP （Virtual IP）用のVLAN と、管理系VM &Kubernetes クラスタ用のVLAN を1 つ、計2 つ用意しています。
デプロイの流れとしては、ブートストラップマシン（管理クラスタのデプロイ用の環境）を用意し、vSphere やvSphere 上に展開するNSX ALB の準備、その後ブートストラップマシンから管理クラスタをデプロイし、最後にワークロードクラスタをデプロイします。
今回使用したコンポーネントのバージョン情報
- vCenter Server 7.0U2b (Build 17958471)
- ESXi 7.0U2a (Build 17867351)
- vCenter やESXi のバージョンは6.7U3 以降であればOK です。
- NSX Advancer Load Balancer (Avi Controller) 20.1.6
- NSX Advanced Load Balancer のバージョンが21.x の場合ワークロードクラスタの正常なデプロイが完了しないため、TKG 1.5 時点ではバージョン20.1.6 または20.1.3 をご利用ください。
vSphere 以外に最低限必要なリソース
- Avi Controller (8vCPU, 24 GB RAM, 128 GB Disk)
- Avi Service Engine * 2 (1 vCPU, 2 GB RAM, 15GB Disk)
- デプロイされるKubernetes クラスタ
- 最小限の構成では管理クラスタとワークロードクラスタ1 組ずつ、それぞれコントロールプレーンとワーカーノード1 台ずつなので、計4 VM展開となります。また、最小のVM サイズであるSmall で展開した場合の各VM のスペックは2vCPU, 4GB RAM, 20GB Disk ですが、これも目的に合わせて調整してください。
- クラスタの各VM がIP アドレスを取得するためのDHCP サーバーが必須なことに注意してください。
バイナリの取得先
- Tanzu CLI やKubernetes OVAなど
- NSX ALB (上記Customer Connect にあるリンクからアクセスできます)
ブートストラップマシンの準備
下記ドキュメントを参照しながら進めます。
最低6 GBのRAMと2 コア を備えたブートストラップマシンに各種ツールをインストールしていきます。
・Docker のインストール
ブートストラップマシンがLinux またはMacOS の場合、non-root ユーザーをdocker ユーザーグループに追加し、non-root ユーザでdocker を管理できるように設定しておきます。
https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user
・NTP 同期
その他、環境によっては必要な設定がありますので、詳細はドキュメントを確認してください。
・CLI ツールの準備
Tanzu CLI、kubectl、Carvel ツール群（ytt、kapp、kbld、imgpkg） をブートストラップマシンで使えるように準備します。Tanzu CLI とkubectl は上述したCustomer Connect からダウンロードでき、Carvel はダウンロードしたTanzu CLI のフォルダに含まれます。
ドキュメントに従ってインストールしていくと、最終的に下記のようになります。
[root@localhost ~]# tanzu version
version: v0.11.1
buildDate: 2022-02-14
sha: 4d578570
[root@localhost ~]# kubectl version
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.5+vmware.1", GitCommit:"8ef4fc5015d7c770c6ac367fcb1d13ed4e99d974", GitTreeState:"clean", BuildDate:"2021-12-17T23:12:22Z", GoVersion:"go1.16.12", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.5+vmware.1", GitCommit:"8ef4fc5015d7c770c6ac367fcb1d13ed4e99d974", GitTreeState:"clean", BuildDate:"2021-12-17T23:06:27Z", GoVersion:"go1.16.12", Compiler:"gc", Platform:"linux/amd64"}
[root@localhost ~]# ytt version
ytt version 0.35.1
[root@localhost ~]# kapp version
kapp version 0.42.0
Succeeded
[root@localhost ~]# kbld version
kbld version 0.31.0
Succeeded
[root@localhost ~]# imgpkg version
imgpkg version 0.18.0
Succeeded
また、SSH 鍵ペアを作成していないのであれば、ssh-keygen コマンドで作成しておきます。詳細はドキュメントをご参照ください。
vSphere 側の準備
下記ドキュメントを参考に、vSphere 側でTKG をデプロイする準備を進めます。
ESXi ホストは1 台からでもOK ですが、Kubernetes クラスタが収容できるように十分なリソースを確保します。
次に、Kubernetes クラスタのベースイメージとなるテンプレートを作成します。Tanzu CLI やkubectl と同様、Customer Connect からイメージをダウンロードし、それをvSphere にインポートした後にテンプレート化すればOK です。この手順はTKG 1.4.0 のブログを参照してください。ただし、管理クラスタのイメージのバージョンは必ず最新のバージョンであるUbuntu v20.04 Kubernetes v1.22.5 またはPhoton v3 Kubernetes v1.22.5 を使用します。今回の構成ではUbuntu v20.04 Kubernetes v1.22.5 を使いました。
なお、ドキュメントには権限の設定について記載されていますが、今回はvSphere の管理者権限をTKG に渡します。本番環境では非推奨となりますので、権限設定は必要に応じて実施してください。
NSX Advanced Load Balancer のデプロイ
NSX Advanced Load Balancer (以下NSX ALB) はソフトウェアで提供されるロードバランサーです。Kuberentes のコントロールプレーンへのアクセスを提供する役割と（こちらはkube-vip でも可能）、アプリケーションを外部公開するためのKubernetes のロードバランサーリソースとしての役割（kube-vip 不可）の2 つの役割を主に持ちます。コンポーネントとしては大きく3 つあります。1 つはAvi Controller と呼ばれるコントロールプレーン、2 つ目にAvi Service Engine と呼ばれるトラフィックを受けるデータプレーン、3 つ目にAvi Kubernetes Operator (AKO) と呼ばれる、Kuberenetes のオペレーター(Kubernetes のリソースをALB のオブジェクトに変換して繋ぐ存在) があります。実体としては、Controller とService Engine はVM ですが、AKO はKubernetes クラスタで実行されるPod です。
NSX ALB の準備は下記の流れで進めていきます。
- Controller のデプロイと初期セットアップ
- (オプション) ライセンスの変更
- NTP の設定
- 証明書の作成と割り当て
- クラウドの設定（vCenter との連携、Service Engine の管理ネットワークの設定、VIP 用のIPAM Profile の作成と割り当て）
- VIP のIP プールの作成
- VIP のデフォルトゲートウェイの設定
- Service Engine Group の設定（Service Engine のデプロイ先の指定）
1. Controller のデプロイ
Controller をOVA からデプロイした後、Service Engine とAKO はTKG のデプロイプロセスの中で自動的に展開されるため、重要なのはController のデプロイです。Controller のOVA はTanzu CLI 入手先のCustomer Connect にあるリンクで飛ぶことができるNSX ALB Cloud Services から取得できます。
ダウンロード後、OVA ファイルをvSphere 上に展開し、パワーオンします。展開時のController のテンプレートのカスタマイズ部分はController のIP アドレスとサブネットマスク、デフォルトゲートウェイの入力だけで、Sysadmin login authentication key 以降は空欄でOK です。
パワーオン後サービスが立ち上がるまで5 分程度待ってから、入力したIP アドレスにアクセスすると初回セットアップの流れとなります。まずはadmin ユーザーを作成します。
パスフレーズは任意です。バックアップ用に使います。DNS やDNS 検索ドメインを入力し、Email/SMPT はここではNone を選択します。テナント設定はデフォルトで構いません。
初回セットアップの完了後に最低限必要なタスクの流れは以下の通りです。
2. (オプション) ライセンスの変更
評価ライセンスではなく、Essentials ライセンスを使う場合はこのタイミングで変更します（後述）。
3. NTP の設定
デフォルトで登録されているNTP サーバーはすべて削除したうえで新規で登録します。
4. 証明書の作成と割り当て
Avi Controller の証明書を新たに作成し既存のものから差し替えます。証明書のName は任意ですが、Common Name とSAN はIP アドレスを入力します。FQDN でももちろんOK ですが、その場合この後のTKG の設定ではController のIP アドレスでなくFQDN を入力することに注意してください。
画面更新後、Controller の証明書が置き換わっていることを確認できます。
5. クラウドの設定
NSX ALB の「クラウド」とはロードバランサーを展開する環境を指します。NSX-T との連携などもできますが、ここではvCenter と連携します。デフォルトで定義済みのDefault-Cloud はNo Orchestrator (vCenter などとの連携なし) なので、これをまずはvCenter と連携するように設定をしていきます。
vCenter とうまく接続できたのであればデータセンター名が見えるはずなので、それを設定します。他はデフォルトで構いません。
ネットワーク設定では、Management Network にvSphere のポートグループを設定します。標準スイッチでも分散スイッチでも構いません。このポートグループにはService Engine の管理側インターフェースが接続されます。Template Service Engine Group はDefault-Group を選択します（後で設定します）。IP Address Management for Management Network ではService Engine の管理インターフェースに振るIP アドレスを設定します。IP プールを定義することもできますが、ここではDHCP を選択しています。
設定が完了したら保存し、もう一度Default-Cloud を設定します。今度はIPAM Profile の設定をします（vCenter との接続が完了していないとポートグループが見えないため、設定を後回しにしました）。IPAM Profile では、Service Engine が持つ VIP、すなわち外部からのトラフィックの受け口となるネットワークを設定します。IPAM Profile に先ほど設定したDefault-Cloud とVIP のための適切なポートグループを入力して、設定が完了したら保存します。
最後に、Default-Cloud のステータスが緑になっていることを確認します。
6. VIP のIP プールの作成
IPAM Profile ではポートグループ名しか指定していないため、まだVIP にどのIP アドレスを振るかが決まっていません。そのため、次にIPAM Profile で指定したポートグループに対して、IP プールを作成します。DHCP で割り当てても構いませんが、今回はIP プールからVIP のアドレスを振っています。
7. VIP のデフォルトゲートウェイの設定
Gateway Subnet を0.0.0.0/0、Next Hop にVIP のデフォルトゲートウェイとして適切なIP アドレスを入力します。
8. Service Engine Group の設定
Service Engine Group ではService Engine の設定が定義されています。ここではDefault-Group の設定を変更します。Basic Settings はデフォルトで構いませんが、Tanzu 用のEssentials ライセンスならばHA モードはLegacy HA になります。Advanced 設定の方ではService Engine がデプロイされるべきクラスタ、ホスト、ストレージを設定します。今回はクラスタとストレージを指定し、ホストは指定していません。
以上でNSX ALB の設定は完了です。
なお、今回はデフォルトで入っている60日の評価ライセンスを使っています。必要に応じて、ライセンスの変更や、Service Engine VMの事前デプロイを行ってください（事前デプロイはEssentials ライセンスでは不可なので一度Enterprise に切り替える必要があります）。事前デプロイは、必須ではありませんが、時間のかかるService Engine VM の作成を先に済ませておくことで、内部的なタイムアウトを防ぐ目的があります。詳細は下記ドキュメントを参照してください。
補足：ライセンスの変更について
Essentials ライセンスではTKG のLB の機能の提供だけを目的としているため、Enterprise ライセンスと比較して機能差があります。したがって、Enterprise からEssentials ライセンスに変更しようとしたときに、Enterprise で有効化した機能が原因でEssentials に変換できない場合があります。デプロイ直後にEssentials に変更するか、変更できなかった場合はController からshow configuration audit tier essentials コマンドで原因となっている機能を確認し、修正しましょう。Service Engine Group のLegacy HA Mode の設定や、Enterprise ライセンス適用中におけるController の証明書の作成が原因となることが多いです（後者の場合証明書を一度削除してEssentials ライセンスを適用し、その後再作成&割り当てで解決します）。
TKG デプロイ前の最終確認
- ブートストラップマシンの準備
- docker のインストールはしましたか？
- NTP の設定はしていますか？
- Tanzu CLI やkubectl、Carvel ツール群をすべてインストールしましたか？
- SSH 鍵ペアは準備しましたか？
- vSphere の準備
- vSphere にKubenetes クラスタのイメージをインポートしてテンプレート化しましたか？
- NSX ALB の準備
- NSX ALB の設定は適切ですか？
- 特にService Engine のVIP と管理ネットワークは、DHCP を使っていない場合どちらもIP プールを作成する必要があります。DHCP アドレスプールの枯渇には注意。潤沢に用意しましょう。
- デフォルトゲートウェイの設定も忘れないようにしてください。
- NSX ALB の設定は適切ですか？
管理クラスタのデプロイ
ブートストラップマシン、vSphere、NSX ALB いずれの準備も完了したら、いよいよTKG 管理クラスタのデプロイに進みます。基本的にはTKG 1.4.0 と変わりません。
[root@localhost ~]# tanzu management-cluster create --ui
Validating the pre-requisites...
Serving kickstart UI at http://127.0.0.1:8080
127.0.0.1:8080 でインストーラーUI にアクセスし、適切にパラメータを入力していきます。
管理クラスタのスペックを選択します。今回はコントロールプレーン1 台（Development）、インスタンスタイプはSmall の最小構成としています。
また、ここでコントロールプレーンにアクセスするエンドポイントを選択します。今回はkube-vip ではなく、NSX ALB にその役割を担わせ、事前に設定したVIP のIP プールからエンドポイントのIPアドレスを払い出すため、CONTROL PLANE ENDPOINT は空欄にしています。
Controller の証明書はController にアクセスして取得します。
TKG VM が収容されるフォルダやストレージ、クラスタ、（有効化していれば）リソースプールを入力します（スクリーンショットではリソースプール名をマスクしています）。
なお、ここでプロキシの設定を行うこともできます。必要に応じて設定してください。
Kubernetes ノードのOS イメージを選択します。表示されない場合、vSphere 側にイメージのテンプレートが存在するかを確認してください。
必要に応じてCEIP (Customer Experience Improvement Program) にチェックを入れます。
設定のレビュー後、管理クラスタのデプロイに進みます。UI からデプロイの進捗を確認することができます。
デプロイが完了したら、CLI からも状況を確認してみましょう。ノードの状態がReady になっていればOK です。
[root@localhost ~]# kubectl config use-context tkg-mgmt-admin@tkg-mgmt
Switched to context "tkg-mgmt-admin@tkg-mgmt".
[root@localhost ~]# kubectl get node NAME STATUS ROLES AGE VERSION tkg-mgmt-control-plane-24zjg Ready control-plane,master 8m v1.22.5+vmware.1 tkg-mgmt-md-0-6786c74dd9-j6v2f Ready <none> 7m2s v1.22.5+vmware.1
管理クラスタのデプロイ完了後、念のためNSX ALB が機能しているかを確認しておきましょう。
[root@localhost ~]# kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml deployment.apps/hello-world created [root@localhost ~]# kubectl get pod NAME READY STATUS RESTARTS AGE hello-world-6df5659cb7-5vcw7 1/1 Running 0 49s hello-world-6df5659cb7-9mbck 1/1 Running 0 49s hello-world-6df5659cb7-g2p4p 1/1 Running 0 49s hello-world-6df5659cb7-sff6b 1/1 Running 0 49s hello-world-6df5659cb7-wn9sj 1/1 Running 0 49s [root@localhost ~]# kubectl expose deployment hello-world --type=LoadBalancer --name=my-service service/my-service exposed [root@localhost ~]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 100.64.0.1 <none> 443/TCP 17m my-service LoadBalancer 100.64.169.125 10.198.104.43 8080:32436/TCP 5s [root@localhost ~]# curl 10.198.104.43:8080 Hello Kubernetes!
一通り確認したら、コントロールプレーンのIP アドレスが変わらないように、DHCP 予約を設定します。詳細は下記をご参照ください。
ワークロードクラスタのデプロイ
最後に、デプロイした管理クラスタを使ってワークロードクラスタをデプロイします。管理クラスタデプロイ時にUI からパラメータを入力しましたが、そのパラメータ群は構成ファイルとして ~/.config/tanzu/tkg/clusterconfigs/ に出力されており、それを編集してワークロードクラスタのためのパラメータを構成します。今回は構成ファイルの中のクラスタ名をtkg-wkld (CLUSTER_NAME: tkg-wkld) に変更し、tkg-wkld.yaml というファイルを作成しました。
なお、細かいパラメータの編集については下記ドキュメントを参照してください。クラスタ名さえ変更すれば作成はできます。必要に応じてノードのスペックやノード数を変更します。
管理クラスタデプロイ後にtanzu cluster コマンドが認識されない場合、tanzu plugin sync でプラグインをダウンロードします。
[root@localhost ~]# tanzu cluster create --file tkg-wkld.yaml Validating configuration... Warning: Pinniped configuration not found. Skipping pinniped configuration in workload cluster. Please refer to the documentation to check if you can configure pinniped on workload cluster manually Creating workload cluster 'tkg-wkld'... Waiting for cluster to be initialized... cluster control plane is still being initialized: WaitingForControlPlane cluster control plane is still being initialized: ScalingUp Waiting for cluster nodes to be available... Waiting for addons installation... I0219 23:34:51.640308 2142132 request.go:665] Waited for 1.184335606s due to client-side throttling, not priority and fairness, request: GET:https://10.198.104.45:6443/apis/system.antrea.io/v1beta1?timeout=32s Waiting for packages to be up and running... Workload cluster 'tkg-wkld' created
デプロイが完了したら、kubeconfig ファイルを取得し、管理クラスタと同様正常にデプロイされているかを確認してください。必要に応じてロードバランサーリソースが正常にデプロイできるかも確認します。
[root@localhost ~]# tanzu cluster kubeconfig get tkg-wkld --admin Credentials of cluster 'tkg-wkld' have been saved You can now access the cluster by running 'kubectl config use-context tkg-wkld-admin@tkg-wkld' [root@localhost ~]# kubectl config use-context tkg-wkld-admin@tkg-wkld Switched to context "tkg-wkld-admin@tkg-wkld". [root@localhost ~]# kubectl get node NAME STATUS ROLES AGE VERSION tkg-wkld-control-plane-jf6ll Ready control-plane,master 9m36s v1.22.5+vmware.1 tkg-wkld-md-0-7b548d9d7d-n6w2b Ready <none> 9m19s v1.22.5+vmware.1
最後に、管理クラスタと同様、コントロールプレーンのDHCP 予約をして、TKG 1.5.1 のデプロイは完了です。
まとめ
今回はNSX Advanced Controller のデプロイを中心に、TKG のデプロイについて解説しました。一度管理クラスタのデプロイが完了すれば、ワークロードクラスタのデプロイはKubernetes でアプリケーションを展開するがごとく簡単にデプロイすることができます。是非ともお試ししてみてください。
