はじめまして。VMware の伊藤です。Tanzu 製品のプラットフォームアーキテクトとして働いており、開発と運用双方の経験があります。この記事では TKG 1.4.0 のマネージメントクラスタ（管理用クラスタ）を AWS に構築する手法の概要を説明します。
OSS の k8s は Day2 操作 （アップグレードや台数変更といった構成変更） の難易度が高く、k8s の数が増えると管理コストも線形に増大してしまいます。そのため、多くの商用環境ではマネージドな k8s （一般的に KaaS : Kubernetes as a Service と呼ばれる）を導入することで k8s の運用コストを低下させています。Tanzu Kubernetes Grid （以下 TKG）は、VMware の KaaS 製品で、その強みはオンプレミスやパブリッククラウドの様々な IaaS 環境に構築できる点などが挙げられます。つまり、IaaS にとらわれない共通した K8s のライフサイクル管理手法を提供するソリューションです。
以下に TKG の概要図を記載します。
TKGの概要は以下の vSphere 版の記事を参考にしてもらいたいですが、簡単にいってしまうと KaaS 環境を提供する基盤を「マネージメントクラスタ」と呼び、そのマネージメントクラスタが管理するアプリを動かすための k8s クラスタを「ワークロードクラスタ」と呼びます。マネージメントクラスタも k8s で実現されていますが、ユーザーとして直接マネージメントクラスタを k8s 操作することはほとんどありません。
この記事では AWS 上にこの TKG のマネージメントクラスタを構築する手法と、それの利用法および AWS 上でそれがどう実現されているかを簡単に解説します。マネージメントクラスタを一旦構築してしまえば、その使い勝手は vSphere 上に構築した場合や AWS 上に構築した場合と大差ありません。ただ、構築するにあたって「IAM などの AWS 特有の機能」が絡むため、マネージメントクラスタの構築までが基盤ごとに若干異なります。そのため、VMware 公式のドキュメントを読む前の概要把握という位置づけで本記事を参考にして頂けるとよいかと思います。
具体的な構築作業に入る前に、最終的に AWS 上の TKG がどのように構成されるかを図に記載します。
まず、TKG は AWS の EKS（Elastic Kubernetes Service）や ECS（Elastic Container Service）といった AWS のコンテナサービスを利用していません。TKG は IaaS の種類に依存せず似たような構成と操作感を提供するために、各パブリッククラウドの独自の仕組みを踏襲するのではなく、様々なクラウドの IaaS で共通化されているインスタンス（AWSでいうEC2）やネットワーク（AWSでいうVPC）というレベルで TKG の KaaS の構成を実現しています。
上記図を見てもらうと VPC のなかに外からアクセスされるパブリックなサブネットと、AWS 内でのみ利用されるプライベートなサブネットがあることがわかります。このプライベートなサブネット側に EC2 のインスタンスとして TKG の k8s ノードを展開します。そしてそれらのノードへのアクセスを提供する Bastion と呼ばれる AWS でよく使われる踏み台サーバーのようなインスタンスを前面に配置しています。この bastion は k8s のノードを直接インターネットに晒さない（つまりセキュリティを高める）ために存在しています。この構成はマネージメントクラスタも、ワークロードクラスタも共通しています。デフォルトでは独立した VPC を作成しますが、既存の VPC にクラスタを展開することなども可能です。
vSphere 構成に TKG を展開する際と同様に、ユーザーはまず図の左下の Bootstrap と呼ばれる TKG 構築ツールを Linux などに用意します。この Bootstrap は GUI のマネージメントクラスター構築アプリを提供しているので、それにパラメーターを入力していくことでマネージメントクラスタを構築します。Bootstrap はマネージメントクラスタの構築後は、マネージメントクラスタの操作クライアントとして利用できますので、bootstrap で KaaS 操作をすることで、図の上部にあるワークロードクラスタのライフサイクル管理（作成/構成変更/破棄）を実現します。構築されたワークロードクラスタは kubectl で操作ができる一般的なクラスタとなりますが、外部ストレージや認証系などの設定が最初から適用されています。そのため、OSS k8s のような利用前の準備作業がほとんどいりません。
ここから構築作業を順を追って解説しますが、おおまかな流れは以下となります。
- Bootstrap の準備 （ほとんど vSphere 版と同様）
- AWS の IAM でアクセスキーを払い出す
- Bootstrap の aws コマンドで、アクセスキーを使って AWS に接続
- Bootstrap でマネージメントクラスタ構築アプリの起動
- マネージメントクラスタ構築アプリを使って、AWS 上にマネージメントクラスタを構築
以上で構築は完了となりますが、参考情報として以下も記載します。
- ワークロードクラスタの構築
- AWS上に TKG がどのように見えるかを確認
- ワークロードクラスタにアプリを展開して、外に公開
- ワークロードクラスタとマネージメントクラスタを破棄
この記事の内容の公式ドキュメントは以下となります。
- Install the Tanzu CLI and Other Tools
- Prepare to Deploy Management Clusters to Amazon EC2
- Deploy Management Clusters with the Installer Interface
また、bootstrap の構築の詳細は以下の vSphere への TKG 1.4.0 のインストール記事が参考になります。
マネージメントクラスタ構築前の下準備
マネージメントクラスタを構築するアプリを起動するには、bootstrap や AWS アカウントの操作が必要です。
まず、bootstrap の構築ですが、これは Windows/Mac/Linux が使えます。ただ、bootstrap はマネージメントクラスタの構築だけではなく、構築後の操作ツールとして利用可能ですので、多くのユーザーからアクセスされることを想定して Ubuntu 20.04 上に構築します。構築する場所は マネージメントクラスタを構築する AWS 上に作ってしまうことが多いかもしれませんが、インターネットアクセスできる環境であればどこでも大丈夫です。今回はオンプレミスの vSphere 上に仮想マシンとして展開します。
以下に bootstrap の準備のサンプルを記載します。tanzu cli までのインストール方法は先に紹介した vSphere への TKG 1.4.0 のインストール記事に書いてありますので、ここではインストールの確認のみを実施しています。
重要なのは後半にある jq コマンドや aws コマンドのインストールです。jq は Linux 的にインストールしていますが、AWS コマンドは AWS のドキュメントに沿ってインストールしています。
インストールが完了したら、次に AWS アカウントを bootstrap が利用できるようにするために、アクセスキーを発行します。利用するユーザーのアクセス権は以下のドキュメントにありますが、今回は管理者権限のユーザーを利用しています。
AWS 上で「IAM -> ユーザー選択 -> Security credentials」で、bootstrap が使うユーザーのアクセスキーを発行するページに移動します。ここで「Create access key」を押すことで、アクセスキーとそのシークレットが発行されます。メッセージにもあるように外に漏れないようにしつつ、キーを失わないように注意してください。
この情報を使って、aws コマンドで bootstrap を AWS の自分のアカウントに接続させます。
「aws configure」コマンドを発行すると、各設定項目を順に聞かれるので設定していきます。設定が終了すると、上記設定を含むコンフィグファイルが作成されます。後ほど展開するマネージメントクラスタの構築アプリはこの設定ファイルを使うことで、AWS に接続します。
最後に AWS 上のインスタンスに ssh するためのキーを作成します。このコマンドを発行することで、そのキーは AWS 側にも保存されています。
以上で構築前の下準備は終了です。
GUI を使ったマネージメントクラスタの構築
準備が整ったので、本記事のメイントピックであるマネージメントクラスタの構築を開始します。
構築のための GUI アプリは以下のようにコマンドで起動します。裏側では docker 上に k8s（kind）が展開されて、そのうえでアプリが動作しています。ちなみに、このコマンドのオプションは「-u」がユーザーインターフェースを使う指定で、「-b」がアプリを公開するアドレスとポートのバインドです。
アプリを起動してブラウザで表示されているアドレスにアクセスすると、図の下側のようなブラウザアプリが表示されます。このアプリを使って構築作業を実施していきます。
最初の画面ではどの種類の基盤に展開するかを聞かれているので、Amazon EC2 を選択します。
次の画面では AWS に接続するためのクレデンシャルや、どのリージョンを使うかを選択します。
図にも書いていますが、このページの「AWS CREDENTIAL PROFILE」はさきほど aws コマンドで作成された設定ファイルを参照しています。ここになにも出てこない場合は AWS への接続を再度実施して、同じ Ubuntu のユーザーで構築アプリを立ち上げてみてください。
次の設定はマネージメントクラスタを構築する AWS 上の VPC の設定です。
ここではこのクラスタ用に新規 VPC を払い出すか、既存の VPC にクラスタを作成するかを選択できます。既存の VPC に強く依存する構成（たとえばそこの DB に繋ぎたい）といった場合は後者を選択しますが、VPC 間の通信はピアリングなどでも実現できるので前者でも構いません。デフォルトは新規作成となっています。
ネットワークの一般的な話ですが、2箇所で同じ IP レンジを使っていると非常にネットワーク間の連携が取りにくくなるので、新規作成する場合は他のネットワークとアドレス帯がぶつからないように注意してください。他と連携させないのであれば特に気を配る必要はありません。
次の設定はマネージメントクラスタのノードの構成とスペックの設定です。
構成は冗長性なしの Development と冗長性ありの Production の2つで、後者はマルチAZ構成を採用することができます。今回はテストで費用も抑えたいため、小規模構成を選択しています。マシンスペックはAWSのインスタンスタイプから選び、今回は「t2.large」を選択しています。TKG 1.4.0 では「CPU 2コア、メモリ8G」以上のスペックであれば問題ありません。膨大な数の候補が表示されますので、使いたいタイプの名前の先頭を入力することで絞り込んでください。マネージメントクラスタの名前の横にある「EC2 Key Pair」は先の準備の段階で作成したキーペア名を入力してください。
画面下側は基本的にデフォルトのままでよいです。既存 VPC 上に展開して、すでに TKG の bastion ホストがそこに存在する場合はチェックを外すことで既存の bastion を利用します。注意が必要なのが「automate creation of AWS CloudFormation Stack」です。この CloudFormation Stack は使い回されるものなのですが、その作成は1度きりです。つまり、はじめてマネージメントクラスタを構築する場合のみチェックします。過去にマネージメントクラスタを構築している場合は、すでにそれが破棄されている場合であってもチェックしないでください。
参考情報として Production の設定項目をお見せします。画面下部からわかるように 3 つの Availability Zone を選択してマルチAZを組みます。マルチ AZ 構成のマネージメントクラスタのワークロードクラスタはマルチ AZ 構成にも Development 構成にもできますので、重要度と金銭コストを天秤にかけて用途ごとに構成を使い分けるのが良いでしょう。
設定を進めていくと、k8s ネットワークや認証系、利用する k8s のイメージなどが聞かれます。
これらは好みの設定をしてもらえればと思いますが、k8s のネットワーク設定は VPC のネットワークではなく k8s 上に構築される仮想ネットワークである点に注意してください。通常はデフォルトで表示されたサブネットを利用すれば問題ありません。誤って VPC のネットワークのアドレスを入力しないでください。
このあとに TMC などの設定が聞かれますが、今回は利用しないのでデフォルトのまま進めてしまってください。
以上で設定は終了です。
設定が終了すると、設定確認のあとでインストールの進捗状況を示す画面に移ります。
この画面が完了になるまで待ってください。
なお、画面の最下段に今回構築したマネージメントクラスタの構成が書き出されたファイルのパスが表示されています。この設定ファイルはワークロードクラスタ作成時のテンプレートに利用しますので、場所をメモしておいてください。ファイル名を忘れてしまっても構築設定ファイルが「~/.config/tkg/clusterconfigs/」の下にあることを覚えていれば、ls コマンドや cat コマンドでファイルを特定できると思います。
インストールが完了したら、bootstrap で「tanzu management-cluster get」コマンドを発行すると、マネージメントクラスタの詳細が確認できます。
手元にあるオンプレミス上の bootstrap の ubuntu から、AWS 上にあるマネージメントクラスタに接続して情報を取得できていることがわかります。
ワークロードクラスタの展開と確認
ここからは構築以後の簡単な操作と AWS 上の TKG の見え方を参考情報として記載します。ワークロードクラスタの詳細な利用方法は tkg のライフサイクル管理のドキュメントやブログ記事をご参照ください。ロードバランサーの種類が各 IaaS 基盤ごとに異なる以外は環境ごとの差異はあまりなく、そのロードバランサーすら k8s レベルでは差異が隠蔽されています。
まず、アプリを動かすためのワークロードクラスタの作成方法ですが、これは vSphere 上の TKG と全く同じです。以下では マネージメントクラスタの設定を踏襲（設定ファイルにマネージメントクラスタを使う）して、ワークロードクラスタを作成しています。
ワークロードクラスタが作成されました。
ここで一旦、AWS のコンソールを覗いて TKG が AWS 上にどのように構築されているかを確認します。
まず EC2 です。
設定した Development の構成（マスター1台、ワーカー1台）と踏み台サーバーの bastion の3台セットが、各クラスターごとに作成されていることがわかります。プロダクション構成だと「マスター3台、ワーカー3台、bastion 1台」の7台セットがクラスタごとに作成されます。
次に VPC と、そのサブネットを確認します。
これも各クラスタごとに独立した VPC が作成されていることがわかります。先に説明したようにクラスタを展開する VPC には既存のものも利用できます。
せっかくなので、ワークロードクラスタにアプリを展開してインターネットに公開してみたいと思います。まず、ワークロードに接続するための kubeconfig をマネージメントクラスタを操作して入手します。今回はパスワードレスの admin 権限で bootstrap ホストにコンテキストを登録していますが、kubeconfig をファイルに書き出して外のマシンからの接続に利用したり、クラスタを利用するために認証を求めるようにすることもできます。
「kubectl get nodes」コマンドでワークロードクラスタのノード一覧が返ってきていますので、きちんと外部（オンプレ上の bootstrap）から kubeconfig でアクセスできていることがわかります。
次に nginx のポッドをデプロイして、それをサービスのタイプ LoadBlancer で公開します。
サービスが External IP として AWS のリソースを引っ張ってきており、それにアクセスするとアプリにインターネット越しに接続できました。細かなオプションを指定せず L4LB を使ったため、このようなランダムに生成されたような URL を使っています。もっと実際のアプリに使うようなアドレス（たとえば example.com など）を利用したい場合は、k8s 的な方法（たとえば ingress や external-dns など）を利用するか、既存インフラ的な手法（たとえば、DNS のレコードを作成したり、前段に AWS の cloud front のようなサービスを挟む）を使います。これらの詳細は本記事の範疇を超えますので割愛します。
クラスタの解体
ここではワークロードクラスタとマネージメントクラスタがその使命を終えたとして、クラスタを破棄します。あたりまえですが、クラスタを破棄しないと AWS の課金が続きます。
まずワークロードクラスタの解体です。
このコマンドを発行すると裏側で解体が走ります。「tanzu cluster list」コマンドでワークロードクラスタ一覧を表示しながら、解体状況を確認できます。なお、解体するワークロードクラスタが Persistent Volume や、Load Balancer などのリソースを利用している場合は先に k8s 的な操作で開放してあげてください。これらを消し忘れてクラスタを解体してしまった場合は AWS 的な操作でリソース開放をお願いします。
詳細は以下のドキュメントをご参照ください。
そして、マネージメントクラスタの解体です。
こちらはコマンドを発行してから解体が完了するまでプロンプトが取られます。
マネージメントクラスタを潰してしまうと、ワークロードクラスタのライフサイクル管理を実現する KaaS を全く使えなくなります。マネージメントクラスタの構築前の状態に戻りますので、もういちど利用する必要が発生したら bootstrap を使って再構築してください。
ワークロードクラスタとマネージメントクラスタを解体すると、AWS 上のリソースも開放されます。
以上で本記事を終了します。ご拝読ありがとうございました。
