Tanzu アプリケーションのモダナイゼーション

触りながら学ぶ vSphere with Tanzu 第2回: vSphere Pod

はじめまして。VMware の伊藤です。Tanzu 製品のプラットフォームアーキテクトとして働いており、開発と運用双方の経験があります。今回は「触りながら学ぶ  vSphere with Tanzu」シリーズの第二回として vSphere Pod を操作しながら機能説明します。

vSphere Pod は一言で言ってしまうと VMware vSphere を構成する ESXi ホスト上で直接 Kubernetes （K8s）のワークロードを実行する技術です。おそらく多くの Kubernetes 実行環境は本シリーズの第一回で説明した「Tanzu Kubernetes Cluster（TKC）」と同じように「仮想マシンとして K8s のノード群をたちあげてクラスタを構築し、そのうえでコンテナを動かす」という構成かと思います。つまり、仮想マシンとコンテナという2階建ての構成になっているということです。一方、vSphere Pod はコンテナ用途に最適化された超軽量仮想マシンのうえでワークロード（Pod）を直接実行するという VMware ならではのテクノロジーです。

上記の図にあるように「Pod が ESXi 上で仮想マシンとして直接実行される」形態をとっています。言い方を変えると普通の K8s のように「ワーカーノード上に複数の Pod が共存する」という実行形式をとりません。そのため、Podレベルのパフォーマンスやアイソレーションに優れているという特徴があります。また、非常に小さいアプリケーションを動かすのに必要なリソースがTKC（冗長性を持ったマスターとワーカーノードを展開）に比べると小さいという特徴もあります。

 

ただし、注意が必要なのは「vSphere Pod が提供する K8s の機能が豊富ではない」という点です。たとえばHelmやIstioなどはvSphere Pod では利用できません。そういった背景がありますので、「vSphere with Tanzu で利用する K8s クラスタは、デフォルトでは一般的な K8s クラスタである TKC を利用する」とご認識ください。一般的な K8s アプリケーションが vSphere Pod では動作しない可能性があります。vSphere Pod の利用を検討する状況は、後ほど紹介する利用が適した場面とお考えください。

 

なお、2020年11月時点では、vSphere Pod は VMware NSX に強く依存しているため、vSphere with Tanzu （別名TKGS） の構築を vSphere Stack（HAProxy や AVI Lite をロードバランサーに利用）で実施すると使えません。vSphere Pod を利用したいのであれば、必ずロードバランサーを NSX としてTKGSの構築をおこなう必要がありますのでご注意ください。みなさんに触っていただくHOL環境はロードバランサーにNSXを使っていますので、問題なく vSphere Pod を利用できます。

vSphere Pod の概念と使い所

HOL にアクセスする前に vSphere Pod がどういったものか説明したいと思います。以下の図をみてください。

この図では vSphere（TKGS） の上に「スーパーバイザークラスター」という TKGS 自体の管理機能をアプリケーションとして実現するための K8s があります。このクラスタ自体でユーザーのワークロードを動かすのではなく、あくまでも TKGS の機能を実現するためのアプライアンスのようなものです。TKGS のうえには「ネームスペース」が置かれており、これは vSphere 上の K8s のリソースプールのような働きをします。仮想マシンのリソースプールのように誰がアクセスできて、どのような操作（編集or閲覧）ができ、どれほどのマシンリソースを消費できるかといったことを定義します。このリソースプール上に前回の記事で紹介した TKC（Tanzu Kubernetes Cluster）を展開するだけでなく、vSphere Pod を展開できます。

 

vSphere Pod はスーパーバイザーネームスペース上に一般的な K8s の Pod リソースと同様に展開されます。実際にはDeployment や Service リソースなどとともに利用されるでしょうが、その使い方は YAML で定義して kubectl apply コマンドで適用するという標準的な使い方です。また、ネームスペースレベルでどれだけのリソースが使えて、誰がアクセスできるか決めれるのも K8s らしい使い方です。このように、vSphere Pod がワークロードをどのように動かすかということは特殊であるものの、ユーザーとしての使い方は普通の K8s と大差ありません。このあたりは実際に機器を操作するなかで体感していただければと思います。

 

TKCは操作体系だけでなく内部構成も一般的な K8s ですので、ほとんどのユースケースに合致します。一方で、vSphere Pod は使うべき場面が限定的です。2020年12月時点では推奨される利用場面は以下が求められる場合です。詳しくはドキュメントを参照ください。

  • TKCのノード(マスター/ワーカー)が使用するCPUやメモリを削減したい。ESXi上で直接K8s Podを動作させるので、TKCのK8sノードとなる仮想マシン自体にリソースを使われません
  • Podレベルでの独立性が必要な場合。1つのPodに問題が起きても仮想マシンレベルで独立しているため、他のポッドに影響がありません
  • 1つのポッドで高いパフォーマンスが求められる場合。通常のK8sのポッドに比べて vSphere Pod は低いレイヤで動作します。マシンパワーや内部ネットワークのオーバーヘッドを減らせます。低遅延が求められたりモンスターPod（超巨大なPod）のような使い方をしたい場合です
  • Podを従来の仮想マシンのように監視したい場合。vCenterで直接監視できます

