KubeCon NA 2020 LinkerdとAmbassadorを使ったマルチクラスター通信を紹介

連載 [第5回] :

KubeCon＋CloudNativeCon North America 2020レポート

2021年3月23日(火)

LinkerdとAmbassadorを使ったマルチクラスターの実装例を、BuoyantとAmbassador Labsのエンジニアが紹介した。

今回は、KubeCon＋CloudNativeCon NA 2020からKubernetesのマルチクラスターに関するセッションを紹介する。これはサービスメッシュのLinkerdとKubernetesに特化したAPI GatewayのAmbassadorを組み合わせて実装したデモを解説するものだ。スピーカーはLinkerdの開発元であるBuoyantのエンジニアThomas Rampelberg氏と、Ambassadorを開発するAmbassador LabsのエンジニアDaniel Bryant氏だ。Ambassador Labsは、以前にはDatawireという社名で知られていたが、社名を変更して開発を行うソフトウェアの名前に合わせている。

これはNGINXをベースにしたAPI GatewayであるKongを開発する母体の企業が、かつての名称MashapeからKongにリブランディングしたことと類似しているのは偶然だろう。

セッションへのリンク：Multi-Cluster is Easier Than You Think with Linkerd and Ambassador - Thomas Rampelberg, Buoyant & Daniel Bryant, Datawire

「LinkerdとAmbassadorを使えばマルチクラスターは思ったより簡単」というタイトル

Multi-Cluster the easy way

セッションのタイトルが示すように、Kubernetesでマルチクラスターを構成する方法をLinkerdとAmbassadorを使って説明するのが主な内容だ。スピーカーは、前述のようにAmbassador LabsとBuoyantのエンジニアが担当している。

セッションを担当するエンジニアの紹介

Multi-Cluster the easy way

ここで「Multi-Cluster the easy way」とあるのは、GoogleのエンジニアKelsey Hightower氏による「Kubernetes the hard way」に引っ掛けたものだろう。Kubernetes the hard wayはKubernetesの導入と設定をすべてマニュアルで行うことで、Kubernetesの基本を学ぶためのチュートリアルだ。

参考：Kubernetes The Hard Way

そしてここからは、3つのステップに沿ってデモを交えてマルチクラスターを構成するやり方を解説するフェーズとなった。最初のステップは「サービスディスカバリー」だ。デモの構成としてはGoogleのマネージドサービスであるGKEに「East」と称したKubernetesクラスターを置き、ローカルのMacBookのDocker Desktop上に「West」と名付けたクラスターを構築する。そしてそれらをマルチクラスターとして構成するのがこのデモの目的である。

左にフロントエンドによるWebページ、右上にGKEの、右下にDocker Desktopのコンソールが表示されている

デモを担当するのはAmbassador LabsのDaniel Bryant氏だ。このデモではフロントエンドとバックエンドのPodがお互いに通信し、Webページを表示するだけのものだ。ここでは一つのクラスターから別のクラスターに通信させるデモで、マルチクラスター実装の準備を行うことになる。そのための最初の一歩がサービスディスカバリーだ。このスクリーンショットでは右のコンソールにはそれぞれFrontendとPodinfoという2つのサービスがEastとWestのクラスターに起動されていることがわかる。

K8s Initializerを紹介

Bryant氏は、Ambassador Labsが提供するK8s Initializerという必要なYAMLファイルを簡単に生成できるサービスを使って、Kubernetes導入に必要な要素を解説した。K8s InitializerはパブリッククラウドのマネージドからDocker Desktop上のKubernetesまで対応しており、Ambassador Edge Stackをコアとして導入するためのユーティリティとも言えるものだ。

Ambassador Labsにとってみれば、Ambassadorを中心として予め用意された構成で簡単にKubernetesクラスターを実装するYAML生成ツールを紹介し、Kubernetesのために多くのコンポーネントが必要になることを見せたと言える。

以下のリンクからAmbassador Labsが提供するK8s Initializerを試用できる。プラットフォームを選択してIngress、Authentication、Observability、CI/CD、Serverless、ServiceMeshまでカバーするだけで、数千行から数万行のYAMLファイルが必要になることがわかる。

