スティッキーセッションを持つKubernetesロードバランサは常に1つのポッドにトラフィックを送信します

スティッキーセッションを持つKubernetesロードバランサは常に1つのポッドにトラフィックを送信します

ロードバランサーの設定に問題があり、ほとんどのトラフィック(99%など)が常に1つのポッドにリダイレクトされます。基本的にインフラストラクチャは次のようになります。この図では目的は、nginx または Google ロードバランサのどちらでもスティッキー セッションを有効にし、トラフィックを利用可能なポッドに均等に分散することです。

簡単に言うと、私のクラスターには 2 つの RC と 2 つのサービスがあります。1 つの nginx ポッドは Google Loadbalancer (nginx-lb) の背後で提供され、もう 1 つのロード バランサ (app-lb) がトラフィックを 2 つのアプリ ポッドに分散します。構成について私が考えたことは次のとおりです。

  • nginx-lb: nginx-lbを に設定しましたsessionAffinity: NoneexternalTrafficPolicy: Local今はスティッキーセッションは必要ないと考えているからですが、ユーザーのIPをパススルーするこの時点では、すべての着信トラフィックは同じように扱われますが、 を設定することでユーザーの IP を保持しようとしていますexternalTrafficPolicy: Local

  • nginx: nginx自体が有効になっていますngx_http_realip_モジュールユーザーの IP を転送したままにしておきます。ただし、ここではスティッキー セッションはまだ必要ないと考えているため、ip_hash は使用しませんでした。ここでも、nginx-lb と同様に、すべての着信トラフィックを通過させながらユーザーの IP を保持しようとしています。ここでの nginx は、主にプロキシと SSL ハンドラー用です。

  • sessionAffinity: ClientIPapp-lb: 次にapp-lbでスティッキーセッションを有効にしexternalTrafficPolicy: Cluster負荷分散背後に 2 つのポッドがある/認識している唯一のサービスであるため、ClientIP による実際の負荷分散はここで行われると考えています。

私はこの構成を、約 50 人のユーザーを 1 日間実行して 1 つのポッドにリダイレクトしながら、もう 1 つのポッドがアイドル状態になり、最初のポッドに比べて CPU とメモリの使用率が低い状態でテストしました。

セットアップについてお聞きしたいのですが、私が達成したいことは正しく達成されていますか? 見落としている構成はありますか? どのようなご意見でも大歓迎です。

追伸: 私が理解した事実をさらに追加するために質問全体を書き直しましたが、基本的には言葉遣いは異なりますが元の質問と関連しています。

答え1

これは、使用しているために発生します。sessionAffinity: ClientIPこれはサービス上のアフィニティであり、IPベースであるため、サービスはロードバランサーのIPを取得し、使用してみてください。sessionAffinity: Noneスティッキーセッションを使用する場合は、nginx ingressコントローラーを使用します。

答え2

モバイルやラップトップよりも多くのクライアントでアプリをテストしようとしたことがありますか?
複数の Google Compute Engine インスタンスからテストできるかもしれません。

スティッキー セッションと負荷分散の両方を実装しているため、ip_hash2 つのデバイスがまったく同じポッドによってサービスを受ける可能性が 50% あり、ページをリロードしても、IP を変更するまで常に同じポッドによってサービスが提供されます。

ip-hash では、クライアントの IP アドレスがハッシュ キーとして使用され、クライアントの要求に対してサーバー グループ内のどのサーバーを選択するかが決定されます。この方法により、同じクライアントからの要求は、そのサーバーが利用できない場合を除いて、常に同じサーバーに送信されるようになります。 http://nginx.org/en/docs/http/load_balancing.html

関連情報