
- ライター:奈良 昌紀
- 通信事業者のデータセンターにおいてネットワーク・サーバー運用を経験した後、ネットワンシステムズに入社。帯域制御やWAN高速化製品担当を経て、2008年から仮想化関連製品を担当。現在は主にクラウド、仮想インフラの管理、自動化、ネットワーク仮想化を担当。
目次
はじめに
サービスメッシュは、マイクロサービスアーキテクチャアプリケーションをKubernetesクラスター上で実行する際に、様々な機能を提供するために利用されています。(サービスメッシュの概要に関しては「サービスメッシュ入門」も合わせてご覧ください。)CNCF(Cloud Native Computing Foundation)の2020年の調査結果(CNCF Survey 2020)によると、サービスメッシュはすでに27%の組織がプロダクション環境で利用しており、サービスメッシュを実現するためのソフトウェアとしては、Istio、Linkerd、Consulの順に利用されています。これらのサービスメッシュプロダクトは単一のKubernetesクラスターにおいてサービスメッシュを実現するものでしたが、コンテナの活用が広まり、マルチクラスター環境でも利用することができるよう機能拡張が進められています。
本記事では、マルチクラスター環境におけるサービスメッシュソリューションとして、VMware Tanzu® Service Mesh™ Advanced Edition をご紹介します。
Tanzu Service Meshとは
Tanzu Service Meshはクラウドサービスとして提供されており、オンプレミスやパブリッククラウド等、様々な実行環境を横断して構成されるマイクロサービスアプリケーションの接続・監視・保護を実現します。
現在、Tanzu Service Meshは、VMwareのVMware Tanzu® Kubernetes Grid™以外にも、アップストリームKubernetesや、Amazon EKS、Azure Kubernetes Service、Google Kubernetes Engine、Red Hat OpenShift等のクラスターにも対応しています。
クラスターのオンボーディング
Tanzu Service MeshのGlobal ControllerにKubernetesクラスターを登録することで、クラスター間のサービスメッシュを実現することが可能になります。クラスターの登録(オンボーディング)は、Tanzu Service Mesh の管理画面のウイザードが提供するSecurity Tokenとyamlファイルをクラスターに適用します。
kubectl apply -f https://[tsm]/cluster-registration/k8s/operator-deployment.yaml kubectl -n vmware-system-tsm create secret generic cluster-token --from-literal=token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX...
yamlファイルによりTanzu Service Meshのオペレータが有効となり、管理画面上で「Install Tanzu Service Mesh」をクリックすることでオンボーディングの登録が完了します。

クラスターのオンボーディングが完了すると、Tanzu Service Meshのコンソールにクラスターが表示され、クラスターを構成するノードのリソース利用状況等を確認することが可能になります。

Tanzu Service MeshはVMware Tanzu® Mission Control™と連携することも可能となっており、VMware Tanzu Mission Controlの管理下にあるクラスターであれば、VMware Tanzu Mission ControlのIntegrationsメニューからわずか2クリックでクラスターをオンボーディングすることが可能です。

オンボーディングされたクラスターでは、VMware Tanzu Service Meshの管理に必要なコンポーネントとIstioが構成されます。
$ kubectl get pod -n istio-system NAME READY STATUS RESTARTS AGE allspark-telegraf-node-vb27p 1/1 Running 0 5m16s allspark-telegraf-node-x5srd 1/1 Running 0 5m16s allspark-telegraf-node-zj5cq 1/1 Running 0 5m16s istio-egressgateway-67f9448bc6-spw2s 1/1 Running 0 5m45s istio-egressgateway-67f9448bc6-t2mlz 1/1 Running 0 5m45s istio-ingressgateway-74684c9545-722kl 1/1 Running 0 5m45s istio-ingressgateway-74684c9545-jtf4h 1/1 Running 0 5m45s istio-telemetry-64c4b94447-kmd9w 2/2 Running 0 5m17s istio-telemetry-64c4b94447-wn826 2/2 Running 0 5m17s istiocoredns-7b57cbfcc8-8hq7l 2/2 Running 0 6m14s istiocoredns-7b57cbfcc8-w7wn6 2/2 Running 0 6m14s istiod-559554b7f8-2hs9v 1/1 Running 0 5m55s istiod-559554b7f8-87mr4 1/1 Running 0 5m56s $ kubectl get pod -n vmware-system-tsm NAME READY STATUS RESTARTS AGE allspark-ws-proxy-75bf454fb4-vqthj 1/1 Running 0 12m installer-job-6fvrs 0/1 Completed 0 6m40s k8s-cluster-manager-6b68458fb9-z7jnm 1/1 Running 0 12m operator-ecr-read-only--renew-token-gxpht 0/1 Completed 0 12m telegraf-istio-75b8547675-stc5f 1/1 Running 0 5m20s tsm-agent-operator-8cc8db46d-n7b6q 1/1 Running 0 12m
Global Namespaceの作成
オンボーディングされた各クラスターにそれぞれネームスペースを作成し、これらを一つのGlobal Namespaceに登録することで、クラスターを跨いでサービスメッシュを利用することが可能になります。
今回は、以下のようにVMware Tanzu Kubernetes Gridで作成した3つのKubernetesクラスター(tkc01/tkc02/tkc03)に、それぞれネームスペース(gnsdemo)を作成し、それぞれのネームスペース内にnginx podとサービスを作成してあります。これらをGlobal Namespaceとして構成してみます。

Global Namespaceのドメイン名としてgnsdemo.nos.local
を指定します。このドメイン名を利用してGlobal Namespace内の名前解決が可能になります。

Global Namespaceに参加するクラスターとネームスペースを選択します。ネームスペース内のサービスが認識されています。各クラスターで共通の名前のネームスペース名を選択する必要があります。

