Linkerd 2.18 とその未來：コミュニティとCNCFにおける技術進化

はじめに

Linkerd は、Kubernetes エコシステムにおいてサービスメッシュの代表的な実裝として知られるオープンソースプロジェクトです。2017年に CNCF（Cloud Native Computing Foundation）に採用され、2022年に 1.x バージョンを終了し、2.x バージョンへと移行しました。この記事では、Linkerd 2.18（Battle Scars）の主要な機能と、コミュニティの貢獻を通じた技術進化、および未來の方向性について詳しく解説します。

バージョンの進化と核心理念

歴史的背景

• Linkerd 0.8（2016年）：最初のサービスメッシュとして登場。Finagle ライブラリをベースにし、sidecar パターンを採用せず、ambient approach を採用していました。
• 2017年：CNCF に採用され、2018年にコアアーキテクチャを再設計。2022年には 1.x バージョンを完了。
• 2.18 バージョン：ユーザーからのフィードバックを反映し、運用體験の改善とメンテナンスの負擔軽減を目的としています。

五つの核心理念

1. Do No Harm：Linkerd を導入しても既存のアプリケーションは正常に動作し続ける。
2. Be Predictable：動作が予測可能で、ユーザーが心のモデルを構築しやすい。
3. Make It Obvious：マジックな操作を避けて、明確なステップを提供。
4. Scale Config From Zero：初期設定がシンプルで、必要に応じて拡張可能。
5. Act Normal：Kubernetes エコシステムと深く統合し、學習コストを抑える。

協議検出の問題と解決策

協議検出の仕組み

Linkerd は、接続の協議（HTTP/TCP）を検出し、それに応じた機能（ルーティング、認証など）を有効化します。しかし、以下の問題がありました。

• TCP協議の検出問題：クライアントがデータを送信するまで検出ができないため、10秒のタイムアウトが発生。
• 特定協議の検出困難：SMTP、MySQL などの協議は検出ができないため、接続が失敗する。

Opaque Ports の導入と課題

• 2.0バージョン：自動協議検出を導入し、最初のいくつかのバイトを読み込んで HTTP を検出。
• 2.10バージョン：Opaque Ports を導入し、特定のポートを TCP として扱い、協議検出をスキップ。

しかし、Opaque Ports は以下の課題がありました。

• 設定の複雑さ：enable-external-profiles アノテーションとデフォルト値の使用が必要。
• デフォルト値の混亂：ポートがデフォルト集合に含まれるかどうかで分岐し、理解が難しくなる。
• ドキュメントの不足：フローチャートを含むドキュメントが必要だが、実際の使用には困難。

2.18 の新機能：Protocol Declarations

• 協議宣言：ユーザーが明示的に協議（HTTP/HTTP2）を指定し、協議検出をスキップ。
• Opaque Ports の代替：より直接的な設定方法を提供。
• 高負荷時の問題解決：HTTP 協議が高負荷でデータ送信が遅れ、認証失敗（例：403 エラー）を防ぐ。

技術的詳細と未來の方向性

協議検出のタイムアウトメカニズム

• 10秒の待機：接続後、10秒待機し、データが屆かない場合は TCP とみなす。
• 偶発的な失敗：システム負荷が高いと、データ送信が遅れ、認証失敗が発生。

未來の方向性

• 操作の簡素化：ユーザーの設定負擔を減らすため、操作をさらに簡素化。
• コミュニティフィードバックによる改善：ユーザーからのフィードバックを活用し、安定性と使いやすさを向上。

設定と協議検出の課題

Opaque Ports の複雑さ

• 設定の複雑さ：非透明ポートの設定が複雑で、フローチャートによる説明が必要。
• デフォルト値の混亂：ポートがデフォルト値（例：3306 は MySQL）に含まれるかどうかで分岐。
• 協議検出の失敗：HTTP 接続で協議検出が失敗し、高負荷時に偶発的なエラーが発生。

2.18 の解決策：Protocol Declarations

• 協議宣言の導入：明示的に協議を指定し、協議検出をスキップ。
• Kubernetes 1.20 の appProtocol フィールド：協議タイプ（例：HTTP2）を直接設定。
• ALPN（Application-Layer Protocol Negotiation）：TLS で協議メタデータを伝達し、プロキシ間の協議同期。
• 指標の追加：協議動作の詳細を追跡し、トラブルシューティングを支援。

操作の簡素化とコミュニティの協力

操作の簡素化の継続

• 機能の拡張：機能を追加しながらも、操作の複雑さを減らすことを重視。
• ユーザーとの協力：実際の使用シーンからのフィードバックを活用し、設計を再評価。

生産環境での実踐

• Linkerd チームの運用：自身の生産環境を運用し、監視責任を負う。
• 多様な環境への適応：異なる環境設定に柔軟に対応し、戦略を調整。

技術の拡張と未來の方向

Skip Ports と Opaque Ports の比較

• Skip Ports：Linkerd 代理以外の外部サービス（例：Datadog）に適用し、追加のボトルネックを迴避。
• Opaque Ports：Linkerd 代理のターゲット端點には適用し、MTLS と TCP 指標を有効化。
• 選択の基準：監視要件やリソース消費、問題のシナリオに応じて選択。

クラウドネイティブトレンドの影響

• FedRamp、Gaia X などの主権クラウドとマルチクラウドの臺頭：Linkerd がこれらのインフラニーズに対応する必要性。
• プラットフォーム所有者の役割：変化するアーキテクチャニーズに柔軟に対応。

新機能と指標

新しい指標

• 協議宣言の詳細追跡：協議検出失敗や高負荷時の異常を診斷。
• 認証拒否の分析：高負荷下での発生パターンを分析。

Kubernetes のネイティブ統合

• appProtocol フィールドの利用：Kubernetes 1.20 以降と互換性を持ち、クラウドネイティブエコシステムとの統合を強化。

未來の展望

継続的な進化方向

• 操作の簡素化：操作の複雑さを減らしつつ、多様なシナリオへの対応を拡張。
• Sidecar、Ambient Mesh などのアーキテクチャ設計の探求：コミュニティからのフィードバックを活用し、技術路線を最適化。

結論

Linkerd 2.18 は、協議検出の課題を解決し、操作の簡素化を追求した重要なアップデートです。コミュニティのフィードバックを通じて、技術の進化が継続され、クラウドネイティブ環境における信頼性と柔軟性を高めています。今後の展開に注目してください。