Tanzu

触りながら学ぶ TKGm 第一回: マルチクラウド Kubernetes の実現

はじめまして。VMware の伊藤です。Tanzu 製品のプラットフォームアーキテクトとして働いており、開発と運用双方の経験があります。今回から VMware Tanzu の主要製品の1つである Tanzu Kubernetes Grid multi-cloud を実際に利用しながら学ぶという内容で4,5回のシリーズ記事を投稿したいと思います。初回は座学ベースで製品のコンセプトを扱いますが、第2回以降はVMwareが提供する無料のハンズオン環境を使って操作した内容を解説するというスタイルで進めます。

VMware のモダンアプリケーション開発に関わる製品群は Tanzu というラインナップにまとめられています。その Tanzu のKubernetes(K8s)製品は「Tanzu Kubernetes Grid」と呼ばれており、この連載で扱う「Tanzu Kubernetes Grid multi-cloud (TKGm)」はその1つです。TKGm 以外にも「vSphere with Tanzu」という類似製品があり、そちらの説明は別の連載で解説しています。

触りながら学ぶ vSphere with Tanzu 第1回: Tanzu Kubernetes Cluster

 

vSphere with Tanzu は vSphere 7 に高度に K8s をインテグレートすることで K8s の構築/管理コストを低減させるという特徴があります。一方、この連載で扱う TKGm は基盤へのインテグレートではなく、様々な場所で動く K8s 管理用のアプライアンス VM を使うことで IaaS 基盤の種類を問わずに K8s の構築/管理コストを低減させることを目的とした製品です。具体的には以下の図にあるように主要なパブリッククラウドである AWS や Azure (GCPなどは将来追加予定)、オンプレミスの vSphere で共通した K8s の管理/運用およびアプリケーション展開を実施できるようにします。

共通した K8s クラスタ管理方法(作成/変更/破棄)と利用方法(アプリの展開)を様々な IaaS 基盤で共通して実施できることは、K8s の利用者である開発エンジニアにとっても、K8s の構築/運用者である運用エンジニアにとっても望ましいことではないでしょうか。

 

セルフサービス型のKubernetes

TKGm 及び vSphere with Tanzu に共通した製品コンセプトは「セルフサービス型の K8s を提供する」というものです。セルフサービスは文字通り自分自身でサービス(K8s)を簡単に操作できるということであり、具体的には K8s の基盤自体を利用者が管理できます。たとえばクラスタを作成することや、変更(バージョンアップやスケールアップ)および削除できます。

仮にセルフサービス型を採用していなければ、開発者は K8s クラスタを利用したくなれば運用者に依頼し、アップグレードや削除といった操作も都度依頼しなければなりません。これはすぐに K8s を使いたい開発者にとっては待たされることを意味し、それと同時に作業を実施する運用者にとっては大きな作業負担がかかることを意味しています。

以下にセルフサービスでない運用者が構築管理する K8s 基盤と、VMware の TKGm が提供するセルフサービス型の K8s 基盤の比較図を記載します。

図にあるようにセルフサービス型の K8s 基盤を採用することで、今まで運用エンジニアが高いコストをかけて実施していたセットアップ作業や変更作業、不要になった際の後片付けを TKGm というプラットフォームが肩代わりしてくれていることがわかります。初期構築だけではなく手動で K8s 基盤のアップグレード等まで実施できるエンジニアはあまり多くないと思いますが、そういったレベルの高いエンジニアの手を煩わせずに基盤運用できるのは大きな強みです。また、人間に比べて機械的な処理をするプラットフォームは処理が高速なので、開発者が待たされることも大幅に減るという特徴があります。

 

ワークロードクラスタを管理するマネージメントクラスタ

Kubernetes 基盤をセルフサービスとして提供するには、その仕組が必要です。vSphere with Tanzu では、K8s をインテグレートしている vSphere 基盤自体がその役割を果たしていました。一方、AWS や Azure、vSphere といった様々な環境で動作する TKGm においては「IaaS基盤に依存しない管理方法」が必要となり、それを各基盤上に管理用のアプライアンスVMを展開するというかたちで実現しています。具体的には実際にアプリケーションを動かす K8s(ワークロードクラスタと呼ばれる)を管理する「管理専用の K8s(マネージメントクラスタと呼ばれる)」を展開します。

