Tanzu

Tanzu Community Edition の概要と使いどころ

はじめまして。VMware の伊藤です。Tanzu 製品のプラットフォームアーキテクトとして働いており、開発と運用双方の経験があります。この記事では Tanzu Community Edition の概要と、それをどういった環境でどう利用するかについて紹介します。

Tanzu Community Edition (以下 TCE)は VMware が提供するマネージド Kubernetes の製品である Tanzu Kubernetes Grid (以下 TKG)の OSS 版となり、商用環境も含めて無償で利用することが可能です。

 

OSS 版の TCE も製品版の TKG もコンセプトは「マネージド Kubernetes の基盤をオンプレミス/パブリックに構築して、Kubernetes の管理運用コストを低減させる」というもので、いわゆるバニラ Kubernetes(以下 k8s) と呼ばれる素の k8sの辛い箇所であるライフサイクル管理(構築/構成変更/破棄)の大変さを解消したり、k8s 構築後に追加インストールで導入する ingress やログフォワーディング系などの様々なツールをパッケージ化して簡単に導入できるといった利点があります。

以下に TCE の構成図を記載します。

 

図にあるとおり、様々な IaaS (Providers)をサポートしており、基盤部分(Runtime, Connectivity)は OSS で構成されております。そしてそのうえには様々な k8s アクセサリが簡単にインストールできるかたちで用意されています。図の右側の「Batteries included but swappable」という説明のとおり、必要な機能はひととおり最初から準備されているものの、この構成の代わりに自分で好きな OSS や製品を導入することもできます。

現時点の TCE と TKG の差異としては、製品である TKG は VMware のサポートや L4 ロードバランサーアプライアンス(NSX-ALB)の提供などがあるものの、TCE にはそれらがありません(ロードバランサーは metallb などを自前で構築すれば使えます)。有名なOSSと企業製品の関係にたとえると、「TCE は Fedora OS であり、TKG は Red Hat Enterprise Linux」であると言えるかもしれまん。開発元である VMware としては TCE を幅広いユーザー層に使ってもらい、そのなかで得られたフィードバックを TKG という製品に反映させるという関係を現時点で考えています。また、TCE を開発環境に使っている企業が、重要な本番/ステージング環境でサポート付きの製品版の TKG を導入することを期待しています。

なお、本格的に TKG を vSphere 本番環境で利用するようになった場合は、「開発環境で TCE を使って、本番環境で TKG を使う」という使い分けは微妙な差分が開発と運用の負担になるかもしれません。TKG 自体は Tanzu の下位ライセンスでも利用できますので、ヘビーユーズするようになった場合は製品版を開発環境で利用することもご検討ください。

 

2種類の利用法と4種類のインフラ基盤。3種類の操作端末

種類により異なりますが、バニラに近い k8s は Linux にコマンドラインで k8s のパッケージをインストールしてクラスタを構築するという手順でクラスタを用意します。一方、TCE は「tanzu コマンドで k8s クラスタを構築/構成変更/削除する」というかたちで k8s クラスタの運用を実施します。前者は操作が複雑で時間がかかる一方、後者は非常にシンプルとなるため、ユーザー視点では TCE のほうが圧倒的に簡単かと思います。

TCE の k8s クラスタの利用法は以下の2種類があります。

  • スタンドアローンクラスタ: 単体の k8s クラスタを構築して利用する
  • マネージメントクラスタ: k8s を管理する基盤を構築し、それがアプリを動かす k8s クラスタ(ワークロードクラスタ)を管理する

ようするに、前者は管理されない k8s クラスタをパパっと構築するというもので、後者は構築後のクラスタの構成変更やメンテなども踏まえて管理できるかたちで マネージド k8s 環境を構築するというものです。

以下に構成図を記載します。

 

バニラ k8s の Minikube のように利用するような使い方がスタンドアローンクラスタ方式であり、EKSやAKS、GKEといったマネージド k8s のように利用するのがマネージメントクラスタ方式だと思ってもらえばよいかと思います。

 

そして、このスタンドアローンクラスタとマネージメントクラスタは以下の環境に構築できます。

  • Docker
  • vSphere
  • AWS
  • Azure

オンプレミスの vSphere やパブリッククラウドの AWS/Azure は、これらのクラスタのノードに仮想マシンやインスタンスを利用します。一方、Docker はもう少し複雑で、Docker のコンテナとして k8s のノードを動作させて、そのうえで k8s の pod が動作します。いわゆる2階建てやネステッドと呼ばれる構成です。

