貧弱な Nested 環境で TKG 1.5.1 をデプロイする場合の注意点

Tanzu Kubernetes Grid (TKG) 1.5 & 1.5.1 が 2022年02月17日 にリリースされました。

https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.5/rn/vmware-tanzu-kubernetes-grid-15-release-notes/index.html

私の周りでは、今話題の Tanzu Application Platform (TAP) v1.0.1 と互換性があるということで、ざわついており、TAP のお試し環境のためにもトライしています。

しかし、手元のラボ環境があまりにも貧弱過ぎて、詰まったところがあったので、備忘を含めて記載します。そのため、"普通に" ラボ環境をお持ちの人にも、広く有益な情報とは言えないので、ご注意ください。

## 概要

TKG は、vSphere のみならず、AWS や Azure などの Native な Public Cloud を始め、果ては Edge といったリソースが非常に限られた環境でも動作します。

しかし、いくら省リソースな製品とは言え、さすがに限度というものがあります。私のラボは、Nested の vSphere 環境かつ、ストレージもめちゃくちゃ遅いという、とても貧弱な環境です。そのため、こんな環境で TKG を構築しようとしたら、さすがに限界があったのか、いくつか詰まってしまいました。

その時、色々と試行錯誤し、なんとか環境構築までは行ったので、その内容を記載します。

## 詰まったところ

### 1つ目: Avi SE のデプロイでタイムアウト

Kubernetes (K8s) の Service (type=LoadBalancer) を提供するため、TKG ではいくつかの LB 製品が利用できます。特に要件がなければ、Kube-vip で構成してしまうのが、もっとも楽だと思います。

しかし、私は、NSX Advanced Load Balancer との連携機能 Avi Kubernetes Operator (AKO) に興味があったので、これを選択しました。具体的にどんな構成なのか？どんなステップが必要なのか？は、こちら↓の VMware Japan Blog の記事が、非常に参考になります。

https://blogs.vmware.com/vmware-japan/2021/10/tkg-1-4-0-install.html

で、結局のところ、1つ目として、どこで詰まったのか？と言うと、TKG のインストーラー UI から、[DEPLOY] ボタンを押して、実際のデプロイを押して、しばらく待っていると、タイムアウトしてしまう、というものでした...

こんな↓感じで、Avi SE (LB の実体 VM) はデプロイされるのに、

![Screen Shot 2022-03-20 at 14.43.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/245234/ac259561-bbaf-8f1e-8652-252ca412435d.png)

TKG の Node が展開されれず、タイムアウトしました...

#### 対処

どうやって先に進んだか？と言うと、早い話が、リトライしました。

どうやら、あまりにも私のラボが貧弱なので、Avi SE を展開して、Control Plane (K8s における Master Node) に API アクセスできるまでに、あまりにも時間がかかり過ぎて、TKG のインストーラーがタイムアウトしてしまう、というお粗末なことが原因だったようです。

Avi SE も、使われないまま放置すると、自動で削除される設定になっているため、これが消されないうちに、もう一度、全く同じ設定内容で、TKG のインストーラーを叩くことで、先に進むことができました。

### 2つ目: TKG の Node デプロイでタイムアウト

1つ目の対処を行なったところ、Control Plane (K8s における Master Node) が立つようになりました。

![Screen Shot 2022-03-20 at 14.45.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/245234/eacd06ba-b7ad-0604-319f-cffa0149130d.png)

...が、Worker Node の作成途中で、またタイムアウトしました...

#### 対処

こちらもリトライすれば行けるだろう！と思ったのですが、それでもダメでした。そこで、そもそものタイムアウト時間を伸ばす、という手を使いました。

具体的には、こちら↓の公式ドキュメントにある `NODE_STARTUP_TIMEOUT` を、思いっきり大きな値 `60m` にして、貧弱なラボ環境でも、TKG のインストーラーに待って貰えるようにしました。

https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.5/vmware-tanzu-kubernetes-grid-15/GUID-tanzu-config-reference.html

| Variable | Description |
| ---- | ---- |
| NODE_STARTUP_TIMEOUT | Optional, set if you want to override the default value. The default value is 20m. |

この値を差し込む方法としては、TKG のインストーラーから [DEPLOY] ボタンを押す直前に、インストーラー画面に、下記のようなコマンドが表示されると思います。

```sh
tanzu management-cluster create --file /root/.config/tanzu/tkg/clusterconfigs/86g4ijjilf.yaml -v 6
```

この場合は `/root/.config/tanzu/tkg/clusterconfigs/86g4ijjilf.yaml` を対象ファイルとして、vi などで開き、`NODE_STARTUP_TIMEOUT` の値をいじります。

```
vi /root/.config/tanzu/tkg/clusterconfigs/86g4ijjilf.yaml
# ... (snip)...
NODE_STARTUP_TIMEOUT: 60m
# ... (snip)...
```

設定を保存したら、TKG のインストーラー画面に戻り、[DEPLOY] を押せば、タイムアウト時間が伸びているので、無事に構築できました。

## まとめ

結局何だったの？と言うと、結果的には、私のラボで (おそらく) ストレージが遅過ぎて、Avi SE や TKG の Node といった VM のデプロイに時間がかかり、タイムアウトしてしまった、ということでした。

さすがに普通のマシン環境では、なかなかこんなことは起きないだろうとは思いますが、同じように貧弱な環境で縛りプレイを楽しんでいる方がいれば、参考にしていただければと思います。