はじめまして。VMware の伊藤です。Tanzu 製品のプラットフォームアーキテクトとして働いており、開発と運用双方の経験があります。今回から VMware Tanzu の主要製品の1つである vSphere with Tanzu を実際に利用しながら学ぶという内容で4,5回のシリーズ記事を投稿したいと思います。初回は主要機能である Tanzu Kubernetes Cluster（TKC）で Kubernetes（K8s）のワークロードを動かしたり、TKC のライフサイクル管理（作成/更新/削除）の手順を紹介します。
vSphere with Tanzu は Tanzu の K8s 製品である「Tanzu Kubernetes Grid」の1つであり、別名「TKGS（TKG Service）」と呼ばれています。TKG と名前がつく製品が多くて少しややこしいのですが、これは vSphere7 に付属する Tanzu の K8s なので「vSphere に付属する Tanzu」だから「vSphere with Tanzu」であり、「vSphere のサービスとして動く TKG」だから「TKGS」などと覚えてもらうのがよいかもしれません。製品名を vSphere with Tanzu と毎回書くと長いので、この記事では TKGS と統一します。
この記事では TKGS の主要機能である開発者が利用するワークロードクラスタである TKC の展開と利用にフォーカスしますが、TKGS の最初の回ですので他の TKG と名前がつく製品との違いや、今後の記事に関わるネームスペースという概念についても説明します。これらの内容はたんに記事を読んでお勉強するだけでなく、VMware が提供するハンズオンラボ環境で誰でも気軽に触ってもらえるようになっています。マニュアルや解説を読むだけでなく、実際に製品に触ってみて Tanzu を理解していただけると幸いです。
この記事の内容を読んで試すことで以下の操作ができるようになります。
- vSphere with Tanzu のスーパーバイザークラスターと Tanzu Kubernetes Cluster （TKC:ワーカークラスター）に接続する
- vSphere with Tanzu のネームスペースに TKC を作成する
- TKC 上にワークロード（K8sのサービスとデプロイメント）を展開する
- TKC のスケールアップ
- TKC の K8s のバージョンアップ
- TKC の破棄
詳細はのちほど解説しますが、操作概念をまとめると以下のように「運用者がスーパーバイザーネームスペース単位で誰がアクセスできるかを定義する」「スーパーバイザークラスター（管理用K8s）で TKC のライフサイクル管理をK8s流に実施」「スーパーバイザークラスターに管理される TKC は一般的な K8s として使える」となります。
vSphere with Tanzu（TKGS）の紹介
vSphere with Tanzu は別名 TKGS と呼ばれており、VMware の K8s 製品である TKG の1つです。それぞれ別の記事にて紹介する予定ですが、TKG には以下の3つがあります。
- TKGS: この記事で説明するもの
- TKGm: TKG multicloud。vSphere に依存しない TKG（vSphere だけでなく AWS, Azure などでも動く）
- TKGI: TKG Integrated。旧Pivotal Container Service や VMware Enterprise PKS のリブランディング製品
上記にあるように製品の成熟度としては2020年11月段階では TKGI が一番高いです。ただ、今後の開発計画では TKGS や TKGm に主軸が移っていくので、すでに TKGI を利用しているのでなければ TKGS, TKGm をまず検討するのがよいと思います。TKGm は TKGS に比べて vSphere への依存度が低いという特徴があり、これは強みであり、弱みでもあります。すぐ想像できると思いますが、TKGm は vSphere への依存が少ないので様々な環境で共通した操作体系を提供できるという強みがあります。ただし、逆にいえばvSphereに依存した機能を作れないので TKGS ほど機能的に豊富ではありません。使い勝手がよりバニラ（オープンソース版）に近いので、TKGS であれば提供される機能を自分で用意したりする必要があります。
本題の TKGS の解説に移りましょう。TKGS のキーコンセプトは「開発者にセルフサービスとして K8s の利用方法を提供する」というものです。具体的にはvSphereの管理者が vSphere のリソースをネームスペースとして切り出し、そのうえで開発者にアプリケーションを動かすための自分の K8s クラスタを作って運用してもらうというものです。ネームスペースには複数ユーザーを編集/閲覧権限で登録できるので、チームでネームスペースを共有することもできます。ネームスペース上にどれほどのサイズのクラスタをいくつ展開するかは開発チームが自分自身で決めることができます。これらにより開発者視点ではいちいち運用チームに払い出しやサイズ変更の依頼をしなくても自分で調整できますし、運用チーム視点では開発チームが好きにクラスタを使うので細かな作業依頼の数が減るでしょう。もちろん、運用チームが開発チームのためにクラスタを作って払い出すというオペレーションを実施してあげても構いません。このコンセプトを以下の図にまとめます。
図の左側にある運用者が操作しているクラスタは「Supervisor Cluster」と呼ばれるもので、vSphere with Tanzu の機能自体を実現するK8sクラスタです。このクラスタを K8s として直接操作することはほとんどなく、実際にアプリケーションを払い出すプロビジョニング機能のサービスを提供しており、運用者は vSphere Client を通してそれを操作しているイメージです。運用者は vSphere Client を通して開発者に貸し出す namespace を作成します。そうすると開発者は自分のアカウントが結び付けられた namespace にアクセスできるようになるので、そこでクラスタの払い出し操作をしたり、アップグレードやスケールアップ/ダウン、クラスタの破棄などを実施できます。これらの操作は vSphere client ではなく K8s で使われる「kubelet」コマンドで実現します。具体的な操作は後ほど紹介します。
これらの操作をこの記事では以下のシナリオで順に解説していきます。
- VMWareの HOL（Hands On Lab）ページにアクセスし、vsphere with Tanzu のラボを開始
- 最初から用意されている開発者用の K8s クラスタ（TKC）にアクセス
- K8s クラスタにワークロードを展開
- 運用者として新規ネームスペースを作成し、ユーザーを結びつける（運用者向け記事で詳細を扱う）
- そのユーザー（開発者）としてスーパーバイザークラスターに接続し、自分用の TKC を展開
- TKC のスケールアップや破棄作業を実施
TKCにアクセスしてワークロードを展開
VMware HOL を利用するにはユーザー登録が必要です。以下のページにアクセスして右上の Register からユーザー登録をしてください。登録/ログイン後にページの言語を右上から変更して日本語にできます。
画面左にリモートデスクトップ画面があり、右にラボシナリオがあり、上部にラボの残り時間が表示されています。「延長」ボタンを押すことでラボの残り時間を増やすことができます。マニュアルのページ操作などは特に難しくないと思いますが、ローカルマシンからのコピーアンドペーストは左上の「テキストの送信」ボタンからおこないます。これを押すとテキストボックスが開くので、そこにリモートの Windows にペーストしたい文字列を貼り付けて「送信」ボタンをクリックします。そうすることで Windows に文字列が貼り付けられます。画面上で直接Ctrl+vで貼り付けられないので気をつけてください。なお、リモートマシン内でのコピペは Ctrl+c -> Ctrl+v で実施できます。
この記事ではマニュアルのモジュール4を実施します。モジュール1や2は構築や運用系の内容ですので、それらは飛ばしてまずはTKGSの使い勝手を理解してもらう当記事の内容にあったモジュール4を使います。ページ右のマニュアルの上部にある目次ボタンからマニュアルのモジュール4を開いてください。初期解説にしたがってvCenterにChromeからログインをおこないます。クレデンシャルなどはマニュアルに記載のものをご利用ください。ログインして「ホストとクラスター（おそらく初期画面）」を表示すると以下のような画面が見えるかと思います。これが vSphere Client で確認できる TKGS のネームスペースとTKC です。
次に開発者として TKC へのログイン作業を実施します。目次からモジュール4の「LOGGING INTO THE TANZU KUBERNETES CLUSTER」に進み、その内容にしたがって、Linux の操作端末にログインします。なお、WindowsやMacOSXからも直接TKCを操作することができますが、今回はラボの関係で Linux の踏み台サーバーから操作を実施します。なお、以下のコマンドのIPやユーザー名はラボのマニュアルもご参照ください。
Linux の操作端末にログインできたら、画面左上の「テキストの送信」にて以下のコマンド（1行）をコピペで発行します。発行したらパスワードが聞かれますので、「VMware1!」と入力してください。
|
1 |
kubectl vsphere login --server=https://192.168.124.1 --insecure-skip-tls-verify [email protected] --tanzu-kubernetes-cluster-name=tkg-cluster-01 --tanzu-kubernetes-cluster-namespace=demo-app-01 |
非常に長くて申し訳ないのですが、コマンドは以下の構造になっています。
|
1 |
kubectl vsphere login --server=<SUPERVISOR_URL> --insecure-skip-tls-verify --vsphere-username=<LOGIN_USER> --tanzu-kubernetes-cluster-name=<TKC_NAME> --tanzu-kubernetes-cluster-namespace=<NAMESPACE_NAME> |
これでK8sのコンテキストとして TKC が登録されたので、「kubectl config use-context」コマンドで該当の TKC にコンテキストを変更します。そうすることでこの TKC を利用できます。
|
1 |
# kubectl config use-context tkg-cluster-01 |
TKC は普通の K8s クラスタなので、K8s の一般的なデプロイメントやサービスの定義をできます。ありきたりな内容となりますが、マニュアルの「DEPLOYING A STATELESS APPLICATION TO THE TANZU KUBERNETES CLUSTER」に沿って nginx の展開を実施し、そのサービスのIP（ロードバランサーから自動で払い出される）を確認してブラウザでアクセスしてみます。このLinux環境に用意されている YAML ファイル「~/labs/nginx/nginx.yaml」を kubectl apply してワークロードを展開します。
K8s のポッドとサービスが作成されたことが確認できました。サービスの External IP（ロードバランサーが提供）にアクセスすると、nginx ポッドが動作していて外部に nginx が公開されていることがわかります。
以上で、払い出されたTKC に開発者としてアクセスし、利用できることが分かりました。「kubectl vsphere」コマンドによる TKC のコンテキストの取得までは VMware 独自のコマンド（kubectl の拡張をしている）なのですが、これがあることで「誰がどのクラスタで何ができる」という設定にしたがって K8s のコンテキストが得られます。一度コンテキストを得てしまえば、普通の K8s クラスタと大差なく利用できます。モジュール4にはウェブアプリの展開などのシナリオもありますので、興味があればそちらも試してみてください。
TKCの作成
ここからは HOL のシナリオにはない作業を実施していきます。まずは自分に割り当てられているネームスペース「demo-app-01」に新しい TKC を展開してみたいと思います。開発者は運用者が定義したネームスペースのリソース上限に達するまで、好きなだけ作業用クラスタである TKC を展開できます。
TKC 自体のライフサイクル操作をするにはスーパーバイザークラスターにたいしてネームスペースを指定してログインし、そこで「YAMLを発行する」という K8s らしい操作をおこないます。そうすることでログインユーザーに割り当てられた権限でスーパーバイザークラスターのネームスペースでクラスタ管理操作をおこなうことができます。なお、開発者がスーパーバイザークラスタにログインできるようにする操作は運用者の仕事ですが、その操作は運用者としての操作をおこなう記事で紹介します。先の図の再掲ですが、TKC の作成操作は以下のイメージとなります。「TKC クラスタ自体の管理はスーパーバイザークラスタでおこなう」「TKC のワークロード操作は TKC で普通におこなう」と認識してください。
それでは TKC 作成作業を開始します。以下のコマンドでスーパーバイザークラスターにログインします。利用している具体的な URL やユーザー名はマニュアルのセクション4の「LOGIN TO SUPERVISOR CLUSTER」を参照してください。
|
1 |
このスーパーバイザーへのログインコマンドは先のTKCへのログイン方法とほとんど同じですが、TKC を指定するための TKC 名やネームスペースがない点が異なります。このコマンドの発行に成功すると以下のようなレスポンスが得られ、スーパーバイザークラスターのコンテキストが得られます。以下の例ではコマンドでのログイン後にコンテキストもスーパーバイザークラスターに変更しています。
次にスーパーバイザークラスターのネームスペースにたいして TKC をデプロイするための YAML の定義をおこないます。K8s で一般的に利用されるPodやServiceの定義と構造は同じですが、リソースタイプが TanzuKubernetesCluster となっています。以下に利用する YAML を記載しますので、Linux 上に mycluster.yaml などとして保存してください。全て手書きすると大変なのでviコマンドで編集モードにはいったうえで「コピペボタン」で貼り付けてもらうのがよいと思います（このブログではソースコード貼り付けがうまくできないので、画像も張っておきます）。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
apiVersion: run.tanzu.vmware.com/v1alpha1 kind: TanzuKubernetesCluster metadata: name: mycluster namespace: demo-app-01 spec: distribution: version: v1.16.8 #K8s version topology: controlPlane: count: 1 #control plane node class: best-effort-xsmall storageClass: high-performance-ssd #Specific storage class for control plane workers: count: 1 #worker nodes class: best-effort-xsmall storageClass: high-performance-ssd #Specific storage class for workers settings: network: cni: name: calico services: cidrBlocks: ["198.51.100.0/12"] pods: cidrBlocks: ["192.0.2.0/16"] storage: classes: ["high-performance-ssd"] #Named PVC storage classes defaultClass: high-performance-ssd #Default PVC storage class |
リソース TanzuKubernetesCluster の細かな yaml の内容は製品ドキュメントを参照していただきたいですが、クラスタ名とK8sのバージョンおよびマスターとワーカーノードの数とサイズ（class）が定義されています。今回は xsmall というサイズでマスターとワーカーをそれぞれ1つ作成します。どのようなサイズ（class）が使えるかはドキュメントに記載されています。YAML の後半の setting 以降はオプション設定ですので、明示的に定義しなければデフォルト値が適用されます。ここでは K8s クラスタの内部ネットワークの定義などをおこなっています。
YAML が定義できましたので、apply コマンドで K8s に適用します。そうすることで pod や service と同じ用にネームスペース（demo-app-01）に TKC（mycluster）をデプロイして利用できるようになります。HOL の環境は多数のユーザーにマシンパワーを分割しているので、かなりパフォーマンスが低いです。通常は小規模の TKC であればデプロイは5分程度で終わりますが、HOL環境だと15分程度かかるかもしれません。TKC が作成される様子を vSphere Client で見ていると面白いかもしれません。作成が完了すると以下の図のような状態になります。
|
1 |
kubectl apply -f mycluster.yaml |
ここで作成した TKC mycluster には先ほどと同様にログインしてコンテキストを変更することで利用することができます。ただし、注意が必要なのは TKC の初期設定でセキュリティポリシーの定義が必要なことです。これをすることで一般的な K8s のクラスターとして利用できるようになります。詳しくは以下のドキュメントを参照ください。
TKCのライフサイクル管理
TKC のライフサイクル管理はクラスタの作成/更新（ノードのサイズや数の変更、K8s のバージョンアップ）/削除などの操作です。これらの操作は TKC にたいしてではなく、スーパーバイザークラスターにたいして実施します。コマンドを発行するコンテキストに注意してください。TKC にたいしてコマンドを発行してもリソースエラーになるだけで何も変化しません（トラブルはおきません）。
TKC の作成は先ほど学んだので、ここではワーカーノードの数を2に増やす更新操作を実施します。ライフサイクル管理は TKC 作成のときと同様に K8s のリソース管理機能を使って実現します。さきほど作成した TKC 作成の YAML（mycluster.yaml）を更新して、workers, count の数を2に変更します。そして YAML を更新したら再度 kubectl apply することで更新します。しばらく待つと以下の図のようにワーカーノードが1から2に増えたことが確認できます。
ノード数の変更と同様に TKC の K8s のバージョンも YAML にかかれているバージョンを更新して、再度 kubectl apply することで実現できます。ただし、今回の HOL 環境では現在使っている K8s イメージ以外のイメージが用意されていないためアップデートはできません。通常はアップデートイメージの指定は「Tanzu 用の K8s イメージの置き場所のリポジトリ URL を設定しておく」として必要になれば勝手にダウンロードするように設定しておきます。外部にアクセスできない環境であれば vSphere にイメージをファイルとしてアップロードしておきます。
最後にこの TKC クラスタを利用し終わったと想定して破棄します。Pod やサービスと同様に TKC も TanzuKubernetesCluster というリソースを削除することで破棄できます。YAML ファイルにたいして delete コマンドを発行してクラスタ削除をおこないます。
コマンド発行後に TKC の削除が開始され、しばらく待つと上記画像のように vSphere Client でも TKC の mycluster が削除されたことが確認できます。以上で TKGS における TKC 操作の紹介を終わります。
なお、重要なのは「これらの TKC のライフサイクルに関する操作はインフラ管理者が実施する必要はなく、スーパーバイザークラスタのネームスペースを利用できる開発者であれば実施可能」という点です。運用者が K8s の利用組織ごとにスーパーバイザーネームスペースを作成して利用者をアサインすることで、開発者は自分に割れ当てられた領域で好きに K8s クラスタ（TKC）を使えます。運用者が開発者のために K8s クラスタを作成して渡すという運用形態だとやりとりに時間がかかります。自由にクラスタを使いたい開発者にとっても、いちいち開発者からインフラ構築の依頼を受けたくない運用者（仕事依頼が多いと1人あたりの生産性が低下）にとってもメリットのある K8s クラスタの運用形態かと思います。
次回は vSphere Pod という ESXi ホスト上でポッドを直接利用できる VMware ならではの K8s の機能を紹介します。ご拝読ありがとうございました。
