新しいサービスメッシュが必要な理由
明らかに、Linkerdが「世界で最も広く使用されているサービスメッシュの生産ソリューション」と呼ばれるBuoyantでは、同様の目的で（したがって、競合する）新しい製品を作成するのに十分な理由がありました。 答えは簡単です-同社は特定のニッチでサービスメッシュの大きな可能性を見ました：
「Linkerdのリソース消費が不当に高いタイプのインストールがあることがわかりました。 Linkerdは、Finagle、Netty、Scala、JVMなど、広く受け入れられている生産実績のあるコンポーネントに基づいています。 膨大な負荷に対応するために拡張できますが、必要な量のCPUとRAMを提供する場合、これらのコンポーネントはすべて、特にサイドカーコンテナーに基づいたKubernetesインストールの場合、リソースが限られた環境に縮小するために反対のことを行うようには設計されていません「。
同じことは、業界の巨人によって作成されたLinkerdの主要な競合他社であるIstioのコンテキストでも言えます。
したがって、Conduitの目的に関する質問への答えは、 Kubernetes（およびのみ）に基づく小さな（リソースに制限のある）マイクロサービス環境向けのサービスメッシュです 。 著者自身によると、ConduitはECS、Consul、Mesosを含む「Linkerdがサポートする非常に多くのプラットフォームと統合に焦点を当てていない」ため、約6か月かかったこの新製品の外観は、実質的にLinkerdにとって何の意味もありません。 ZooKeeper、Nomad、Rancher、およびさまざまな複雑な環境。 Conduitは何に適していますか？
コンジット：アーキテクチャと機能
著者によって強調された製品の主な機能：
- 作業の容易さと速度。
- 開始から終了までの可視性（コードを変更する必要なくすべてのアプリケーションコンポーネントの動作を確認する機能）;
- すぐに使えるセキュリティ（デフォルトのTLSで有効化）;
- Kubernetesフォーカス。
これはどのように達成されますか？ コンジットは、データプレーンとコントロールプレーンの2つのコンポーネントで構成されています。
一般的なコンジットアーキテクチャ（ Abhishek Tiwariのブログから引用 ）
データプレーンはサービスリクエストに直接応答し、これに必要なトラフィックを制御します。 技術的な実装は、サービスの各インスタンスのサイドカーコンテナー（つまり、サービスの直接機能を実装するメインコンテナーの隣の同じポッドに存在する「追加」コンテナー）として展開される軽量プロキシのセットで表されます。 サービスをConduitに追加するには、Kubernetesのポッドを再展開して、Conduitデータプレーンからプロキシに各ポッドを追加する必要があります。
展開結果コンジットデータプレーン
このドキュメントは、Conduitが「各自で構成する必要なくほとんどのアプリケーションをサポートする」ことを約束しています。これは、各接続に使用されるプロトコルの自動検出を使用します。 ただし、場合によっては、この定義は完全に自動化されません。たとえば、HTTPSを使用しないWebSocket、およびHTTPプロキシ（
HTTP CONNECT
を使用）、TLSをMySQLおよびSMTPを使用しない接続の
HTTP CONNECT
です。 その他の制限事項：grpc-goを使用してgRPCを介して通信するアプリケーションは、1.3以上のライブラリバージョンを使用する必要があり、Conduitはまだ外部DNSクエリをサポートしていません（つまり、これらのリクエストをサードパーティAPIにプロキシする）。
データプレーンは、要求とタイムアウトの再試行、暗号化（TLS）、要求の受け入れまたは拒否のポリシーの割り当てなど、関連する補助メカニズムを実装することにより、囲炉裏に通信を提供します。
このコンポーネントの重要な機能は、高性能という名前で、 Rust言語で書かれていることです。 それを実装するために、著者は基盤となるオープンソース技術の開発に投資しました： Tokio （ネットワーク非同期アプリケーションを作成するためのイベント駆動型I / Oプラットフォーム）およびTower （簡潔に
fn(Request) → Future<Response>
として記述） このアプローチにより、著者は最小限の遅延 （「サブミリ秒p99」）とメモリ消費 （「10mb RSS」）を達成できました。
コントロールプレーン -Conduitの2番目のコンポーネント。データプレーンからプロキシの動作を制御するように設計されています。 これは、別個のKubernetesネームスペースで起動される、 Goですでに記述された一連のサービスによって表されます。 その機能には、テレメトリックデータの集約と、収集されたメトリックへのアクセスとデータプレーンの動作の変更の両方を可能にするAPIのプロビジョニングがあります。 コントロールプレーンAPIは、Conduitへの両方のインターフェイス（CLIおよびWeb UI）も使用し、他のサードパーティツール（たとえば、CI / CDのシステム）で使用できます。
コンジットWebインターフェースの一般的なビュー
Conduitの技術デバイスとそのコンポーネントの詳細については、開発者向けのドキュメントを参照してください 。
K8sの統合とステータス
コンジットは、最初に既存のKubernetesインストールで使用されることを目標に構築されています。 特に、このために、
conduit
コンソールユーティリティは、
kubectl
の広範な使用を意味します（たとえば、
conduit install
および
conduit inject
は、
kubectl apply -f
リダイレクトする必要がある構成を生成します）。 Conduitの基本的な悪用可能なコンポーネントとして
Deployments
選択
Deployments
れました（
Services
ではなく、Web UIに表示され
Services
）。これにより、トラフィックのルーティングで不必要な困難が生じないようにします（個々のポッドは任意の数の
Services
一部になることができ
Services
）。
Conduitの使用を開始する方法（Minikubeのオプションとデモアプリケーションのインストール例）は、 プロジェクトのドキュメントに記載されています 。 Conduitでデプロイされたアプリケーションの統計は、次のようになります。
conduit stat deployments NAME REQUEST_RATE SUCCESS_RATE P50_LATENCY P99_LATENCY emojivoto/emoji 2.0rps 100.00% 0ms 0ms emojivoto/voting 0.6rps 66.67% 0ms 0ms emojivoto/web 2.0rps 95.00% 0ms 0ms
Conduitプロジェクトの現在のステータスはアルファ版です。 現在（最新バージョン-v0.2.0- 2月1日）、HTTP、HTTP / 2、およびgRPCのすべてのトラフィックについて、すべてのTCPトラフィックのプロキシと、高レベルメトリックの出力（成功率、遅延-上記の例を参照）がサポートされています。 プロジェクト開発基準 （本番環境での適用の可能性をもたらすため）では、次のグローバルタスクに注意してください。
- サービス間のすべてのタイプの相互作用のサポート（HTTPだけでなく）。
- サービス間認証と機密性のプロビジョニング（デフォルト）。
- Kubernetes API拡張機能により、実際のさまざまな悪用ポリシーをサポート。
- コンジットコントローラー自体は、環境固有のポリシーを持つプラグインをサポートするために拡張可能なマイクロサービスです。
このプロジェクトは、存在してから2.5か月間、GitHubと19人の貢献者から1,000以上の星を集めることができました。 ソースコードは、Apache License v2.0の条件の下で配布されます（使用されるコンポーネントの一部はMITライセンスの下にあります）。
Buoyantは、Conduitを生産で使用できるよう準備するとともに、商業的なサポートを提供するために、今後数か月にわたって積極的に作業する予定です。
PS
ブログもご覧ください。
- 「 サービスメッシュとは何ですか。なぜ必要なのですか（マイクロサービスを備えたクラウドアプリケーション）。 " （Linkerd 1.0の際に発行されたBuoyantによる記事の翻訳） ;
- 「 ルークはKubernetesの 「 セルフサービス」データウェアハウスです 。
- 「 CoreDNS-クラウドネイティブワールドのDNSサーバーとKubernetesのサービスディスカバリー 」。
- 「 Container Networking Interface（CNI）-Linuxコンテナのネットワークインターフェイスおよび標準 」;
- 「 手頃な価格のサービスとしてKubernetesを使用したインフラストラクチャ 。」