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

触りながら学ぶ TKGm 第3回: マイクロサービスアプリケーションの展開

はじめまして。VMware の伊藤です。Tanzu 製品のプラットフォームアーキテクトとして働いており、開発と運用双方の経験があります。触りながら学ぶ TKGm の第三回ではハンズオン環境に事前に用意されたマイクロサービスアプリを展開し、そのなかで一般的な Kubernetes や TKGm の解説をおこないます。

第3回では TKGm でアプリケーションを展開する Kubernetes クラスタである「ワークロードクラスタ」にたいして、実際にアプリを展開します。その作業を通して Kubernetes の基礎概念について説明します。

この記事では以下の構成でアプリ(Pod)を展開します。

 

外部に公開する手法はいくつかありますが、今回は Ingress(イングレス) を利用します。Ingress がアプリの実体が動く Pod 群宛に通信を転送しますが、それを Pod 群の代表IPとして働くサービス経由でおこないます。具体的な話は後ほど扱います。

なお、オリジナルのハンズオンラボにはイングレスの説明が少なかったため、本記事では最後にイングレス自体に関する解説を追加しています。イングレスに関する知識に不安があれば、先にそちらを参考にしていただいたほうが分かりやすいかもしれません。

 

マイクロサービスアプリ

アプリの公開作業のまえに今回のお題である「マイクロサービス」のアプリがどのようなものか説明します。

マイクロサービスアプリケーションはその名前にあるように「小さな」「サービス(独立して動作するアプリの一部)」から構成されるアプリです。たとえば従来のJavaアプリが1つの jar ファイルをアプリサーバーとして起動することで実現されているのであれば、マイクロサービスではそれを小さな4つの jar ファイルから構成されるサービスとして構成し、全体で1つのアプリになるといった具合です。

このマイクロサービスのアプリに Kubernetes は向いていて、サービスを構成するパーツを「リソース」や「オブジェクト」として定義できます。その定義には一般的に YAML がもちいられ、その YAML で書かれた定義をクラスタにたいして適用することで、定義されたとおりにアプリを構成するリソースが展開されます。

以下に概要図を記載します。

 

ここでは YAML に定義された青色の X アプリと、紫色の Y アプリを Kubernetes クラスタに展開しています。右側のワーカーノード上に定義されたコンテナイメージが定義された数だけ展開されていることがわかります。今までの仮想マシンベースのアプリ運用であれば、「コンテナイメージに相当する仮想マシンを手動なりスクリプトなりで構築する」ことを、必要な数だけ繰り返すことによりアプリを構築していました。ただ、上記の Kubernetes の例では事前に用意されたコンテナイメージを指定して、デプロイする数を定義して適用するだけで自動で展開されます。

 

YAMLに定義されたアプリケーションの展開

ここからは実際にアプリの展開作業にはいります。まず学習用のハンズオン環境にアクセスしますので、第2回の資料に沿って VMware HOL を開始してください。

触りながら学ぶ TKGm 第2回: ワークロードクラスタの管理操作

 

ハンズオンを開始したらマニュアルの Module4 の「Deploying a Microservice Based Application」に進んでください。Module4で使う環境は最初から構築されていますので、Module3 までは飛ばしてしまって問題ありません。

ハンズオン環境でマニュアルに沿って操作端末であるLinuxにログインし、操作する Kubernetes の確認をおこないます。「kubectl config get-contexts」コマンドで、この端末が認識しているクラスタの一覧と、現在選択されているクラスタが確認できます。この「どのクラスタを使うか」という状態を Kubernetes では「コンテキスト」と読んでいます。

事前に用意されているワークロードクラスタである「tkg-workload」にコンテキストが向けられているので、その状態で「kubectl get nodes」コマンドを打てば「tkg-workload」のノード一覧が得られます。異なるクラスタにコンテキストが向けられていれば、その異なるクラスタのノード一覧を得ることもできます。

 

コンテキストとノードの確認が済んだので、展開するアプリのYAMLを確認します。YAMLは事前に「~/.lab/kuard-config.yaml」として用意されています。