K8s Initializer：K8s Initializer

K8s Initializerの解説：Let Developers Try Your Demo at Home

K8s Initializerで生成されたYAMLファイルを適用してLinkerdを実装したのが、次のスクリーンショットだ。

LinkerdをGKEとDocker Desktopにインストール

クラスター間のサービスディスカバリー

そしてここから、ローカルのDocker Desktop（West）に実装されたバックエンドに当たるpodinfo-eastがGKE上のクラスターEastに実装されたバックエンドpodinfoを見つけるサービスディスカバリーを解説する。このスライドではローカルのクラスターにデプロイされたサービスを解説しているところだ。同じクラスター上であれば、Kubernetes 1.13以降のデフォルトであるCoreDNSを使って簡単にサービスを見つけられるが、異なるクラスターの場合それは簡単ではないというのが前段の説明だ。

デモで使用するKubernetesのサービスを表示

Rampelburg氏は強制的にローカルのクラスターからGKE上のクラスターのPodを使うためのKubectlコマンドを紹介した。

コマンドで強制的に設定することも可能

しかしこの方法では運用上の不都合が多いとして、同じことをLinkerdで実装する方法を紹介した。

LinkerdのService Mirrorを使ってクラスター間の通信を実装

Linkerdのマルチクラスターは、Service MirrorとGatewayによって実装されている。Service Mirrorが常に相手のクラスターのAPI Serverの変更を検知して更新し、実際の通信はGatewayが行うという方法だ。より詳しくは以下のBuoyantのドキュメントを参照されたい。

参考：Multi-cluster communication

そしてクラスターをまたがったアクセスについては、Ambassadorが実装することになる。GKE上のAmbassadorがIngressとして実装され、ローカルのDocker Desktopクラスターに実装されたPod（podinfo-east）からGKEのAmbassadorにLinkerdではデフォルトとなるmTLSで通信を行うことを紹介した。

クラスター間をmTLSで通信

Linkerdのコマンドラインを使って実装を行ったのがデモの動画になるが、実際にステータスが見られるようすも紹介された。以下のスクリーンショットはLinkerdのマルチクラスターの状態をチェックした結果を表示している。

Linkerdのステータスを表示

またサービスメッシュの相互運用性を高めるための仕様であるSMI（Service Mesh Interface）を使って、トラフィックの配分を変えられることも紹介された。これはKubernetesのデフォルトではないことを説明した上で、KubernetesのCRDを利用したネイティブの実装であることを解説した。

SMIを使ってトラフィックの配分を変えることができる

これでローカルのクラスター上のpodinfoから、SMIを使って50:50の配分でAmbassadorを経由したpodinfo-eastを使うことができることを解説した。

LinkerdとAmbassadorを使ってマルチクラスターのサービス通信をデモ

マルチクラスターで何ができるか？

ここからは「マルチクラスターによって何が可能になるのか？」という最後のProfitの部分の説明となる。最初の例はクラスターの一部を分離する利用例だ。これはECサイトなどでクレジットカードの決済などの部分だけをセキュアでコンプライアンスが確保されたクラスターに分離することで、その他の機能と区分けできる。

クラスターを用途に応じて分離する例

次の利用例はディザスターリカバリーの例だ。ここで紹介されたのはPrimaryのクラスターからBackupのクラスターにPodのトラフィックを振り替える例だが、実際にPodに障害がない場合でも大幅な構成変更をせずにプライマリーからバックアップにトラフィックを分けて運用可能であることが利点として強調された。

ディザスターリカバリーの例

Rampelburg氏が一番好きな利用例として挙げたのが、開発環境におけるマルチクラスターの実装例だ。ここではローカルのマシンで新しいサービスのmy-serviceを開発し、必要に応じて別のサービスやユーザーデータにアクセスするルートを用意することで、すべてのサービスをローカルにコピーしなくても開発がスムーズに進められるとした。サービスメッシュのコンポーネントであるLinkerdの開発元らしいコメントをしていたのが印象的だ。