はじめまして。VMware の伊藤です。Tanzu 製品のプラットフォームアーキテクトとして働いており、開発と運用双方の経験があります。今回は「触りながら学ぶ vSphere with Tanzu」シリーズの第三回として vSphere with Tanzu を管理者と操作して開発者に Kubernetes 環境を提供する方法を学びます。これを学ぶことでスーパーバイザークラスタの概念や、なぜセルフサービス型のK8s運用が優れているかといった点を理解できます。
Tanzu Kubernetes Grid （TKG） の基本的なコンセプトは K8s の利用者（開発者と運用者の両方）にたいして、セルフサービス型の K8s 基盤を提供するというもので、K8s を利用したいユーザーが自分自身でクラスタを展開/変更（スケールやアップグレード）/削除できます。これは vSphere7 に組み込まれる vSphere with Tanzu （別名TKGS: Tanzu Kubernetes Grid Service）でも、AWS や Azure などで利用される TKGm （TKG multicloud） でも同様です。誰かになにかの作業を頼まないでよいセルフサービス型の K8s 基盤は開発者にとっても、運用者にとってもメリットがあります。セルフサービス機能の有無による違いを以下の図に記載します。
たとえば図の左側のようにセルフサービスでない K8s 基盤の払い出しをするとしましょう。K8s が必要になるたびに運用者は要件にしたがって K8s クラスタを定められた手順に従って作成します。原始的な作成方法であれば、ベアメタルか仮想マシンとして Linux を数台作成し、それに K8s に必要なパッケージをインストールしてからツールを使ってクラスタを構築することになります。もう少しスマートな方法を採用すれば GUI なり CLI なりで決められた要件に沿ったクラスタを自動で構築できますので、労力は減ります。ただし、IT エンジニアが数百人以上いる組織においてプロジェクトごとに複数のクラスタを構築し、それをアップデートしたり、破棄（資源の回収）する作業は膨大になります。それを運用チームがすべて引き受けて実施していれば、利用者にクラスタを作成して渡すにも時間がかかりますし、サイズ変更やアップデートなども即座には実施できないでしょう。運用チームにとっても多くの仕事依頼に忙殺されることになります。
一方、図の右側のようにセルフサービスな K8s 基盤の払い出しをするのであれば、K8s を必要とする人が自分自身で作成を実施できます。開発者視点では即時に環境の払い出しや構成変更（スケールやバージョン）を行えるというメリットがあり、運用者視点では環境払い出しに人的なリソースを奪われないというメリットがあります。TKG が図の左側で運用者が実施していた作業をプラットフォームとして自動で実施しています。このようなK8s自体をサービスのように利用者が使うことができる基盤は「KaaS（Kubernetes as a Service）」と呼ばれることがあります。
私の個人的な意見となりますが、たとえば開発環境の K8s クラスタは本番環境に比べるとかなり荒く利用することが多いです。拾ってきたYAMLをとりあえず展開してみたり、勉強中の機能を見様見真似で導入することを頻繁に実施したりします。そうすると、使っているK8sクラスタの環境はすぐに汚れてしまいます。もし左側のような運用方法で K8s を使っていれば、運用者にクラスタ再構築を依頼することに気が引けるので、クラスタを汚さないように気をつけますし、汚れてしまったら手動で頑張って戻そうとします。ただ、新しいことを試したい状況ではそういった利用法は開発者にとって負担となるはずです。一方で右側の例のように TKG では簡単にK8s環境を自分で管理できます。そのため「K8sクラスタをガチャガチャ触って、汚れたり、壊れたり、新しいことを試したくなったら新規に作り直す」ということを気兼ねなく実施できます。これは利用者にとってありがたいことなのではないかと思います。運用者にとっても壊れたクラスタの復旧依頼や再構築依頼が減るでしょう。
この記事では TKGS のスーパーバイザーネームスペースを使ったセルフサービス基盤をどのように設定するかを紹介します。ネームスペース機能を使うことで、TKGS 上の「TKC の作成」「vSphere Pod の作成」といった利用者操作を「誰が」「何を」できるかといったことや、「どの永続ストレージを使うか」「どれほどのCPU/メモリ/ストレージリソースを使えるか」といったことを定義できます。
スーパーバイザークラスタの構成確認
このシリーズの第1-2回でも紹介しましたが、vSphere with Tanzu の構成を復習します。vSphere Tanzu には「スーパーバイザークラスタ」と呼ばれるK8sを管理するための K8s がいます。そしてスーパーバイザークラスタには「スーパーバイザーネームスペース」という VMware の仮想マシンのリソースプールと一般的な K8s のネームスペースを合わせたような管理単位があります。このスーパーバイザーネームスペースの上に第一回で紹介した「Tanzu Kubernetes Cluster（TKC）と呼ばれるワークロード K8s クラスタ」を展開したり、第二回で紹介した「ESXi 上に Pod を超軽量仮想マシンとして K8s 的に展開する vSphere Pod」を展開したりします。以下にこの概念図を記載します。
Tanzu の管理者（運用者）の仕事は、「利用者にスーパーバイザーネームスペースを提供する」ことです。具体的には「ネームスペースを作成する」操作をし、「誰がどういった権限でネームスペースにアクセスできるか」「ネームスペース上のコンテナはどのデータストアを利用するか」「CPU やメモリ、ストレージをどれだけ利用できるか」といったことを設定します。あとは設定されたスーパーバイザーネームスペースを実際のK8s の利用者（開発環境 K8s を使う開発者や本番環境 K8s を使う運用者など）に渡して、それが正しく使われているか従来の仮想マシン環境と同じようにネームスペースレベルでモニタリングを実施するだけです。
この記事では前回までの記事のように VMware が提供するハンズオンラボ環境の「HOL-2113-01-SDC – vSphere with Tanzu」を使って、まずスーパーバイザークラスタの構成を確認したうえで、上記の管理者としての操作であるスーパーバイザーネームスペースの管理と作成を行います。ハンズオン環境の利用法は当シリーズの第一回の記事をご参照ください。
触りながら学ぶ vSphere with Tanzu 第1回: Tanzu Kubernetes Cluster
まず、管理者としてvCenterに接続するためにモジュール2の「The Supervisor Cluster」の「Log into vCenter」にしたがって、vSphere Client にログインしてください。ログインしてクラスタとホスト一覧のページを確認すると以下のような状況となっているはずです。
この図にあるようにクラスタ「RegionA01-COMP01」の下に Namespaces があります。これは vSphere7 で vSphere with Tanzu（TKGS）の機能を有効化した際に現れるスーパーバイザーネームスペースの一覧となります。このHOLでは最初から「demo-app-01」というネームスペースが作成されていますが、機能を有効化した直後の状態では空になっています。スーパーバイザーネームスペースの下にある「SupervisorControlPlaneVM」が、TKGSの機能を実現するアプライアンスVMとなり、これらも vSphere7 で TKGS の機能を有効化した際に自動で作成されます。この VM たちはTKGSが提供する機能を実現するためのサービスを動かしており、これら自身も K8s クラスタを構築して動作しています。第一回の TKC 作成や第二回の vSphere Pod の作成のさいに「kubectl vsphere login」コマンドを使ってスーパーバイザークラスタにログインを実施しましたが、実はその接続先はこれらの VM が動かす管理用の K8s クラスタです。このスーパーバイザークラスタがどういうものかは深く知らなくても運用はできますが、以下に簡単な構成図を記載します。
図にあるように一般的な vSphere 環境と同じように vCenter が複数の ESXi を束ねるという構成をとっています。注目して欲しいのは ESXi の中にある「K8s Control Plane VM」であり、これがさきほど紹介したアプライアンス VM となります。アプライアンス VM は全ホストに展開されるのではなく、K8s クラスタ構築に必要な3台が vSphere クラスタを構成する ESXi のどれかに配置されます。このアプライアンス VM のサイズはvCenter などと同様に管理する vSphere Pod や TKC の数が増えるほど大きくなります。
図の右上にこの VM の内部構成があり、K8s ユーザーには見慣れたコンポーネントが並んでいることが確認できます。また、ESXi ホスト自身と vCenter にたいしても TKGS の機能を実現するためのコンポーネントが追加されており、特に重要なものとしては vSphere Pod を実現するために ESXi の内部に Spherelet（kubelet）が置かれていることが挙げられます。この Spherelet があることで、スーパーバイザークラスタは ESXi ホストをワーカーノードのように扱って K8s ポッドを vSphere Pod として作成できるようになっています。
また、管理者やユーザーとして知っておくべきことは、このスーパーバイザークラスタを構成する VM は「マネージメント用のネットワーク」と「ワークロード用のネットワーク」に接続されているということです。前者は図で「Management vNIC」と書かれたものであり、後者は「NSX Cluster vNIC」と書かれたものです。これらをどう設定するかは機能を有効化する際に指定しますが、その設定は「vSphere クラスタ（スーパーバイザークラスタではないので注意）」の設定（Config）にある Namespace から確認できます。2020年12月時点で多くの項目は構築後に変更できませんので、最初のネットワーク設計はきちんと実施してください。
なお、このスーパーバイザークラスタのIPアドレスはメニューの「Workload Management」から「Clusters」タブで確認できます。以下の例では「192.168.124.1」となります。「kubectl vsphere login」で接続する際に利用する重要なパラメーターですので確認方法は覚えておいてください。
スーパーバイザーネームスペースの確認
アクセス頂いている vSphere ではすでに vSphere with Tanzu が有効化されており、スーパーバイザーネームスペースも作成されています。そのネームスペース「demo-app-01」を使って、ネームスペースの設定確認をしながら機能説明をおこないます。マウスで「demo-app-01」をクリックすると以下のような画面が表示されるはずです。
上記の図で番号を与えている箇所はそれぞれ以下の表示をしています。
- ネームスペース設定の機能ごとのタブ。Summary で機能一覧の状況が確認できる
- スーパーバイザークラスタの稼働状況
- ネームスペースに編集（edit）/閲覧（view）権限を持つユーザー。ここにないユーザーはアクセスできない
- ネームスペースに割り当てられたストレージポリシー（vSphereのデータストア指定などに使う）と作成されたPVCの数
- ネームスペースで使われている TKC と vSphere Pod の合計リソース
- ネームスペースで動いている vSphere Pod の数と稼働状況
- ネームスペース上に構築されている TKC（ワークロードクラスタ）の数
それぞれに表示される Manage や Edit ボタンからこれらの設定を変更することができますし、上記の Summary があるタブから各項目の画面で詳細を確認したり設定変更することも可能です。各項目ごとに詳細説明すると記事が長くなりすぎるので割愛しますが、クリック操作でそれぞれどういった項目があるかチェックしてもらったり、オリジナルの HOL のモジュール2の「Supervisor Cluster Namespaces」に沿って操作をしていけば、どういった機能があるかを確認してもらえます。お時間がある際に試してみてください。
スーパーバイザーネームスペースの作成と編集
アクセスコントロールやリソースの管理はスーパーバイザーネームスペース単位で実施します。K8s の利用者1人ごとにネームスペースを与えれば、その人だけが使える環境が用意できます。また、作成したネームスペースに複数の利用者アカウントを結びつけることで、チームで共有する環境を用意することもできます。実際にネームスペースの作成をおこないながら、どういうかたちでネームスペースを使うがよいかを説明していきます。ここで紹介する利用法の詳細は以下のドキュメントをご参照ください。
まず、ネームスペースの作成をおこなうために vSphere Client のページ上部ナビゲーションにある Menu（メニュー）から「Workload Management」を選択し、スーパーバイザークラスタの管理ページに移動します。
このページはスーパーバイザークラスタの有効化（スーパーバイザークラスタの作成）や更新にも利用しますが、ここからネームスペースの管理（作成/変更/削除）も実施できます。上記図では既存のネームスペースが選択されていないので、「New Namespace」のみ表示されていますが、下の表で選択すれば変更や削除（上で動く TKC や vSphere Pod もまとめて削除）を実施できます。今回は作成するので、「New Namespace」をクリックします。
クリックすると、vCenter が管理するどのデータセンターのどの vSphere クラスタ上にネームスペースを作成するか聞かれるので、上記図の1-2のように選びます。そしてネームスペース名をと必要であれば概要（description）を入力し、Create ボタンを押すとネームスペースが作成できます。
ネームスペースを作成すると既存の「demo-app-01」と同じように「demo-app-02」がメニューのクラスタとホストの一覧のなかに表示されるようになります。さきほど demo-app-01 を確認したように demo-app-02 をクリックしてネームスペースの状況を表示し、ネームスペースの初期設定作業を実施します。ネームスペースを利用するために必須なのは Permission と Storage の設定のみで、それ以外のリソースコントロールなどは必要であれば設定する項目となります。
上記図の Add Permissions を押すと、登録するユーザーの入力画面が出ますので、誰が、何（Edit/View）をできるか入力してOKボタンをクリックします。このユーザー登録作業を必要なだけ繰り返します。なお、ここに入力されるユーザーは vSphere に登録されているユーザーです。外部（LDAPなど）で管理されないユーザーであれば、メニューの設定（Administration）から「Single Sign On」「Users and Groups」と進むことでユーザー管理をおこなえます。詳細は vSphere のドキュメントを参照ください。
vCenter Single Sign-On ユーザーの追加
次にスーパーバイザーネームスペース上の TKC と vSphere Pod が利用できるデータストアの指定をおこないます。これはネームスペース設定画面の「Add Storage」ボタンからストレージポリシーの設定をすることでおこないます。今回は「high-performance-ssd」を指定します。
なお、今回は事前にストレージポリシーが用意されていましたが、新規構築する場合は新しく「データストアを特定するためのストレージポリシー」を作成する必要があります。それには以下の画像のように利用したいストレージにたいして識別子となるタグを与えたうえで、メニューから「Policies and Profiles」に進み、VM Storage Policies で新規にストレージポリシーを作成することで実施します。ポリシー作成のさいに先ほどデータストアに与えたタグを利用するように指定すれば、選択したデータストアを指定できるストレージポリシーが作成できます。
vSphere with Tanzuのストレージ ポリシーの作成
kubectl vsphere コマンドのインストール案内
最後に第1-2回で利用していた kubectl vsphere コマンドの設定方法について扱います。このコマンドは Linux のパッケージ管理や Docker Desktop のインストールをしただけでは利用できません。VMware から入手した kubectl の実行ファイル（バイナリ）もしくはすでにご利用の kubectl のバイナリにたいして、「kubectl-vsphere」というプラグインを追加することで使えるようになります。運用者のかたは TKGS の利用者にたいして「どのURLでプラグインを入手して、それをOSのどこに配置することで kubectl vsphere コマンドが使えるようになるか」ということを伝えてください。詳細は後述するドキュメントをご参照いただきたいですが、vSphere Client の「namespace -> summary -> status -> link to cli status」で確認できる「Kubernetes CLI Tools」のダウンロードページの URL を利用者に送り、そこでダウンロードしたバイナリ（Windows/Mac/Linux）をkubectlバイナリがある「パスが通っているディレクトリ」に配置することになります。
vSphere 向け Kubernetes CLI Tools のダウンロードとインストール
以上で管理者としてのネームスペース機能の概念と利用法の紹介記事を終了します。作成されたネームスペースへの接続方法は第一回の TKC の記事にて説明していますので、そちらを参照してください。次回の第4回は TKGS がどのように構成されているかという座学よりの内容を扱う予定です。ご拝読ありがとうございました。
