マルチクラスター環境におけるサービスメッシュ

はじめに

サービスメッシュは、マイクロサービスアーキテクチャアプリケーションを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.185           80/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.117           80/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.68           80/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のセッションでデモが行われていましたので興味がある方はご覧ください。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。