各クラスターにはnginx podとserviceを構成してあります。
$ kubectl --context tkc01 -n gnsdemo get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-tkc01-5df48bf55-7g28h 2/2 Running 0 118s 172.20.1.34 tkc01-default-nodepool-wxgpv-5b87967cc9-tjbgw
$ kubectl --context tkc01 -n gnsdemo get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-tkc01 ClusterIP 10.96.184.18580/TCP 100s
$ kubectl --context tkc02 -n gnsdemo get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-tkc02-57d5ccccfd-pqm2p 2/2 Running 0 105s 172.20.2.86 tkc02-default-nodepool-q5tn2-5f68c54cff-mgd4j
$ kubectl --context tkc02 -n gnsdemo get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-tkc02 ClusterIP 10.96.203.11780/TCP 91s
$ kubectl --context tkc03 -n gnsdemo get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-tkc03-c76bd8bc7-6dv5q 2/2 Running 0 102s 172.20.3.175 tkc03-default-nodepool-rqjwg-869dff8475-lz4mk
$ kubectl --context tkc03 -n gnsdemo get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-tkc03 ClusterIP 10.96.81.6880/TCP 88s
tkc01のnginx podから、tkc02/tkc03のnginxサービス対してnginx-tkc02.gnsdemo.nos.local
とnginx-tkc03.gnsdemo.nos.local
という名前でアクセスすることができました。同様に、tkc02からtkc01/tkc03、tkc03からtkc01/tkc02に対してもアクセスすることが可能でした。

$ kubectl --context tkc01 exec -it nginx-tkc01-5df48bf55-7g28h -- bash bash-5.0# curl nginx-tkc02.gnsdemo.nos.local Server address: 172.20.2.86:80 Server name: nginx-tkc02-57d5ccccfd-pqm2p Date: 01/Nov/2021:05:23:13 +0000 URI: / Request ID: 18d069e9b1bf74de0955ef461ff9f4b4
bash-5.0# curl nginx-tkc03.gnsdemo.nos.local Server address: 172.20.3.175:80 Server name: nginx-tkc03-c76bd8bc7-6dv5q Date: 01/Nov/2021:05:23:19 +0000 URI: / Request ID: 9fe7c4752021ae3c62a4c0de4785641b
各クラスター内のDNSサービスで、Global Namespace内のサービス名の名前解決を実現し、トラフィックは各クラスターのIstioが持つEgressGateway/IngressGatewayと呼ばれる機能を利用して他クラスターにルーティングされ、クラスターを跨ぐPod間の通信が実現されています。
サービスの公開
VMware Tanzu Service Meshの管理画面から、Global Namespace内のサービスをクラスター外部に公開することも可能です。サービスを公開するために、公開するサービスと、公開するURLを指定します。VMware Tanzu Service Meshは、外部のDNSサービスとしてAmazon Route 53、もしくはVMware NSX® Advanced Load Balancer™と連携することが可能です。公開URLとして利用するドメイン名は、これらのDNSサービスで管理されるドメインを利用します。

公開URLは、指定したドメインを管理するサービスにレコードとして登録されます。Amazon Route 53と連携している場合、以下のようにレコードが登録され、nginx.lab.netone.co.jp
というFQDNに対し、CNAMEを介して10.44.186.9というIPアドレスが返されます。

実際にクラスター外部からアクセスすると、公開したService(nginx-tkc01)配下にあるPodにアクセスすることができました。
$ curl nginx.lab.netone.co.jp Server address: 172.20.1.34:80 Server name: nginx-tkc01-5df48bf55-7g28h Date: 01/Nov/2021:08:49:42 +0000 URI: / Request ID: b077352e4a89124237714f7c8001f017
Global Namespaceは、異なるローケーションのクラスターに配置したサービスを公開することも可能です。公開されたサービスはDNSによるGSLB(広域負荷分散)構成となり、クラスター障害が発生した場合も、異なるクラスターでサービスを継続提供することが可能になります。
サービスの可視化
ここまで説明に利用したアプリケーションは非常にシンプルなものでしたが、VMwareがデモ用に公開しているマイクロサービスアプリケーションを3つのクラスターに分散して配置してみます。アプリケーションにアクセスしてトラフィックを生成すると、アプリケーションを構成する各サービスのトポロジーが表示され、サービス間のトラフィックの状況を確認することが可能です。

サービスのオートスケーリング
上記の通り、サービスメッシュを利用してKubernetesクラスターで管理される各種メトリックを収集することができるため、これらのメトリックを利用してサービスのオートスケールを構成することも可能です。CPU利用率や、サービスに対するリクエスト数をメトリックとして、一定の状況が継続した場合に、Pod数を動的に増減することが可能です。

まとめ
VMware Tanzu Service Meshを利用することにより、複数のKubernetesクラスターにおけるサービスメッシュ機能を統合管理し、マルチクラスター環境におけるサービスメッシュを実現することが可能であることをご紹介しました。今回は、オンプレミスのKubernetesクラスターにおける利用方法を中心にご紹介しましたが、VMware Tanzu Service Meshはマルチクラウド環境においても利用することが可能です。ネットワンシステムズでは、VMware Tanzu Service Meshを利用してマルチクラウド環境における検証を完了しており、現在ホワイトペーパーを作成中です。
なお、VMwareは2021年3月にサービスメッシュベースのAPIの可視化、セキュリティ対策を行うソリューションを提供するMesh7を買収しており、今後このMesh7の技術がAPI Management機能として統合され、マイクロサービスアプリケーションのセキュリティ機能が更に強化される見込みです。こちらの機能はVMworld 2021のセッションでデモが行われていました。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。