これを cat コマンドで確認してみます。

上から順に説明していきます。

  1. cat コマンドで YAML の中身を画面出力
  2. Kubernetes の Deployment リソースの定義。内部にアプリを動かす Pod のコンテナイメージの定義(image)と、いくつのポッドを展開するかの定義(replicas)がされている
  3. ポッドにたいして接続をおこなうための Service リソースの定義。80番ポートで受けた通信を、名前で結び付けられた先ほどの Pod の8080番ポートに転送
  4. サービスにたいして外部からの接続を提供する Ingress の定義。名前で結び付けられたさきほどのサービスの80番ポートにたいして通信を転送

という定義がされています。

簡単な概念図にまとめると以下のような構成となっています。

 

まず、Kubernetes クラスタの外部で通用する IP を持つ Ingress が、その IP あての通信を受け取ります。Ingress はそれをサービス(SVC)にたいして転送し、サービスは結び付けられた Pod にたいして転送するという流れです。

それでは、この定義されているリソースを展開します。Kubernetes のリソースはnamespace(名前空間)という単位で分離でき、今回は展開するアプリ名の namespace を「kubectl create namespace」コマンドで作成して、そこにYAMLで定義されたデプロイメントとサービスとイングレスを「kubectl apply -f ファイル名 -n ネームスペース」で展開しています。

 

上から順に

  1. namespace 一覧の確認
  2. namespace の作成
  3. リソースの展開
  4. ネームスペースの確認(Step1 で作ったものが追加されている)
  5. ネームスペースの Pod の確認(YAML 定義どおりに Step3 で作ったものがある)

となっています。

 

リソースの更新と外部接続の確認

このアプリはすでに稼働しているので確認できますが、そのまえにアプリ構成を変更します。さきほどはデプロイメントの定義でポッドを3つ展開するとしていましたが、それを4に変更します。

 

YAML の定義ファイルを更新したら、それを Kubernetes クラスタにたいして再適用します。そうすると、展開されるポッドの数が3から4に変更されます。

 

Age にあるアプリの起動時間をみると、「kubectl apply」による最適用語に起動時間が短い新しい4つめの Pod が確認できます。新設した4つめの Pod も、既存の3つも通信は全て結び付けられたサービス経由でロードバランスされて届けられます。つまり、Pod 上のアプリは Pod がいくつ存在する(アクセスするIPをPodごとに変更)かを気にせず、サービス(1つの代表IP)にたいして通信すれば、Pod がいくつあろうと変わりなく通信できます。

Pod の増設をしたのと同じように、YAML に定義する Pod 数を減らして縮退させることも可能です。アプリの負荷が増えれば Pod を増やしてパフォーマンスを向上させ、負荷が減ったら Pod を減らしてマシンリソース(お金がかかる)を減らすといったことを簡単に実現できます。同じことを仮想マシンでやろうと思うと、増設のマシン準備や縮退時のリソース回収に加えてロードバランサーの転送設定の変更が必要なので面倒です。

次に公開されているアプリのネットワーク(Ingressとサービス)の確認をします。

 

Ingress(ing)の項目をみると、namespace の kuard に Address として192.168.100.51が確認できます。これは Kubernetes の内部で使う IP ではなく、外部に公開されている IP(VMwareのHOL環境のみで使えるPrivate IP)です。

その次のサービス(svc)の項目をみると、namespace の kuard にサービスが作成されていることがわかります。

kuard の Ingress は kuard のサービスに結び付けられており、kuard のサービスは展開したポッドにに結び付けられていますので、Ingress の IP にたいしてブラウザでアクセスすると、以下のように Pod として動作しているアプリにアクセスできます。

 

IngressとContourについて

Kubernetes の Deployment(デプロイメント)や Pod(ポッド)および Service(サービス)は、Kubernetes でアプリを構築するのに必要不可欠なリソースです。そのため、Kubernetes を少し勉強したことがあるひとであれば聞いたことがあるかもしれません。一方、今回利用した Ingress は利用が必須ではないため初めてその名前を聞いたかたがいらっしゃるかもしれません。

