こんにちは。サイバーエージェントの杉浦です。
「5分でわかる!
この記事ではNetwork Service Meshとは何か、どういった仕組みで動くのか、そしてNetwork Service Meshのユースケースについて紹介し、最後にkindを使って実際にNetwork Service MeshをKubernetesクラスタで動かした様子について紹介します。
Network Service Meshとは
Network Service Meshとは、サービスメッシュのコンセプトをL2/
サービスメッシュでは各アプリケーションにプロキシを設置して、アプリケーション間のセキュアな接続性と、アプリケーション間の通信の制御・
Network Service Meshは設計上、Kubernetesクラスタ内の通信だけでなく、Kubernetesクラスタ間の通信に対しても適用できます。またそれだけではなく、各アプリケーションがKubernetesクラスタ・
Network Service Meshの仕組み
次はNetwork Service Meshの仕組みについて見ていきましょう。
Network Service MeshはClient・
1つ目のClientは文字通り通信を発生させる実体で、KubernetesにおけるPodやVM、物理サーバなどが該当します。
なお個々のClientはアプリケーションの識別子として用いられるSPIFFE IDによって認証されている必要があります。2つ目のEndpointはClientの通信先に該当するもので、Clientと同一あるいは異なるKubernetesクラスタにデプロイされたPodやVM、物理サーバが該当します。3つ目のVirtual Wire
Network Service Meshにおける通信経路の確立は、ClientからNetwork Service Meshのコントロールプレーン
ClientはNetwork Service Managerに対して、
ここでKubernetesクラスタにおける、Network Service Meshの利用方法を見てみましょう。KubernetesではNetwork Service Meshのインストール時に追加されるNetworkServiceカスタムリソースを利用します。
NetworkServiceリソースの例はこちらです。この例ではIP通信において、
---
apiVersion: networkservicemesh.io/v1
kind: NetworkService
metadata:
name: my-network-service
spec:
payload: IP
matches:
- source_selector:
app: sample
routes:
- destination_selector:
service: firewall
ここでKubernetesクラスタにおける、Network Service Meshの仕組みついてもう少し深く見ます。
まずはじめにClientからNetwork Service Meshにリクエストが送信されます。その後ClientとEndpointのPod内に、新しくネットワークインタフェースが作成されます。この別のネットワークインタフェースを作成する手法は、既存のネットワークインタフェースに対して影響を与えないため、CNIプラグインにより構築される既存のKubernetesクラスタのネットワーク環境に影響を与えません。
Network Service Meshのユースケース
Network Service Meshのユースケースの一つとしては、複数のワークロードを跨ぐVPNの構築があります。ClientとEndpointをそれぞれ別ワークロードにデプロイされているコンポーネントを指定することで、ユーザはそのコンポーネント間のみにネットワーク疎通性を持たせたVPNを構築できます。
またサービスチェイニングの実現方法の一つとしてのNetwork Service Meshの活用が期待されています。サービスチェイニングとは、ルータやファイアウォールといったネットワークサービスに対して、通信パケットを適切な順番で転送させる機能を指します。
Network Service MeshではClientとEndpointを指定することで、通信パケットの転送経路をユーザが指定できます。そのため、ネットワークサービスのPodに対して適切にラベルを付与し、Endpointとして指定することで、ユーザは通信パケットを特定の順番で転送できます。
特に昨今では、汎用的なマシン上で仮想マシンにネットワーク機能を持たせるVirtual Network Function
Endpointをラベルを使って指定できる仕組みは、KubernetesにおけるPodのような生成と削除が高頻度で行われ、IPアドレスが一つに定まらない環境においては有効に働くことが期待されています。
Network Service Meshを試してみる
それでは公式で用意されている例を使って、2つのKubernetesクラスタにそれぞれデプロイされたPod間で、実際にNetwork Service Meshを使った通信をさせてみます
今回使う実験環境を用意するスクリプトも用意しました。使用する際はkindとkubectlがインストールされた環境で以下のようにして実行してください。
$ curl https://raw.githubusercontent.com/chez-shanpu/nsm-demo/main/kind.yaml -O $ curl https://raw.githubusercontent.com/chez-shanpu/nsm-demo/main/setup.sh -O $ chmod +x ./setup.sh && sh ./setup.sh
この例では2つのKubernetesクラスタを用意し、クラスタ1にClient、クラスタ2にEndpointを用意し、このClient・
クラスタ1のClientから発行された、クラスタ2のgreeting Podへのリクエストは、NetworkServiceリソースによって構築されたvWireを経由してクラスタ2のEndpointに到達し、その後クラスタ2のネットワークでリクエストが転送されます。
このときClient・
# Client $ kubectl --kubeconfig cluster1.yaml exec deploy/alpine -- ip a Defaulted container "alpine" out of: alpine, cmd-nsc, cmd-nsc-init (init) 1: lo: <LOOPBACK,UP,LOWER_UP> … 2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> … 3: nsm-1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1440 qdisc mq state UNKNOWN qlen 500 link/[65534] inet 172.16.1.3/32 scope global nsm-1 valid_lft forever preferred_lft forever inet6 fe80::8e57:96e:d968:3c63/64 scope link flags 800 valid_lft forever preferred_lft forever # Endpoint $ kubectl --kubeconfig cluster2.yaml exec $(kubectl --kubeconfig cluster2.yaml get po |grep proxy |cut -d ' ' -f 1) -- ip a 1: lo: <LOOPBACK,UP,LOWER_UP> … 2: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> … 3: autoscale--1d96: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1440 qdisc mq state UNKNOWN qlen 500 link/[65534] inet 172.16.1.2/32 scope global autoscale--1d96 valid_lft forever preferred_lft forever inet6 fe80::41d:9636:913b:fc26/64 scope link flags 800 valid_lft forever preferred_lft forever
実際にクラスタ1にデプロイされたClientから、クラスタ2にデプロイされたアプリケーションにリクエストを送信すると、レスポンスが返ってくることが確認できます。
$ kubectl --kubeconfig cluster1.yaml exec deploy/alpine -c cmd-nsc -- curl -s greeting.default:9080 "hello world from istio"
公式サイトには他にも様々な例が用意されているので、よかったら触ってみてください。
結び
この記事ではNetwork Service MeshというL2/
CloudNativeな世界では、イミュータブルインフラストラクチャやマイクロサービスアーキテクチャの手法が普及し、アプリケーション間の通信ネットワークは大規模になるとともに、変化に対して柔軟かつ簡単に操作できることが求められるようになりました。このことに対して、Network Service Meshは各アプリケーションワークロードに紐づけられたメタデータを使うアプローチで、CloudNativeにおけるNetworkingの課題に対する解決策を提供してくれました。
Network Service Meshの開発状況はGrafanaダッシュボードで公開されています。開発開始以来、継続的に開発が進められている様子が見られ、今後の発展に期待したいと思います!