Kubernetes における負荷分散の完全ガイド

多くの企業は、コンテナを展開する際に、コンテナ オーケストレーション システムとして Kubernetes を選択しています。これは、Kubernetes の信頼性、柔軟性、および機能を広く肯定するものです。この記事では、Kubernetes が非常に一般的かつ必要なタスクである負荷分散をどのように処理するかを詳しく見ていきます。負荷分散は、多くの非コンテナ環境では比較的単純なタスクです (つまり、サーバー間の分散)。ただし、コンテナが関係する場合は、追加の特別な処理が必要になります。

コンテナの管理

Kubernetes の負荷分散を理解するには、まず Kubernetes がコンテナを構築する方法を理解する必要があります。

コンテナは通常、特定のサービスまたはサービス セットを実行するために使用されるため、コンテナは、サービスの単一のインスタンス (つまり、単一のコンテナ) としてではなく、コンテナが提供するサービスに基づいて表示する必要があります。実際、Kubernetes はまさにこれを実行します。

ポッドに入れる

Kubernetes では、ポッドは基本的な機能単位です。ポッドは、コンテナとそれらが共有するボリュームのグループです。コンテナは、機能とサービスに関して密接に関連していることがよくあります。

同じ機能セットを持つポッドは、サービスと呼ばれるコレクションに抽象化されます。これらのサービスは、Kubernetes 上に構築されたアプリケーション クライアントによってアクセスされます。これらのサービスは、それらを構成するコンテナへのアクセスを管理し、クライアントをコンテナ自体から分離します。

ポッドの管理

それでは具体的な詳細を見てみましょう。

ポッドは通常、Kubernetes によって作成および破棄され、永続的なエンティティとして設計されていません。各ポッドには独自の IP アドレス (ローカル アドレスに基づく)、UID、およびポート番号があります。新しく作成されたポッドは、現在のポッドのコピーであるか以前のポッドであるかに関係なく、新しい UID と IP アドレスが割り当てられます。

各ポッド内のコンテナは相互に通信できますが、異なるポッド内のコンテナとは直接通信できません。

Kubernetesに仕事を任せよう

Kubernetes は独自の組み込みツールを使用して、個々のポッド間の通信を管理します。つまり、一般的には、ポッドの作成、削除、複製について心配することなく、Kubernetes に依存してポッドを内部的に監視するだけで十分です。ただし、Kubernetes によって管理されるアプリケーションの少なくとも一部の内部要素を、基盤となるネットワークから見えるようにする必要がある場合もあります。このような状況が発生した場合、ソリューションでは、*** IP アドレスの不足をどう処理するかを考慮する必要があります。

ポッドとノード

多くの点で、Kubernetes はコンテナ管理システムと同様にポッド管理システムと考えることができます。ほとんどのインフラストラクチャは、コンテナ レベルではなく、ポッド レベルでコンテナを処理します。

Kubernetes 内部管理の観点から見ると、ポッドの上位の組織レベルはノードに相当し、ノードは管理および通信リソースを含む仮想マシンであり、ポッドを展開するための環境です。ノード自体も内部で作成、破棄、置換/再デプロイできます。ノード レベルでもポッド レベルでも、その作成、破棄、再デプロイ、使用、スケーリングはすべて、コントローラーと呼ばれる内部プロセスによって処理されます。

ディスパッチャとして機能する「サービス」

サービスは、Kubernetes が管理レベルでコンテナとポッドを処理する方法です。ただし、前述したように、機能的に関連する、または同一のポッドもサービスに抽象化され、外部クライアントやアプリケーション内の他の要素がポッドと対話する場合、Kubernetes はサービス レベルになります。

サービスには比較的安定した IP アドレスがあります (Kubernetes によって内部的に使用されます)。プログラムがサービスによって提供される機能を使用する必要がある場合、個々のポッドではなくサービスにリクエストを送信します。次に、サービスはディスパッチャーとして機能し、リクエストを処理するポッドを割り当てます。

スケジューリングと負荷分散

これを見ると、負荷分散はスケジューリング レベルで行われるのだろうかと疑問に思うかもしれません。確かにその通りです。 Kubernetes サービスは、必要に応じて同じ機能を備えたマシンを指定された領域に送信する、巨大な機器プールのようなものになります。スケジューリング プロセスの一環として、可用性の管理とリソースのボトルネックの回避を考慮する必要があります。

kube-proxyで負荷分散を実行

Kubernetes における最も基本的なタイプの負荷分散は、実際には負荷分散であり、スケジューリング レベルで簡単に実装できます。 Kubernetes は 2 つの負荷分散方法を使用します。どちらも、サービスが使用する仮想 IP の管理を担当する kube-proxy 関数を通じて実行されます。

kube-proxy のデフォルト モードは iptables であり、かなり洗練されたルールベースの IP 管理をサポートします。 iptables モードでは、ローカルの負荷分散方法はランダム選択です。つまり、着信要求によってサービス内のポッドがランダムに選択されます。以前の (元のデフォルト) kube-proxy モードはユーザー空間であり、ラウンドロビン負荷分散を使用し、IP リストで次に使用可能なポッドを割り当ててから、そのリストを置き換え (または並べ替え) ていました。

実際の負荷分散: Ingress

先ほど 2 つの負荷分散方法について説明しましたが、これらは真の負荷分散ではありません。真の負荷分散を実現するために、現在多くの分野で最も優れ、最も柔軟で適用されている方法は、専用の Kubernetes ポッド内のコントローラーを通じて動作する Ingress です。コントローラーは、トラフィックを管理する一連のルールである Ingress リソースと、それらのルールを適用するデーモンで構成されます。

コントローラーには独自の負荷分散機能が組み込まれており、かなり高度な機能を備えています。特定のシステムまたはプロバイダーの負荷分散機能と要件を満たすために、Ingress リソースにさらに複雑な負荷分散ルールを含めることもできます。

代替手段としてロードバランサーを使用する

Ingress に加えて、代わりにロードバランサタイプのサービスを使用することもできます。このサービスでは、外部のクラウドベースのロードバランサーを使用します。ロードバランサは、AWS、Azure、OpenStack、CloudStack、Google Compute Engine などの特定のクラウド サービス プロバイダーでのみ使用でき、バランサの機能はプロバイダーによって異なります。さらに、サービス プロバイダーやサードパーティからは、他の負荷分散方法も利用できます。

一般的には、Ingress が推奨されます。

現在、Ingress は最も人気のある負荷分散方法です。これはポッドベースのコントローラーとして Kubernetes 内で実行されるため、Kubernetes 機能へのアクセスは比較的制限がありません (一部の外部ロードバランサーはポッド レベルではアクセスできない場合があります)。 Ingress リソースに含まれる構成可能なルールにより、アプリケーションの機能要件や動作条件に合わせて調整できる、非常に詳細で粒度の細かい負荷分散が可能になります。