🥇Kubernetes での長期接続の負荷分散とスケーリング

この記事は、Kubernetes での負荷分散の仕組み、存続期間の長い接続をスケーリングするときに何が起こるか、HTTP/2、gRPC、RSockets、AMQP、またはその他の存続期間の長いプロトコルを使用する場合にクライアント側の分散を考慮する必要がある理由を理解するのに役立ちます。。

Kubernetes でトラフィックがどのように再分散されるかについて少し説明します。

Kubernetes は、アプリケーションをデプロイするための XNUMX つの便利な抽象化、サービスとデプロイメントを提供します。

デプロイメントでは、アプリケーションのコピーを常にどのように、またいくつ実行する必要があるかを記述します。各アプリケーションはポッドとしてデプロイされ、IP アドレスが割り当てられます。

サービスは機能的にはロードバランサーと似ています。これらは、トラフィックを複数のポッドに分散するように設計されています。

どのようなものかを見てみましょう.

以下の図では、同じアプリケーションの XNUMX つのインスタンスと XNUMX つのロードバランサーが示されています。
ロードバランサーはサービスと呼ばれ、IP アドレスが割り当てられます。受信リクエストはすべて、ポッドの XNUMX つにリダイレクトされます。
デプロイメントシナリオによって、アプリケーションのインスタンスの数が決まります。以下の直下で展開する必要はほとんどありません。
各ポッドには独自の IP アドレスが割り当てられます。

サービスを IP アドレスの集合として考えると便利です。サービスにアクセスするたびに、IP アドレスの XNUMX つがリストから選択され、宛先アドレスとして使用されます。

こんな感じです.

サービスに対するカール 10.96.45.152 リクエストが受信されます。
サービスは、次の XNUMX つのポッドアドレスのいずれかを宛先として選択します。
トラフィックは特定のポッドにリダイレクトされます。

アプリケーションがフロントエンドとバックエンドで構成されている場合、それぞれにサービスとデプロイメントの両方が必要になります。

フロントエンドがバックエンドにリクエストを行うとき、バックエンドがサービスを提供するポッドの数を正確に知る必要はありません。XNUMX、XNUMX、または XNUMX の可能性があります。

また、フロントエンドは、バックエンドにサービスを提供するポッドのアドレスについては何も知りません。

フロントエンドがバックエンドにリクエストを行うとき、バックエンドサービスの IP アドレスが使用されますが、このアドレスは変更されません。

ここではそれがどのように見えるのです.

1 では、内部バックエンドコンポーネントをリクエストします。バックエンドに特定のものを選択する代わりに、サービスにリクエストを作成します。
サービスは、バックエンドポッドの XNUMX つを宛先アドレスとして選択します。
トラフィックは、サービスによって選択されたポッド 1 からポッド 5 に送信されます。
Under 1 は、Under 5 のようなポッドがサービスの背後に何個隠されているかを正確に知りません。

しかし、サービスはリクエストをどのように正確に分散するのでしょうか? ラウンドロビンバランシングが使用されているようですか？それを理解しましょう。

Kubernetes サービスのバランス調整

Kubernetes サービスは存在しません。 IP アドレスとポートが割り当てられるサービスに対するプロセスはありません。

これを確認するには、クラスター内の任意のノードにログインし、netstat -ntlp コマンドを実行します。

サービスに割り当てられた IP アドレスを見つけることさえできません。

サービスの IP アドレスは、コントローラーの制御層にあり、データベース (etcd) に記録されます。同じアドレスが別のコンポーネント (kube-proxy) によって使用されます。
Kube-proxy は、すべてのサービスの IP アドレスのリストを受信し、クラスター内の各ノードに iptables ルールのセットを生成します。

これらのルールには、「サービスの IP アドレスが見つかった場合は、リクエストの宛先アドレスを変更し、ポッドの XNUMX つに送信する必要がある」と記載されています。

サービス IP アドレスはエントリポイントとしてのみ使用され、その IP アドレスとポートをリッスンするプロセスによって提供されることはありません。

これを見てみましょう.