スタンドアローンクラスタ及びマネージメントクラスタの構築をおこなうマシンには tanzu コマンドをインストールします。そのコマンドも Windows/Mac/Linux をサポートしています。

 

要件ごとの TCE の構成パターン

クラスタの利用法や、インフラ基盤、操作端末の種類など、TCE を利用するパターンには様々な構成がとれます。どういった構成を利用するのがよいかは利用者により異なるので、ここでは Tanzu 製品担当の SE である私が考えるおすすめパターンをいくつか紹介します。最初に結論を言ってしまいますが、おそらく以下の4パターンあたりのどれかに落ち着くと思います。

  • 2-3時間だけ使ってみたい場合: Windows/Mac の Docker 上にスタンドアローンクラスタの Docker 版を構築
  • 可能な限りお金をかけたくないが、マネージド k8s 環境を使いたい: Linux の Docker 上にマネージメントクラスタを構築
  • そこそこ大事なオンプレミス マネージド k8s 環境: vSphere 上にマネージメントクラスタを構築
  • そこそこ大事なパブリッククラウド マネージド k8s 環境: AWS/Azure 上にマネージメントクラスタを構築

1人のユーザーとしておすすめなのは、2つめと3つめのパターンとなります。1パターンめはクラスタ構築が面倒なので頻繁に利用するユーザー向きではありませんし、4パターンめはパブリッククラウドの月額利用料がそこそこかかってくるため、それなら AWS の EKS や Azure の AKS で良いと思われるからです。製品版の TKG が EKS や AKS の代わりに AWS や Azure で利用されることはよくありますが、それはどのクラウドでも同一操作体験の マネージド k8s を使いたいという要望からであり、正直なところ TCE のユーザーがそこまでやりたいというシナリオは稀有かと思います。

 

考慮するポイントは以下です。

  • そのクラスタは使い捨てか -> スタンドアローン(使い捨て) or マネージメントクラスタ(管理したい)
  • クラスタは大事か -> Docker(消えてもすぐ作ればいい) or vSphere/AWS/Azure
  • Dockerのマシンパワー -> Windows/Mac(非力) or Linux(強い)
  • どれぐらい基盤にお金をかけられるか -> Docker(タダがいい) or vSphere(すでに持ってる/試用版で60日) or AWS/Azure(毎月数万円払える)
  • ロードバランサーでのアプリ公開は必要か -> Docker(不要) or vSphere/AWS/Azure(必要)

分かりやすいことの解説はしませんが、注意が必要なポイントとしては将来的に解決するかもしれませんが、2021年10月現時点では「Docker上に TCE を構築すると、ホストの再起動などをすると使えなくなる」という点です。つまりノートPC上の Docker に TCE などを構築すると、すぐに使えなくなるので再構築が何度も必要です。Linux をベアメタル(intel nucみたいなマシンで用意)か仮想マシンなどで用意すれば、そんなに頻繁には停止しませんので再構築する機会もさほど多くないと思います。

なお、使い捨てのスタンドアローンクラスタでよい場合であっても、Windows/Mac の Docker は同スペックの Linux に比べてパワーがない点に注意してください。たとえば私は比較的新しい Core7 の 32G の MacBook Pro 16inch を使っていますが、それの 2コア, 12GB を割り当てている Docker Desktop よりも、家庭用デスクトップ PC にインストールした vSphere 上の 2コア 6GB の Ubuntu 仮想マシンの Docker のほうが、はるかに処理能力が高いです。スペックの関係で、私の Mac 上の Docker にはスタンドアローンクラスタは構築できるものの、マネージメントクラスタはインストールできませんでした。

最後にお金ですが、ハードウェア以外を完全無料を目指すなら Docker か vSphere の 60日試用版しか選択肢に入りません。なお、企業のIT部門で働いているかたであれば vSphere を間借りできるかもしれませんし、個人ユーザーであれば「VMUG advantage」を利用することで小遣い程度で1年間の vSphere ライセンスをもらえます(商用利用はアウト)。AWSやAzureはインスタンス代の支払いが必要ですが、短期間で構築から解体まですれば一般的に高額になりません。企業内の研修で1日だけ多数の k8s 環境を用意したいといった場合は便利かと思います。そこそこ大きな開発環境で安定的なマネージド k8s を利用したい組織は、vSphere の購入を検討してもらえると幸いです(笑)。

 

VMware というよりも私の個人的な見解となりますが、どういう組み合わせが使うのがよいかを表形式でまとめてみました。

