短縮版：

Envoy のハッシュ リング ロード バランシング アルゴリズムを Istio で使用できますか? これはロードマップに載っていますか？

より詳しい情報：

こちらの Istio ロード バランシング ドキュメントには、現在利用可能なロード バランシング アルゴリズムがリストされています。

Envoy のハッシュ リング ロード バランシング アルゴリズムを使用できるようにしたいのですが、現在リストされていません。

なんで？将来のリクエストに必要なノード/ポッド データでキャッシュするために、シャード キーに基づいて毎回同じ kubernetes ポッドに grpc rpc を送信したいと考えています。以前に go ライブラリの groupcache を使用してこれを行ったことがあり、それはうまくいきましたが、さまざまな理由でより良い方法であると想像しているため、Istio で可能かどうかを調べたいと思います。

プロジェクトに関係している、またはプロジェクトに精通している誰かが、ハッシュ リング ロード バランサーが Istio のロードマップにあるかどうか、または追加される可能性があるかどうかについてコメントしてくれることを願っています。また、現在それを行う方法があれば、正しい方向に向けたいと思います。

どうもありがとう！

現在、mesos/marathon クラスター内のアプリケーションが、mesos/marathon クラスターに存在する場合と存在しない場合があるサービスにアクセスしたいという設定があります。クラスターへの外部トラフィックのイングレスは、Traefik インスタンスのクラスターの前にある Amazon ELB を介して行われます。次に、適切なコンテナー インスタンスのセットを選択し、受信 HTTP ホスト ヘッダーを介して負荷分散します。 - 特定のコンテナー インスタンスに対する構成済みホスト ヘッダーの 1 つの関連付け。内部から内部へのトラフィックも、実際にはこの同じルートによって処理されます。これは、特定のサービスに関連付けられている DNS レコードが、メソ/マラソン クラスターの内部と外部の両方で同じ ELB にマップされているためです。また、同じコンテナ セットを指す複数の DNS レコードを持つ機能も提供します。

このセットアップは機能しますが、コンテナまたは別のコンポーネント内のアプリケーションが、呼び出したいサービスがそれらが含まれていた特定の mesos/marathon クラスターを呼び出し、一連のコンテナーの前にあるクラスターの内部にある何か、または特定のコンテナー自体に直接、適切な呼び出しを行います。

私が Kubernetes について理解していることから、Kubernetes はサービスの概念を提供します。これは基本的に、サービスが一致するポッドの構成に基づいて一連のポッドのフロントとして機能できます。ただし、ネットワーク トラフィックをサービス IP に転送することを Kubernetes クラスター内のアプリケーションに透過的に認識させるメカニズムについては、完全にはわかりません。Envoy プロキシ トラフィックをサービス名などに使用することで、この問題の一部を解決できると思います<application-name>.<cluster-name>.company.comが、以前の DNS エントリ (たとえば ) にマップする CNAME がある場合、<application-name>.company.comどのようにクラスタの終了を回避できます。

両方のケースを解決する良い方法はありますか? アプリケーションのロジックが、特定のクラスター内にあることを理解しなければならず、ルーティングを適切に実行するためにアプリケーションの外部のコンポーネントを優先することを回避しようとしています。

特定のコンポーネントを根本的に誤解している場合は、訂正していただければ幸いです。