XNUMX つのノードからなるクラスターを考えてみましょう。各ノードにはポッドがあります。
ベージュに塗られた結ばれたポッドはサービスの一部です。サービスはプロセスとして存在しないため、灰色で表示されます。
最初のポッドはサービスをリクエストし、関連するポッドの XNUMX つに移動する必要があります。
しかし、サービスもプロセスも存在しません。どのように機能するのでしょうか?
リクエストはノードから出る前に、iptables ルールを通過します。
iptables ルールは、サービスが存在しないことを認識し、その IP アドレスをそのサービスに関連付けられたポッドの IP アドレスの XNUMX つに置き換えます。
リクエストは有効な IP アドレスを宛先アドレスとして受け取り、通常どおり処理されます。
ネットワークトポロジに応じて、リクエストは最終的にポッドに到達します。

iptables は負荷分散できますか?

いいえ、iptables はフィルタリングに使用され、バランシングのために設計されたものではありません。

ただし、次のように機能する一連のルールを作成することは可能です。疑似バランサー.

そして、これはまさに Kubernetes に実装されているものです。

ポッドが XNUMX つある場合、kube-proxy は次のルールを書き込みます。

33% の確率で最初のサブを選択します。そうでない場合は、次のルールに進みます。
50% の確率で XNUMX 番目のものを選択します。そうでない場合は、次のルールに進みます。
XNUMX番目の下を選択します。

このシステムでは、各ポッドが 33% の確率で選択されます。

また、ポッド 2 の次にポッド 1 が選択されるという保証はありません。

注意: iptables はランダム分布の統計モジュールを使用します。したがって、バランシングアルゴリズムはランダムな選択に基づいています。

サービスがどのように機能するかを理解したところで、さらに興味深いサービスシナリオを見てみましょう。

Kubernetes の長期間存続する接続はデフォルトでは拡張されません

フロントエンドからバックエンドへの各 HTTP リクエストは、開閉される個別の TCP 接続によって処理されます。

フロントエンドが 100 秒あたり 100 のリクエストをバックエンドに送信すると、XNUMX の異なる TCP 接続が開かれ、閉じられます。

XNUMX つの TCP 接続を開き、それを後続のすべての HTTP リクエストに使用することで、リクエストの処理時間と負荷を軽減できます。

HTTP プロトコルには、HTTP キープアライブ、または接続の再利用と呼ばれる機能があります。この場合、単一の TCP 接続を使用して複数の HTTP 要求と応答が送受信されます。

この機能はデフォルトでは有効になっていません。サーバーとクライアントの両方をそれに応じて構成する必要があります。

セットアップ自体はシンプルで、ほとんどのプログラミング言語と環境でアクセスできます。

さまざまな言語の例へのリンクをいくつか示します。

Kubernetes サービスでキープアライブを使用するとどうなりますか?
フロントエンドとバックエンドの両方がキープアライブをサポートしていると仮定します。

フロントエンドのコピーが XNUMX つ、バックエンドのコピーが XNUMX つあります。フロントエンドは最初のリクエストを作成し、バックエンドへの TCP 接続を開きます。リクエストがサービスに到達すると、バックエンドポッドの XNUMX つが宛先アドレスとして選択されます。バックエンドが応答を送信し、フロントエンドがそれを受信します。

応答を受信した後に TCP 接続が閉じられる通常の状況とは異なり、TCP 接続はさらなる HTTP リクエストのために開いたままになります。

フロントエンドがバックエンドにさらにリクエストを送信するとどうなりますか?

これらのリクエストを転送するには、オープン TCP 接続が使用され、すべてのリクエストは最初のリクエストが送信されたのと同じバックエンドに送信されます。

iptables はトラフィックを再分散すべきではないでしょうか?

この場合はありません。

TCP 接続が作成されると、トラフィックが送信される特定のバックエンドを選択する iptables ルールが通過します。

後続のリクエストはすべて、すでに開いている TCP 接続上にあるため、iptables ルールは呼び出されなくなります。

どのようなものかを見てみましょう.