展開されたマネージメントクラスタにたいしてワークロードクラスタのライフサイクル管理の命令を実施することで、アプリケーションを実際に動かすクラスタを人の手を煩わせずに作成したり、変更したり、削除することができます。ワークロードクラスタの利用法は一般的なクラスタと全く変わらず、YAML で定義した K8s リソースを展開するだけです。

以下にマネージメントクラスタとワークロードクラスタの関係図を記載します。

最初に運用者がマネージメントクラスタを展開するという手間はかかりますが、そうすることにより以後発生する「アプリケーションを動かすための多くの K8s クラスタの基盤自体の維持管理」という重荷から開放されます。また、先ほども説明したように簡単な操作で K8s 基盤のライフサイクル管理を実現できるので、実際の K8s 基盤の利用者である開発者が自分自身で操作ができるようになります。

よくある利用例としては運用者が各開発チームごとにマネージメントクラスタを提供し、リソースプール(CPU やメモリの上限設定)のなかで好きに開発環境を構築してもらうという使い方です。一方で、本番環境のようなクリティカルな基盤は運用チーム自身が本番環境用のマネージメントクラスタで本番環境のワークロードクラスタを管理するというものです。

 

GUIツールによるマネージメントクラスタの展開

マネージメントクラスタの展開方法はこの連載の別記事にて扱いますが、ここでも簡単に紹介します。先ほど説明したようにマネージメントクラスタはアプライアンス VM として AWS や Azure、vSphere といった各 IaaS 基盤上に展開されます。ただ、展開方法はエンジニアが手動でアプライアンス VM をセットアップするというよりは、決められたパラメーター(たとえば vSphere であればどのリソースプールやネットワークを使うかなど)を指定し、それに沿ってインストーラーが勝手にアプライアンス VM(マネージメントクラスタ)を展開します。展開する IaaS 環境により求められるパラメーターは多少異なりますが、展開の流れは大筋として同じです。

以下にマネージメントクラスタの構築図を記載します。

図にあるように運用者のノート PC や作業用 VM などに TKG のインストーラー(正確にはマネージメントクラスタの操作ツール)をインストールし、それを使って GUI(上記図のブラウザ画面)もしくは CLI でマネージメントクラスタを各環境に構築します。この構築をおこなったマシンにはマネージメントクラスタにたいするアクセス権限が付与されますので、作業用 VM で構築してそれを利用者(開発者)に渡すのが簡単な運用方法かもしれません。開発者のマシンにたいしてマネージメントクラスタを操作する設定を施すことも可能です。

 

IaaS基盤ごとの差分を隠蔽するTKGm

AWS や Azure などの各クラウド基盤はそれぞれが独自のマネージド K8s を提供しています。具体的には AWS の Amazon EKS や、Azure の AKS などです。全ての K8s ベースのアプリケーションを1つのクラウド基盤に統一するのであれば、それぞれのマネージド K8s を利用するのはよい選択肢かと思います。ただ、オンプレやパブリックの様々なクラウドを併用したいのであれば、クラウドごとに異なるマネージド K8s の利用方法を覚えることは大きな負担となります。

そういったマルチクラウドを利用したい状況で、もし VMware の TKGm を利用して頂ければ様々なクラウドで統一した K8s 基盤の管理方法を実現し、K8s 基盤上で動くアプリケーションも大きな差分なく様々な環境に展開できるようになります。以下に統一されたワークロードクラスタの運用法と利用法の図を記載します。

 

TKGm を使えば、オンプレミスの開発環境で開発をおこないそれを AWS や Azure 上の本番環境に展開するといったことや、その逆を簡単に実現できます。そのため、アプリケーションが特定の IaaS 環境にロックインされてしまうリスクも低減できます。また、 TKGm や vSphere with Tanzu のワークロードクラスタ自体はベンダー色の強くない一般的な K8s ですので、TKG 上で開発した K8s アプリを VMware でない別の K8s 上で動作させることもさほど難しくありません。

そのため、強いベンダーロックインは避けたいものの、全て自分たちでスクラッチ構築する(高い技術力と人件費という運用コスト。サポートなし)という選択肢がとれない場合は、TKGm をロックイン性の弱いマネージド K8s として検討して頂ければと思います。

以上で第一回の記事を終えます。この連載では第二回ではワークロードクラスタの利用方法、第三回ではマネージメントクラスタの展開方法を扱います。第四回以降は K8s のネットワークやストレージに絡めた技術補足的な内容を扱う予定です。ご拝読ありがとうございました。