Ingress は K8s 以前の既存技術でたとえるとロードバランサーやリバースプロキシーに近いです。Kubernetes クラスタの外部からの通信をアプリに届けるという点ではサービスのタイプ:ロードバランサー(いわゆるL4 Loadbalancer)に似ていますが、L4 Loadbalancer は「外部 IP で通信を受けて結び付けられた複数の Pod に通信をロードバランスして転送する」というシンプルな機能しか提供していません。

一方で、Ingress は「L7(HTTP/HTTPS)の情報にもとづいて通信トラフィックを制御できる」という機能を提供しています。その制御を具体的にいうと、以下のようなものです。

  • HTTPのURL(パス)などに応じて通信先のサービスを選択
  • HTTPのドメインに応じて通信先のサービスを選択
  • HTTPSの証明書とオフロード(SSL終端)
  • Blue/Greenデプロイメント

こういった処理はアプリを公開する際に利用することが多いですが、必ずしも Ingress を使わなくても実現できます。実際に現在では商用のファイアウォール製品などはこのあたりの機能を提供しており、多くのユーザーはそれを使っています。ただ、Kubernetes とファイアウォールを同時運用するスタイルでこれを実現すると、アプリのデプロイや更新のたびにファイアウォールの設定変更が必要になるため、スピード感がありません。一方、Ingress で実現するのであればアプリの更新と同時に機能設定の変更も即座に反映できるため、スピード感があります。

詳しい Ingress の説明は Kubernetes の公式ドキュメントなどをご参照ください。

Ingress

 

以上のように、Ingress は適切に利用すれば便利な存在です。ただ、Ingress は K8s クラスタに必須の機能ではなく多くの環境ではクラスタの構築直後には利用できません。そのため、Ingress を実現するための機能を K8s 的に YAML で展開していくことで導入します。

VMware の TKGm でも構築直後に導入されておらず、追加インストールするという流れは同じです。ただ、その導入をお客様自身でオープンソースのものや商用版製品を導入することで解決しなくても、TKG が拡張機能(extensions)というかたちで提供しています。TKGm Extensions の導入ガイドに沿って、VMware が用意した YAML をクラスタに適用するかたちで商用サポート付きの Ingress をすぐに利用できます。

なお、VMware が提供する Ingress は「Contour をコントローラー(制御の中心)とし、Envoy をデータプレーン(トラフィックの転送)」とする構成となります。Contour は2017年にリリースされてから開発され続けている高度なルーティング機能を提供しており、Envoy も他の Ingress コントローラーで多く採用される標準的なコンポーネントとなります。Contour を使った Ingress の詳細は別記事にて将来的に扱う予定です。

 

Ingressの構成

最後に参考情報としてみなさまに操作していただいたKubernetes環境と、その上で動くアプリ環境の構成を図にまとめます。これは先ほどの Ingress と SVC と POD の構成図をもう少し詳細にしたもので、Ingress (この構成ではContour + Envoy)にたいする通信がどのように実現されているか記されています。

今回は Ingress が最初から準備されていたため詳細が隠されていましたが、このワークロードクラスタには L4 ロードバランサとして Metallb がインストールされており、Ingress (ContourとEnvoy)がそれを使う設定がされています。

そのため、Ingress までの通信は以下の手順でおこなわれています。

  1. Ingress リソースが作成される
  2. Ingress がL4 Loadbalancerを作成し、そこで外部IPを使えるようになる
  3. ノードに Loadbalancer の IP に到着した通信は Ingress に届けられ、Ingress から Pod のサービスに届けられる

この Ingress が Loadbalancer を使う設定はさきほどの「kubectl get svc -A」の namespace の projectcontour からも確認できます。

 

以上で TKGm の第3回の記事を終了いたします。第4回では HOL のマネージメントクラスタ構築の module を実施をとおして、マネージメントクラスタ展開の手法や概念を説明します。

関連記事