最初のポッドはサービスにリクエストを送信します。
次に何が起こるかはすでにわかっています。サービスは存在しませんが、リクエストを処理する iptables ルールがあります。
バックエンドポッドの XNUMX つが宛先アドレスとして選択されます。
リクエストはポッドに到達します。この時点で、XNUMX つのポッド間の永続的な TCP 接続が確立されます。
最初のポッドからの後続のリクエストは、すでに確立されている接続を経由します。

その結果、応答時間が短縮され、スループットが向上しますが、バックエンドをスケールする能力が失われます。

バックエンドに XNUMX つのポッドがある場合でも、常時接続すると、トラフィックは常にそのうちの XNUMX つに送信されます。

これは修正できますか？

Kubernetes は永続的な接続のバランスを取る方法を知らないため、このタスクはユーザーの責任になります。

サービスは、エンドポイントと呼ばれる IP アドレスとポートの集合です。

アプリケーションはサービスからエンドポイントのリストを取得し、エンドポイント間でリクエストを分散する方法を決定できます。各ポッドへの永続的な接続を開き、ラウンドロビンを使用してこれらの接続間でリクエストのバランスをとることができます。

またはさらに申請してください複雑なバランスアルゴリズム.

バランスをとるクライアント側のコードは、次のロジックに従う必要があります。

サービスからエンドポイントのリストを取得します。
各エンドポイントに対して永続的な接続を開きます。
リクエストを行う必要がある場合は、開いている接続のいずれかを使用してください。
エンドポイントのリストを定期的に更新し、新しいエンドポイントを作成するか、リストが変更された場合は古い永続接続を閉じます。

このようになります.

最初のポッドがサービスにリクエストを送信する代わりに、クライアント側でリクエストのバランスをとることができます。
どのポッドがサービスの一部であるかを尋ねるコードを記述する必要があります。
リストを取得したら、それをクライアント側に保存し、それを使用してポッドに接続します。
あなたは負荷分散アルゴリズムを担当します。

ここで疑問が生じます。この問題は HTTP キープアライブにのみ適用されるのでしょうか。

クライアント側の負荷分散

永続的な TCP 接続を使用できるプロトコルは HTTP だけではありません。

アプリケーションがデータベースを使用する場合、データベースにリクエストを送信したり、データベースからドキュメントを取得したりする必要があるたびに TCP 接続が開かれるわけではありません。

代わりに、データベースへの永続的な TCP 接続が開かれ、使用されます。

データベースが Kubernetes 上にデプロイされ、アクセスがサービスとして提供される場合、前のセクションで説明したのと同じ問題が発生します。

XNUMX つのデータベースレプリカは他のデータベースレプリカよりも負荷が高くなります。 Kube-proxy と Kubernetes は接続のバランスをとるのに役立ちません。データベースに対するクエリのバランスに注意する必要があります。

データベースへの接続に使用するライブラリに応じて、この問題を解決するためのオプションが異なる場合があります。

以下は、Node.js から MySQL データベースクラスターにアクセスする例です。

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

永続的な TCP 接続を使用するプロトコルは他にも多数あります。

WebSocket と安全な WebSocket
HTTP / 2
gRPC
Rソケット
AMQP

これらのプロトコルのほとんどについてはすでによく知っているはずです。

しかし、これらのプロトコルがこれほど普及しているのであれば、なぜ標準化されたバランシングソリューションがないのでしょうか? なぜクライアントロジックを変更する必要があるのでしょうか? ネイティブの Kubernetes ソリューションはありますか?

Kube-proxy と iptables は、Kubernetes にデプロイする際の最も一般的なユースケースをカバーするように設計されています。これは便宜上のものです。

REST API を公開する Web サービスを使用している場合は、幸運です。この場合、永続的な TCP 接続は使用されないため、任意の Kubernetes サービスを使用できます。

ただし、永続的な TCP 接続を使い始めると、バックエンド間で負荷を均等に分散する方法を考え出す必要があります。 Kubernetes には、このケースに対する既製のソリューションが含まれていません。

ただし、役立つオプションは確かにあります。

Kubernetes での長期接続のバランスを取る

Kubernetes には XNUMX 種類のサービスがあります。

クラスターIP
ノードポート
ロードバランサー
ヘッドレス