◎がこの記事で紹介する構成パターンで、当然ながらおすすめなつかいかたです。○が技術的には可能だが、◎には劣る利用法。△は技術的には可能ですが、不便なのでおすすめしない利用法。そして X は技術的には可能なものの、使い物にならない利用法です。どの組み合わせでも一応動作しますが、2020年10月段階では「IaaS に Windows の Docker を使う構成は現在 experimental 扱い」なので注意してください。

◎から漏れた○の理由は、しっかりした IaaS 基盤があるのであれば、スタンドアローンクラスタよりもマネージメントクラスタを検討してよいからとなります。ただ、商用 IaaS の上で個人レベルでサクッと k8s を使いたい場合はスタンドアローンクラスタを利用いただいても全く問題ありません。チームでクラスタ共有する場合は機能豊富なマネージメントクラスタをおすすめします。

Windows と Mac でマネージメントクラスタの構成が X や △ になっています。X の理由は明確で、Windows や Mac といった頻繁に停止する環境で、長期運用を想定したマネージメントクラスタを、ホストが停止したら k8s ノードが消えるDocker 環境で利用することがナンセンスだからです。ただ、実運用ではなく操作感を確認したいという場合は問題ありません。構築する場合は Docker Desktop のリソース設定をかなり増やしてください。

また、マネージメントクラスタは個人が専有するというよりも、開発者や運用者が共有することが多いため、Windows や Mac をマネージメントクラスタの操作端末にしてしまうと他のユーザにとって不便です。簡単な CLI 操作をするだけなので、多数のユーザが利用できる Linux のほうがおすすめということで、Windows/Mac を操作端末にした vSphere/AWS/Azure 基盤のマネージメントクラスタ方式は△にしています。なお、Linux の代わりに Windows Server を remote desktop で使うシナリオも問題ないと思いますが、Docker の安定度を考えるとやはり Linux がおすすめです。

ここからはおすすめ構成の解説をします。

 

パターン1: Windows/Mac上の Docker にスタンドアローンクラスタの構築

この構成は一番お金がかからなく、この記事を読んでいるかたであれば誰でも利用できる使い方です。ただし、さきほど説明したように「TCE を Docker 上に構築したら、PCを再起動したら k8s が動作しなくなる」という問題があります。とりあえず試してみたく、なおかつ安定稼働させられる Linux を持っていない場合はパターン1を検討してください。

この構成は本来の TCE の役割からいうと、あまりおすすめできる利用法ではありません。この構成の代わりに OSS の kind などを利用してもよいかもしれません。

 

パターン2: Linux の Docker 上にマネージメントクラスタを構築

個人や中小企業などでも気軽に採用できるマネージド k8s 環境がこの構成となります。10万円程度の小型PCや、払い出された仮想マシンにインストールされた Linux があれば、TCE のマネージメントクラスタを導入することで、少し機能不足なものの k8s のライフサイクル管理を実現できるマネージド k8s 環境を利用できます。

ただし、この構成の問題点は以下があげられます。

  • Linux を再起動したら、マネージメントクラスタもワークロードクラスタも消滅する (コマンドで同一構成を再作成は可能)
  • Docker 上に k8s を構成するという2階建て構成なので、アプリを外部に公開しづらい (kubectl port-forward で公開可能)

これらの欠点を考慮すると、「パターン3を採用できない」かつ「すぐに作り直すことを許容できる場合の開発環境での利用」という場合に、第一候補となる構成かと思います。

 

パターン3: vSphere 上にマネージメントクラスタを構築

すでに VMware のお客様の場合は、このパターン3がおすすめです。製品版の TKG ほど機能豊富ではありませんが、安定した vSphere 上にマネージド k8s を構築するのでコンテナ基盤も安定しますし、パターン1や2のように TCE on Docker の構成(2階建て)になっていないので、metallb などの OSS を使うことでアプリを外部に公開することも簡単です。なお、vSphere はインストール後60日間は試用期間としてライセンスなしで利用できます。パターン2をよく利用するのであれば、この構成も試してみてください。

 

AWS/Azure 上にマネージメントクラスタを構築

vSphere 環境を持っておらず、AWS や Azure のインスタンス代の支払いに問題がない場合はパターン4がおすすめです。パブリッククラウドの強みを生かして、「必要なときに必要なサイズだけ利用する」といった利用法がおすすめです。

 

以上でこの記事を終了します。具体的な構築方法や利用方法は別の記事で紹介する予定です。ご拝読ありがとうございました。