KubeCon Europe 2023から、Linkerdの最新情報とeBPFがサービスメッシュに使えない理由を解説したセッションを紹介

KubeCon＋CloudNativeCon Europe 2023から、サービスメッシュのプロジェクトであるLinkerdの最新情報を解説したセッションを紹介する。これはLinkerdの開発元のBuoyantのエンジニアであるMatei David氏が解説とデモを行ったものだ。

●セッションの動画：Overview and State of Linkerd - Matei David, Buoyant, Inc.

David氏はセッションの冒頭で「『サービスメッシュ』という言葉を聴いたことがある人はいる？ その中でサーキットブレーカーについて知ってる人は？」と参加者に問いかけ、セッションの中で新機能であるサーキットブレーカーについて説明したいという意図を見せる形からスタートした。

Linkerdについて説明するMatei David氏。事例としてMicrosoftが挙がっている点に注目

このスライドではLinkerdのユースケースとしてMicrosoftが挙げられているが、2023年5月24日にMicrosoft Azureにおける公式コンテナOSディストリビューションであるAzure Linuxの上で、Linkerdがサービスメッシュのソリューションとして採用され、サポートされることが発表された。AWSに次ぐポジションにいるAzureが、Azureで実行される公式のコンテナ用LinuxディストリビューションでLinkerdを認定したことには大きな意味がある。これまでIstioがIBMやCisco、Red Hatといった著名なベンダーに採用され、Linkerdは孤軍奮闘とも言える状況だったが、これでエンタープライズ向けにも利用が拡大していくだろう。

●参考：Buoyantのブログ：Announcing Linkerd as a validated service mesh for Azure Linux

Linkerdの基本機能を解説。何よりも軽量でシンプルなKubernetes専用のサービスメッシュだ

特にサイドカーで実装されるコンテナ内のproxyはRustで書かれたLinkerd2-proxyというモジュールで、Rustの最初期のユースケースとしても良く知られている。

Rustで書かれたコンテナにサイドカー実装されるLinkerd2-proxyの紹介

またIstioとの比較については、Istioは「さまざまなユースケースを想定して多くの機能を持つがその分、複雑で運用が非常に困難である」と説明。LinkerdはKubernetes専用でセキュア、軽量かつ高速なサービスメッシュであると説明した。

IstioとLinkerdの比較。「IBMのお勧めするものを採用してクビになったやつはいない」というのが利点のIstio

そしてLinkerd 2.11の機能の説明としてgRPCのリトライ機能について説明。

Linkerd 2.11のgRPCのリトライ機能を説明

次のスライドではLinkerd 2.13で導入されたサーキットブレーカーについて説明した。その際に、KubernetesのService Profilesを使わずにGateway APIで新たに導入されたHTTPRouteを使うことなども合わせて説明。ここではサービスメッシュに共通のAPIを定義することを目標として結成されたSMI（Service Mesh Interface）からGateway APIをサービスメッシュの運用管理に使うGAMMA（Gateway API for Mesh Management and Administration）にシフトしたことを語り、SMIプロジェクトの活動が事実上停止していることを語った。

Linkerd 2.13の機能を説明。SMIからGAMMAへ移行

サーキットブレーカーを解説するために実際にデモを見せて、負荷等によってエラーを返すPodをサービスの宛先から外す例を紹介した。これをシンプルな設定ファイルだけで実装できるのがLinkerdの利点だろう。

サーキットブレーカーのデモ

次に紹介したのはLinkerdの2.14とそれ以降の計画に関するスライドだ。

Linkerd 2.14ではクラスター内外へのトラフィックをLinkerdで実装する予定

ここではgRPCレベルのサーキットブレーカー機能、Proxy構成のより細かな設定、サービスメッシュの拡張、そしてクラスター内部のトラフィックではなく外部のサービスとのトラフィックをLinkerdのproxyで実装するという計画を説明した。

eBPFを実装したCNI準拠のネットワークスタックであるCiliumが、Pod間のトラフィックをCilium Meshで実行する流れとは逆のサービスメッシュのためのproxyがクラスターから外に向かうトラフィックを担当するということになるのだろう。Linkerdのシンプルな実装と運用をエンタープライズレベルに持ち上げていきたいというBuoyantの意図を感じるスライドとなった。

プレゼンテーションを行うMatei David氏

最後のQ＆Aでは「誰か、eBPFに関する質問をする人はいない？ その質問が出るまでQ＆Aを続けるから（笑）」として、このKubeCon Europe 2023のトピックとなったeBPFが、ネットワークやオブザーバービリティだけではなくサービスメッシュにも応用できるのでは？ という参加者の空気を読んだとも言えるコメントを行ったDavid氏だった。そして回答としては「フィルタリングやオブザーバービリティのためにeBPFが使えるのはそのとおりだと思うが、リトライやセキュリティなどを実装しなければいけないサービスメッシュでは、ステートを保持できないeBPFは使えないと思う」とコメントしてセッションを終えた。終了後も満員となったセッション会場で引き続き質問攻めになっていたDavid氏だったが、参加者からの確かなリアクションに満足していたようだった。

最後に余談となるが、Istioを使ったセッションに参加した感想とコメントを記しておこう。そのセッションでは登壇者のプレゼンテーションとデモがクラウドネイティブというよりも手間暇をかけた手工芸品的な内容だったため、セッション後に「Istioを使ったシステムのプレゼンテーションとデモがいわゆるペットと家畜の比喩で言うところのペットだったのはなぜですか？」と質問を向けたところ「そもそもIstioを使うことは決まっていた。弊社は金融サービスなので投資を行うVCに対して有力ベンダーが支持するIstioを使っておけば文句は出ないから。でもIstioの運用はとても面倒で難しかった」というコメントを貰った。

運用が難しいのはわかっていたが、それよりもブランド力を重視したということだろう。Matei David氏がいうIstioの利点「IBMが提案するシステムを採用してクビになったヤツはいない」をリアルで体験することとなった。

オンプレミスの実装だけではなく、マネージドサービスのLinkerdに関する公式トレーニングコースも用意され、Microsoftからの追い風とGateway APIとのシナジーを利用することでさらなる飛躍がLinkerdに起きるのか、注意深く見守っていきたい。