最初の XNUMX つのサービスは、kube-proxy が iptables ルールを構築するために使用する仮想 IP アドレスに基づいて動作します。しかし、すべてのサービスの基本はヘッドレスサービスです。

ヘッドレスサービスには IP アドレスが関連付けられておらず、関連付けられているポッド (エンドポイント) の IP アドレスとポートのリストを取得するメカニズムのみが提供されます。

すべてのサービスはヘッドレスサービスに基づいています。

ClusterIP サービスは、いくつかの追加機能を備えたヘッドレスサービスです。

管理層はそれに IP アドレスを割り当てます。
Kube-proxy は必要な iptables ルールを生成します。

この方法では、kube-proxy を無視し、ヘッドレスサービスから取得したエンドポイントのリストを直接使用して、アプリケーションの負荷分散を行うことができます。

しかし、クラスターにデプロイされているすべてのアプリケーションに同様のロジックを追加するにはどうすればよいでしょうか?

アプリケーションがすでにデプロイされている場合、このタスクは不可能に思えるかもしれません。ただし、別のオプションもあります。

サービスメッシュがお手伝いします

おそらく、クライアント側の負荷分散戦略が非常に標準的なものであることにすでに気づいているでしょう。

アプリケーションが起動すると、次のことが行われます。

サービスから IP アドレスのリストを取得します。
接続プールを開いて維持します。
エンドポイントを追加または削除して、プールを定期的に更新します。

アプリケーションがリクエストを行う場合は、次の処理を行います。

何らかのロジック (ラウンドロビンなど) を使用して、利用可能な接続を選択します。
リクエストを実行します。

これらの手順は、WebSocket、gRPC、AMQP 接続の両方で機能します。

このロジックを別のライブラリに分離し、アプリケーションで使用できます。

ただし、代わりに Istio や Linkerd などのサービスメッシュを使用することもできます。

Service Mesh は、次のプロセスを使用してアプリケーションを強化します。

サービスの IP アドレスを自動的に検索します。
WebSocket や gRPC などの接続をテストします。
正しいプロトコルを使用してリクエストのバランスをとります。

Service Mesh はクラスター内のトラフィックの管理に役立ちますが、リソースをかなり消費します。他のオプションとしては、Netflix リボンなどのサードパーティライブラリや Envoy などのプログラム可能なプロキシを使用する方法があります。

バランスの問題を無視するとどうなるでしょうか?

負荷分散を使用しないことを選択しても、変化に気付かないこともあります。いくつかの作業シナリオを見てみましょう。

サーバーよりもクライアントの方が多い場合、これはそれほど大きな問題ではありません。

XNUMX つのサーバーに接続する XNUMX つのクライアントがあるとします。バランス調整がない場合でも、両方のサーバーが使用されます。

接続は均等に分散されていない可能性があります。おそらく XNUMX つのクライアントが同じサーバーに接続されていますが、両方のサーバーが使用される可能性が十分にあります。

さらに問題なのは、その逆のシナリオです。

クライアントの数が少なく、サーバーの数が多い場合、リソースが十分に活用されず、潜在的なボトルネックが発生する可能性があります。

XNUMX つのクライアントと XNUMX つのサーバーがあるとします。最良の場合、XNUMX 台のサーバーのうち XNUMX 台に対して XNUMX つの永続接続が存在します。

残りのサーバーはアイドル状態になります。

これら XNUMX つのサーバーがクライアント要求を処理できない場合、水平スケーリングは役に立ちません。

まとめ

Kubernetes サービスは、ほとんどの標準的な Web アプリケーションシナリオで動作するように設計されています。

ただし、データベース、gRPC、WebSocket など、永続的な TCP 接続を使用するアプリケーションプロトコルを使用し始めると、サービスは適切ではなくなります。 Kubernetes は、永続的な TCP 接続のバランスをとるための内部メカニズムを提供しません。

これは、クライアント側のバランスを念頭に置いてアプリケーションを作成する必要があることを意味します。

チームが作成した翻訳 Mail.ru の Kubernetes aaS.

このトピックに関して他に何を読むべきか:

出所： habr.com

Kubernetes での長期接続の負荷分散とスケーリング