ではいよいよ、Tanzu Kubernetes Grid Service(TKGS)を有効化してみましょう！

Tanzuエディションについて

さっそく、「ワークロード管理」に移動してみると・・・、

「Tanzu エディションライセンスをお持ちですか？」と聞かれます。

「はて、Tanzuエディションってなんぞ？」と思う方もいらっしゃるかもしれません。実はこのTanzuエディション、vSphere 7 Update 1から導入された概念なんです。(VMware Blog)

Day3で、Tanzuポートフォリオについてご紹介しましたが、以前は各Tanzu製品を個別に買う形となり、窓口も違うため、購入すること自体がややこしくなっていました。Tanzuエディションでは、企業の導入フェーズに合わせて4つのペルソナに分類し、顧客層を基準としたシンプルなパッケージプライスとなった訳です。
それぞれのエディションがどういうものか、簡単に説明します。

Tanzu Basic : まずはオンプレでK8sを導入しようと思う企業向けで、vSphere上のインフラのみが対象です。今回紹介した、TKGとvSphere with Tanzuが利用可能です。具体的な価格を私は言えませんが、最もお手頃価格となっているとのことです。また、vSphere 7 Ent+とのバンドルとして、またはvSphere 6.7u3にデプロイするアドオンとしてライセンスを受けることができます。
Tanzu Standard : マルチクラウド向けにスケール管理するためのパッケージ。TKGがサポートする他のプラットフォーム(2020年12月17日時点では、AWS(EC2)と、VMC on AWSと、Azure)が対象に加わってきます。また、Tanzu Mission Controlの機能の一部が利用可能であり、Prometheus/GrafanaなどOSSのサポート対象も拡大されます。
Tanzu Advanced : DevOpsプラクティスを構築するためのパッケージとして、Tanzuポートフォリオの多くの製品が同梱されてくる予定となっています。詳細は、今後発表予定とのこと。
Tanzu Enterprise : Tanzuポートフォリオをフル活用できる最上位パッケージ。自動化されたアプリケーションプラットフォームで開発者のエクスペリエンスとベロシティを向上させたい場合に最適なソリューションです。こちらも詳細は、近日発表予定とのこと。

こちらによると、他のVMware製品同様、60日の評価利用が可能です。さらに、評価期間が終了しても、評価期間中に作成したTKCは引き続き利用可能（構成変更は不可）なようなので、安心して使ってみましょうｗ

基本情報を入力して・・・、「登録」。
はい、これで、ワークロード管理の初期画面が現れました！

HAProxyのCA Certの取得

「開始する」に進みたいところですが・・・、
Day18で、HAProxyを作成した訳ですが、その際、CAを放置したのを覚えてますでしょうか？この後の設定の際に、HAProxyのCA証明書が必要になるので、事前に情報を取得しておく必要があります。（私はそれを知らずに、この後の工程で証明書を求められ、有効化作業を最初からやり直すハメにあいました・・・）

そして、取得できる場所が分かりづらかった。haproxyの「設定の編集」を開き・・・

「仮想マシンオプション」の詳細を開き・・

「構成パラメータ」の「設定の編集...」をクリックし・・

「guestinfo.dataplaneapi.cacert」にありましたｗ　階層が深いっ！

さらにもう一手間必要で、「echo "(取得した文字列をペースト)" | base64 -d」で、Base64をデコードしてあげる必要があります。

ワークロード管理の有効化

ではいよいよ、「開始する」を押します！

ステップ1. vCenterとネットワークの選択。NSX-Tを導入してないため、特に選択肢はないです。「次へ」

なお、ここでDay18で作成した「コンテンツライブラリ」がないと、先に進めませんでした・・

2ではvSphereクラスタを選択します。選んで「次へ」

3は、ControlPlaneのサイズ。本番運用だと「中」以上がオススメですが、検証用途なので「極小」にしてみます

4はストレージの選択ですね。事前に作成したポリシー選んで「次へ」

