クラウドネイティブ
Linkerd解説：邪魔をしないサービスメッシュ
Linkerd実務者ガイド — RustベースのマイクロプロキシがIstioと何が違うのか、どんな場面で優れているのか、そして本番環境でどう運用するか。
Todea Engineering
クラウドネイティブ・プラクティス
ほとんどのチームは、Kubernetesディストリビューションを選ぶのと同じ方法でサービスメッシュを選びます。つまり、RFPで最初に名前が挙がったものを選ぶのです。その結果、3つのサービスのためだけにIstioがデプロイされ、Linkerdなら午後一度で解決できたはずの問題に対して見過ごされることになります。
LinkerdはEnvoyを基盤としない唯一のCNCF卒業サービスメッシュです。その設計のすべては、この一つの決定から派生しています。
Linkerdとは実際に何か
Linkerdは、linkerd2-proxyと呼ばれる専用のRustベースのマイクロプロキシを中心に構築された、Kubernetes向けのサービスメッシュです。ほぼ何でもできる汎用L7プロキシであるEnvoyとは異なり、linkerd2-proxyはサイドカーが実際に必要とするものだけを実装しています。メンテナーたちは、機能の幅よりも、より小さく予測可能なプロキシを優先して、この方針を意図的に維持しています。
その狭いスコープこそが製品の本質です。プロキシはメモリフットプリントが小さく、テールレイテンシが予測可能で、設定項目は頭の中に収まる程度に小さく抑えられています。
ほとんどのチームにとって、これは正しいトレードオフです。WASMフィルター、マルチプロトコルゲートウェイ、あるいはIstio固有の拡張機能に依存するワークロードを運用しているチームにとっては、そうではありません。
仕組み
Linkerdは他のすべてのメッシュと同じ2プレーンアーキテクチャに従います：
- データプレーン — メッシュ化されたすべてのPodにサイドカーとして注入される
linkerd2-proxy。iptablesルールを書き換えるinitコンテナを介して、すべてのTCPトラフィックを透過的にインターセプトします。 - コントロールプレーン — プロキシにサービスディスカバリーとポリシーをストリーミングし、mTLS用の短命ワークロード証明書を発行し、アドミッション時にPodスペックを変更してサイドカーを注入する、少数のコントローラー（destination、identity、proxy-injector）。
サービスAがサービスBを呼び出す場合：
- Aから
b.default.svc.cluster.localへのリクエストは、linkerd-initinitコンテナ、またはCNIモードインストールの場合はlinkerd-cniDaemonSetによってインストールされたiptablesルールによって、Aのサイドカーにリダイレクトされます。 - Aのサイドカーは、
destinationコントローラーからすでにストリーミングされているエンドポイントに対してBを解決し、ワークロード証明書を使ってBのいずれかのPodへmTLS接続を開きます。その証明書は、プロキシ起動時にidentityによって発行され、24時間ごとにidentityに対して更新されます。 - Bのサイドカーは mTLS を終端し、policyコントローラーからストリーミングされているインバウンドポリシーに対してクライアントのワークロードIDを検証し、許可されていればループバック経由でBにリクエストを転送します。
アプリケーションコードは変更されません。サービス間のすべてのバイトが認証され、暗号化され、観測可能です。
コントロールプレーン
コントロールプレーンは3つのDeploymentで構成されており、それぞれがメッシュの異なる側面をカバーします。各Deploymentは独自のlinkerd-proxyサイドカーの背後で動作し、mTLSを提供します。つまりコントロールプレーンも、ワークロードと同じようにメッシュ化されています。
-
identity: メッシュ化されたPodが起動すると、そのプロキシはPodのKubernetes ServiceAccountトークンで署名された証明書署名要求（CSR）を送信します。identityは、APIサーバーへのTokenReview呼び出し（identity.l5d.ioaudienceを使用）でトークンを検証し、短命（24時間）のワークロード証明書を発行します。 -
destination: 「このサービスを支えているエンドポイントはどれで、何を知っておくべきか？」という問いに答えます。プロキシがb.default.svc.cluster.local:80のようなauthorityを初めて解決する必要があるとき、destinationへ長命なgRPCGetストリームを開き、プッシュ更新を受け取ります：準備完了のエンドポイントアドレスに加え、それぞれにTLS ID、プロトコルヒント（HTTP/2アップグレード、opaqueポート、opaque-transportインバウンドポート）、メトリックラベル、ウェイトが注記されています。並列のGetProfileストリームは、ServiceProfileからサービスごとのルーティング設定を返します。 -
policy: プロキシに2つのgRPC APIを提供します：各サイドカーが（リスニングポートごとに1回）watchするInboundPoliciesAPI（どのクライアントIDがどのルートで許可されるかを学習）と、各サイドカーが（呼び出すauthorityごとに1回）watchするOutboundPoliciesAPI（ルーティングルール、リトライ、タイムアウト、サーキットブレーカー、レート制限を取得）。認可の判断は、キャッシュされたポリシーに対してプロキシのローカルで行われます。 -
sp-validator:ServiceProfileCRDのvalidating admission webhookです。 -
proxy-injector: mutating admission webhookです。そのMutatingWebhookConfigurationは、設定されたnamespaceSelectorに一致する名前空間内のPodとServiceのすべてのCREATEを購読します。APIサーバーがwebhookを呼び出すと、ハンドラーはオブジェクトにlinkerd.io/inject: enabled（Podまたはその名前空間上）があるかを検査し、存在する場合はPodスペックにlinkerd-proxyコンテナを追加するためのパッチを適用します。
運用の現実
-
トラストアンカーのローテーション。 ルートCAの有効期限は、Step、AWS Private CA、上流からcert-managerで発行するなど、どれを使ったかに関係なく、生成時に設定した値です。Linkerdはアンカーが期限切れになるまでワークロード証明書を発行し続け、その後すべてが停止します。有効期限を記録し、リマインダーを設定し、インシデント中に必要になる前にローテーションフローを練習しておいてください。
-
マルチクラスター。
linkerd-multicluster拡張機能は堅実ですが、ゲートウェイベースのリンキング、フラットPodネットワーク、フェデレーテッドサービスなど、それぞれ独自のトレードオフを持つ複数のトポロジーをサポートしています。ゲートウェイベースは、追加のホップと運用すべきゲートウェイPodという代償で、あらゆるネットワーク境界（別々のVPC、同一CIDR）にまたがって動作します。フラットとフェデレーテッドはゲートウェイをスキップしてレイテンシを下げますが、どちらもクラスタ間のPodレベル接続を必要とし、それを用意するのはタダではありません。本番トポロジーが依存する前に、どのモデルが自分の環境に合うかを理解しておく価値があります。 -
プロキシのリソース制限。 万能なサイジングレシピは存在しません。毎秒数千の接続を終端するメッシュ化されたingressコントローラーは、わずかな内部トラフィックを処理する上流サービスよりも、はるかに多くのプロキシメモリを消費します。50サービスのクラスターをwatchする
destinationコントローラーは、5,000エンドポイントをwatchするものとは別物です。制限を設定する前にまず観察してください：制限なしで動かし、本番トラフィックにワークロードを形成させ、サイドカーごとおよびコントロールプレーンコンポーネントごとの実際のCPUとメモリ消費を計測します。ピークを含む1週間分のデータが得られたら、観測された最大値に余裕を加えた値で制限を設定します。
実践的な推奨
Kubernetesプラットフォーム向けのサービスメッシュを評価中で、Istioを選ぶ強い理由がまだないのであれば、まずLinkerdを試してみてください。インストールは午後一度で終わります。必要なことを満たしてくれれば、四半期分の運用工数を節約できたことになります。そうでなくても、別の選択肢へ進むための明確で文書化された理由が手に入ります。