Skip to content

Linkerd

Pod 間トラフィックに mTLS・メトリクス・信頼性を、軽量な Rust 製サイドカープロキシ経由で追加する Kubernetes 向けサービスメッシュ。

  • カテゴリ: Service Mesh & Networking
  • CNCF 成熟度: Graduated
  • 言語: Go (コントロールプレーンと CLI) と Rust (ポリシーコントローラとデータプレーンの proxy)
  • ライセンス: Apache-2.0
  • リポジトリ: linkerd/linkerd2
  • ドキュメント基準コミット: 7977d50 (タグ edge-26.6.3 付近)

何をするものか

Linkerd は Kubernetes 向けのサービスメッシュである。メッシュ対象の各 Pod の隣に小さな proxy を置き、その Pod の TCP トラフィックを proxy 経由で流す。トラフィックが proxy を通るようになると、アプリのコードを変えずに、Pod 間の相互 TLS、ゴールデンメトリクス (成功率・リクエストレート・レイテンシ)、リトライ、トラフィック分割が得られる。

プロジェクトは 2 つのリポジトリにまたがる。コントロールプレーンと linkerd CLI は linkerd/linkerd2 (Go、Rust 製ポリシーコントローラを含む) にある。データプレーンの proxy は linkerd/linkerd2-proxy にあり、Rust で書かれた専用のマイクロプロキシである (出典 6)。決定的な選択はこの proxy にある。Linkerd は Envoy を使わない。低レイテンシ・低メモリ・メモリ安全を狙った小さな Rust proxy を載せる (出典 12, 13)。

Linkerd は「サービスメッシュ」という用語を世に広めたプロジェクトである (出典 4, 13)。2017 年に CNCF に参加し、2021 年にサービスメッシュとして史上初の Graduated に到達した (出典 1, 2)。

いつ使うか

  • Kubernetes 上で動かしており、最小限の設定でサービス間 mTLS をデフォルトで有効にしたい。
  • アプリのコードを編集せずにゴールデンメトリクスとトラフィックレベルの信頼性 (リトライ・タイムアウト・トラフィック分割) が欲しい。
  • 運用面を小さく保ちたい。CLI 主導のインストール、コンパクトなコードベース、ワークロードごとのチューニングが不要な proxy を重視する。
  • Istio の全機能セットや非 Kubernetes ワークロードが必要なら向かない。Linkerd は Kubernetes 中心である。
  • サイドカーなしでカーネルレベルのネットワーキングが欲しいなら向かない。その場合は Cilium の eBPF モデルが近い (出典 12)。

このディープダイブの構成

出典