vSphere Podには上記のような強みがある一方で、VMware の独自色が強いことに起因する弱点もあります。一番大きなものとしては、シンプルな使い方（サービスとデプロイメント及びネットワークとストレージの利用など）以外では機能的な制約によりワークロードを実行できない可能性が標準的な K8s である TKC に比べると高いことです。たとえばIstioなどは利用できません。また、vSphere流の監視ができる一方で、K8s流のモニタリングは難しくなります。その次にTKCと異なり、様々な利用者が同じスーパーバイザークラスター上でワークロードを展開するため、1つのK8sクラスタが管理するワークロードが多くなりがちという問題点もあります。TKCはクラスタレベルで完全にワークロードを分離できますが、vSphere Podはそれができません。繰り返しますが、2020年12月時点では「TKGS上で利用する K8s クラスタのデフォルトは TKC とし、vSphere Pod はそれが必要な場面以外では利用しない」という運用をおすすめします。なお、vSphere Podは今後も機能拡張していく予定ですので、将来的にはその用途が増えることが予想されます。

 

vSphere Pod の展開

ここからは実際に弊社が提供するラボ環境で vSphere Pod を利用してもらうことで、その機能を実体験していただきたいと思います。以下のシナリオで進めていきます。

  1. VMware の HOL（Hands On Lab）のサイトにアクセスする
  2. vSphere with Tanzu のラボを開始する
  3. vSphere Pod のモジュール3（演習）に進む
  4. vSphere Client 上でスーパーバイザークラスターの構成を確認する
  5. kubectlコマンドでスーパーバイザークラスターに接続する
  6. vSphere Pod のワークロード（ウェブアプリ）を展開
  7. 展開したアプリにブラウザでアクセス
  8. vSphere Client 上で vSphere Pod の VM（Pod, コンテナ用）を確認

まず、上記ステップの1から3ですが、これは前回の記事に書いた HOL へのアクセス法を参照してください。

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

 

モジュール3にある「LOG IN TO VCENTER」を参照して、vSphere Client にログインします。そして、メニューの「Hosts and Clusters（おそらく初期画面がこれ）」から Namespaces（スーパーバイザーネームスペース一覧）および demo-app-01（スーパーバイザーネームスペースの1つ）を開きます。そうすると TKC である tkg-cluster-01 の下に3つの hello-kubernetes… という VM のようなものが見えると思いますが、これがvSphere Podです。

 

 

次に自分で vSphere Pod を展開します。そのためには、まずモジュール3の「LOGIN TO SUPERVISOR CLUSTER」に従って、kubectl コマンドでスーパーバイザークラスターにログインをおこないます。このコマンドの解説はシリーズ第一回で説明していますが、vSphere with Tanzu のIPを指定して、ユーザー名を指定してログインします。ログインすると Kubernetes のコンテキスト（複数のK8s環境を使い分けるための標準的な仕組み）が得られるので、スーパーバイザーコンテキストを指定してスーパーバイザークラスタを操作できる状態にします。

 

 

上記の例では接続先のスーパーバイザークラスターの IP は 192.168.124.1 であり、接続ユーザーは [email protected] です。そうすると、ユーザーが属するネームスペースである「demo-app-01」のコンテキストが得られました。そして、そのコンテキストに変更しています。

 

次に自分のアプリケーションを vSphere Podとして展開します。前回の復習も兼ねて説明すると「TKC のコンテキストで kubectl を使ってポッドを展開すると、TKC 上にポッドが展開される」「スーパーバイザーのネームスペースでポッドを展開すると、vSphere Pod がそのスーパーバイザーネームスペース上に展開される」という動きをします。サンプルアプリのマニュフェストが「~/labs/guestbook」にあるので、それを kubectl apply コマンドで展開してみます。

 

 

kubectl get pods コマンドや kubectl get svc コマンドの結果から、kubectl apply コマンドにより Pod（Deployment）と Service のリソースが展開されたことが確認できます。Pod が起動するまでに少し時間がかかっていますが、これはポッドの初回利用イメージを取得するダウンロード時間などが含まれるためです。サービス確認コマンドで確認しているサービスのタイプ:ロードバランザーとして公開された IP:192.168.124.3 （みなさまの環境では違うIPの可能性が高いです）にブラウザでアクセスすると、さきほど apply によりデプロイしたウェブサービスが動作していることが確認できます。

 

 

このアプリケーションを構成する Pod（コンテナ）は  vSphere Pod （vSphereの超軽量仮想マシン）として展開されているので、それを vSphere Client で確認してみます。今回利用したスーパーバイザークラスターの「demo-app-01」というネームスペースに着目してください。

 

 

先ほど確認した時に存在しなかった「frontend」「redis-master」「redis-slave」という3つの vSphere Pod が展開されていることが確認できました。これらは先ほど apply したマニュフェスト内で定義されています。

 

最後に展開したアプリケーションを通常の K8s のリソースのように削除をおこないます。kubectl delete でマニュフェストを指定してリソース削除をすると、CLI のレスポンスとしてリソースが削除されたことが確認でき、それに加えて vSphere Client 上からも vSphere Pod が削除されていることが確認できます。

 

 

以上で本記事の vSphere Pod の基本的な機能紹介を終えたいと思います。第1,2回は開発者目線の操作を中心に説明してきましたが、第3回では運用者側の視点で vSphere with Tanzu の管理と操作について紹介したいと思います。ご拝読ありがとうございました。

 

関連記事