この投稿は、TUNA-JP Advent Calendar 2021 の 10日目です。
以前に、自宅ラボ vSphere 環境で Tanzu Community Edition（TCE）を展開した様子を投稿しました。
今回は、以前の投稿をふまえつつ、TCE 展開でつまずきを減らせそうな補足情報をお伝えしたいと思います。投稿の流れでタイトルに「kube-vip 編」とありましたが、今回は kube-vip は特に関係しません。
Advent Calendar 10日目なので 10個あげてみました。
Bootstrap 用のマシンについて
ちなみに、Tanzu CLI を利用する Bootstrap 用のマシンは、以下の理由で Photon OS の OVA を利用しました。
- docker がデフォルトでインストールされていてる。
- 誰でも入手しやすい。（ダウンロードにアカウント登録やログインが不要）
- せっかくなので VMware の Linux ディストリビューションを使う。
Docker コンテナ領域の容量
Photon OS 4.0 の OVAだと、VMDK サイズが 16GB です。は16GB の「/」（root）ファイル システムで、ここには OS も含まれます。この OVA ではない場合も、vSphere で VM を作成した際に、Linux VM はデフォルトの VMDK サイズが 16GB だったりするので、適当に VM を作成しているとうっかり不足しがちかなと思います。
Bootstrap Cluster / Management Cluster の作成で失敗すると、Bootstrap Cluster のコンテナやボリュームが残ってしまい、何度か繰り返しているうちに意外と容量枯渇します。
Tanzu CLI での処理で Bootstrap クラスタのコンテナが自動削除されなかった場合は、docker rm、volume volume rm などで手動削除します。
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES $ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a02af9f12324 projects.registry.vmware.com/tkg/kind/node:v1.21.2_vmware.1 "/usr/local/bin/entr…" 3 weeks ago Created tkg-kind-c68gv6qpp2q47r958jeg-control-plane $ docker rm a02af9f12324 a02af9f12324 $ docker volume ls DRIVER VOLUME NAME local 657897c948bc81e93c64174de20f549ad5c020ff464f3096154809002af04a5c $ docker volume rm 657897c948bc81e93c64174de20f549ad5c020ff464f3096154809002af04a5c
どうしても容量が空けられない場合は、VMDK ファイルを追加して /var/lib/docker にマウントするとよいかなと思います。
jq インストール
Photon OS は、jq が標準的なパッケージとして yum / tdnf のリポジトリ（photon-release）に用意されているので、インストールしておくと便利かなと思います。個人的には「kubectl -o jsonpath=～」よりも jq の方が使いやすいので・・・
（yq は残念ながら用意されてません）
Photon OS では、yum や dnf ではなく、tdnf で RPM をインストールします。
$ tdnf install -y jq
ちなみに yum も利用できますが、tdnf へのシンボリック リンクになっています。
$ ls -l `which yum` lrwxrwxrwx 1 root root 13 Oct 14 02:51 /bin/yum -> /usr/bin/tdnf
vimrc のカスタマイズ
これは Photon OS ならではの微妙なところですが、vi / vim でファイル編集する場合は、エディタの設定もあまりカスタマイズされていません。
リダイレクト、ヒアドキュメント、sed、ytt などで工夫していればそんなに問題ないかもしれませんが、ターミナル経由で vi 編集画面にコピー アンド ペーストができなかったので、私の環境ではとりあえず下記のようにクリップボード設定を追加しています。
$ echo 'set clipboard=unnamed,autoselect' >> ~/.vimrc
採用 OS / ディストリビューションについて
自分で手順で採用しておきながらですが、そもそも Photon OS は普段使い用を想定されていないので、RHEL や Ubuntu のような便利調整はされていません。
「とりあえずあるがままの手順を試してみる」のような事情がない場合は、普段利用しているディストリビューションや、macOS 等を利用するとよいかなと思いました。
Tanzu CLI 操作
補完機能の有効化
Tanzu CLI のサブコマンドはけっこう頻繁に変わりそうな予感がしており、補完機能を有効化しておくと便利かなと思います。
Photon OS のデフォルト シェルは bash です。そして Photon OS では、デフォルトで bash の補完機能が有効になっています。ちなみに RHEL などでは、bash-completion パッケージ（.rpm）の追加インストールが必要だったりします。
kubectl なども、あわせて設定しておくとよいかなと思います。
即時反映であれば・・・
$ source <(tanzu completion bash) $ source <(kubectl completion bash)
再ログイン時にも反映されるように設定するなら、.bash_profile か .bashrc にコマンドを追記しておきます。前回の投稿ではこちらを実施していました。
$ echo 'source <(tanzu completion bash)' >> $HOME/.bash_profile $ echo 'source <(kubectl completion bash)' >> $HOME/.bash_profile
「コンテナ / Kubernetes / Tanzu をこれから勉強したい、しかしそもそも Linux 操作に慣れていない」みたいな状況に遭遇することが多く、そういったシーンでも補完機能の有効化はお勧めです。
最近の CLI ツールではわりと補完機能に対応しているので、
クラスタの作成
環境のドメイン名（.local は NG）
最近の Linux ディストリビューションでは、名前解決の仕組み（system-resolved）の都合により .local ドメインが使いにくくなっています。
たとえば、Photon OS 4.0 で起動した TCE の Web UI で、.local ドメインの vCenter Server を指定するとエラーになります。
これは Bootstrap マシンでの名前解決の問題なので、下記のようなコマンドで .local ドメインを Search Domain として設定することで、外部 DNS サーバに問い合わせられるようになります。これで、Management Cluster と Workload Cluster の作成はできるはずです。
# resolvectl domain eth0 ～.local
それでも、TCE や TKG（Tanzu Kubernetes Grid）のノードとして利用される Photon OS と Ubuntu では system-resolved が採用されているので、.local ドメインはトラブルになりやすいので避けるべきかなと思います。
clusterconfigs の YAML ファイル名
前回の投稿では、まず Web UI からクラスタ作成の YAML を生成しました。
初回スタートでは（パラメータが多いこともあってか） Web UI を使うことが推奨されていますが、何度か作成することになったら、2回目以降は CLI のみで実施した方が効率的かなと思います。
mc の YAML ファイル名は自動生成なのですが、ちゃんとリネームして保持しておくとよいと思います。たとえば、8omj7epmp9.yaml のような名前で生成されるので、クラスタ名.yml などに変更しておきます。YAML ファイルの保存先は、$HOME/.config/tanzu/tkg/clusterconfigs ディレクトリ以外でも大丈夫です。
$ cp $HOME/.config/tanzu/tkg/clusterconfigs/8omj7epmp9.yaml $HOME/.config/tanzu/tkg/clusterconfigs/tcemgmt.yml
クラスタ名の指定
YAML の CLUSTER_NAME はそのままで、tanzu cluster create のパラメータで、ワークロード クラスタの名前を指定することも可能です。
$ tanzu cluster create wlc-02 -f ./wlc-01.yml
ただ、クラスタごとに 仮想マシン フォルダやリソース プールなども変更することが多いと思います。個人的には、パラメータはすべて YAML に記載しておくとよさそうかなと思います。tanzu cluster create では、-f で YAML ファイルだけ指定します。
$ tanzu cluster create -f ./wlc-02.yml
ノードのリソース割り当て
前回の投稿では、Management Cluster のノード（つまり VM）へのリソース割り当て（Web UI では Instance Type）を、「small（2 cpu、ram 8GB）」にしています。そして、Management Cluster の YAML をコピーして作成した Workload Cluster も同じスペックです。（しかも、どちらも 1ノードだけ）
しかし、このスペックのクラスタで何か検証しようとすると、結構リソース不足になります。最低でも medium にしておいた方が無難かなと思います。
YAML を直接編集する場合は、small や medium ではなく、数値で設定します。
- VSPHERE_CONTROL_PLANE_MEM_MIB: "4096"
- VSPHERE_CONTROL_PLANE_NUM_CPUS: "2"
- VSPHERE_WORKER_MEM_MIB: "4096"
- VSPHERE_WORKER_NUM_CPUS: "2"
複数環境へのクラスタ作成
TCE で複数のクラスタを作成することがあるはずです。いろいろな構成でクラスタを作成したり、vSphere / Azure といった別クラウドにクラスタを作成したり・・・
tanzu login を実行すると、Management Cluster を切り替えられます。しかし、環境変数、各種 CLI のバージョン、kubeconfig など他にも切り替えたいものがいろいろと存在します。
そこで、私の環境ではためしに Management Cluster ごとに OS ユーザを作成して、OS ユーザごと切り替えて使い分けてみています。各種バイナリも /usr/local/bin あたりではなく、TANZU_BIN_PATH 環境変数などで $HOME/bin（~/bin）にインストールしています。
使い方にもよると思いますが、Management Cluster あたりの Workload Cluster が増えてくると結局混乱してきました。次は vCeneter 単位や IaaS Provider（vSphere、Azure）単位ぐらいで分けてみようかなと思いつつあります。clusterconfigs YAML の雰囲気がそこそこ異なるので・・・
以上、TCE on vSphere の Tips についてでした。
明日の Advent Calendar は、@iwaseyusuke さんです。