5はLB情報を入力。ここで、事前に設計したIP情報や、作成したhaproxyや、CAが必要になります！
(2020年12月21日修正) 以下の設定で作り直しました。

名前 : haproxy-lb (DNS名。小文字a-z、数字0-9、-(ハイフン)のみが使用可能とのこと)
タイプ : HA プロキシ　（現時点ではこれしか選べない。。）
データプレーンAPIのアドレス : 172.18.0.45:5556 (※haproxyのIPアドレス:ポート)
ユーザー名＆パスワード : (登録したものを入れる)
仮想サーバのIPアドレス範囲 : 172.18.0.208-172.18.0.222 (事前に設計したVIPのレンジ内で指定)
サーバ認証局 : (先ほど取得したCA Certをコピペ)

6は管理ネットワークです。「開始IPアドレス」から5IPsのアドレスを、Supervisor ControlPlane VMが使用するため、バッティングしないようご注意下さい。 (2020年12月21日追記) ネットワークは「DSwitch-VM Natwork」とした

7は、ワークロードネットワークです。ここはちょっと紛らわしくて、最初にあるサービスとは、**K8sのServiceリソース**のことです。つまり、**コンテナネットワーク**です。特に最初から入っている値のままで良いでしょう。DNSサーバは、k8sのコンテナネットワークで良く使われる「8.8.8.8」を指定してみます。続いて、ワークロードネットワークを「追加」

ワークロードネットワークには、TKCのControlPlaneやWorkerのVMにアサインされるIPを指定していき、「保存」 (2020年12月21日追記) 以下の設定に作り直しました。

Name : network-1 (そのまま放置)
Port Group : DPortGroup-workload
Gateway : 172.18.0.1
Subnet : 255.255.255.0
IP Address Range : 172.18.0.129-172.18.0.191

すると、このように情報が埋まります。このネットワークを選択して「次へ」

8は、コンテンツライブラリを追加して、「次へ」

9は確認画面。今までの設定が問題ないことを確認し、「完了」！　さぁ、どうだ・・・？

なんか画面下のタスクが色々と動き出した・・・結構時間がかかります。時折、「OVFテンプレートのデプロイ」や「リモートファイルのダウンロード」で、「ステータス404でHTTP通信を完了出来ませんでした。」とエラーが出てドキッとしますが、リトライしてなんとか処理してくれているようです。

20分位して、Supervisor ControlPlaneVMのデプロイは一通り終わったように見えますが、引き続きSupervisor Namespaceの設定をなにかやっているようです。

さらに10分位して、「名前空間」メニューが使用可能となり、クラスタが「実行中」のステータスとなれば完了です！「完了」を押してからのトータル待ち時間は、30分ちょいといったところでした。

#リソース魚拓
さて、今までのTKG環境に加え、今回、「Namespaces」というリソースプールが作成され、3台の「SupervisorControlPlaneVM」が作成されました。同居させるとどうなるかな？
###SupervisorControlPlaneVM
Tinyでも結構消費しますね！VM毎にバラツキがあるのが興味深いです。

CPU : 500MHz 〜 1GHz
Mem : 1 GB 〜 2GB
Storage : 13 GB 〜 15 GB

###Namespaces
Supervisor Clusterの分は、カウントしていなさそうですね。ほぼリソースなし

###HAProxy
CPUとメモリはほぼ0！省エネ設計ですね

###Nested ESXi
おぉ、結構使ってきましたね。。特にメモリが。でも、まだ入るな。SV ControlPlane VMが居るところが多めになる。

CPU : 1GHz 〜 1.5GHz
Mem : 21GB 〜 27GB

###Nested vCenter
使用メモリが90GBを超えてきました。

###物理 vCenter
ざっくりいうと利用率50%といったところでしょうか。TKGとvSphere w/ Tanzuを組み合わせると、やはりメモリが2台では収まらないですね。

ちょっと長くなってしまいましたね。vSphere with Tanzuの方が、導入するまでが大変な印象です。
明日は、実際に使ってみたいと思います！