Kubernetes ネットワーク 101

NodePort、LoadBalancer、Ingress コントローラー…おやおや!

Kubernetes を本番環境グレードにすることについてお客様やコミュニティと話し合うとき、最もよくある質問の 1 つは、「Ingress コントローラーは必要ですか?」です。 この質問に対する答えは、単純な「はい」または「いいえ」になることはめったになく、ポッドにトラフィックを誘導するさまざまな方法についての知識が必要になります。 このブログでは、Kubernetes ネットワークの基礎について説明します。これにより、Ingress コントローラーが必要かどうか、またいつ必要になるかについて、十分な情報に基づいた判断を下すことができます。

Kubernetes は、外部トラフィックをポッドにルーティングするためのいくつかのアプローチとレイヤーをサポートしていますが、それらはすべて同じように作成されているわけではありません。 デフォルトのモデルはkube-proxyですが、これは実際にはプロキシではなく、トラフィックの負荷分散、API の制御、サービスの動作の監視を行うようには設計されていません。

幸いなことに、外部トラフィックを管理する方法は他にもありますが、先に進む前に、Kubernetes コンポーネントを簡単に確認してみましょう。

• Kubernetes のデプロイメントは、物理マシンまたは仮想マシンであるノードで構成されます。
• ノードは結合してクラスターを形成します。
• 各クラスターは、Kubernetes のネットワークおよびインフラストラクチャ レベルにおける最小公分母であるポッドを管理します。 1 つ以上のポッドが集まってサービスを構成します。
• 各ポッド内には、1 つ以上のコンテナーが存在します (アプリケーションのサイズによって異なります)。

Kubernetes は、サービスを構成するポッドを監視し、アプリの要件に合わせて必要に応じてポッドをスケーリングします。 しかし、ポッドにトラフィックをどのように送るのでしょうか? ここで、サービスと Ingress コントローラーという 2 種類の Kubernetes オブジェクトが登場します。

Kubernetes サービスとは何ですか?

Kubernetes のドキュメントによると、サービスとは「一連の Pod 上で実行されているアプリを公開するための抽象的な方法」です。 サービスは、特定のノード上の位置が関係ないように、クラスターまたはコンテナのネットワーク内のポッドを接続します。 つまり、ポッドの場所が変更された場合や、ポッドが破棄されて再起動された場合でも、外部トラフィックを特定のポッドにルーティングできます。 このように、サービスは非常に基本的なリバース プロキシのように動作します。

Kubernetes への外部トラフィックのルーティングに関連するサービスとサービス オブジェクト タイプには複数の種類があります。 これらはよく混同されますが、実際にはそれぞれが非常に異なることを行うため、機能、用途、欠点を確認する価値があります。

クラスターIP

ClusterIP は、クラスター内の他のサービスがアクセスできる Kubernetes 内のサービスを提供するデフォルトのサービスです。 クラスターの外部からはアクセスできません。 ClusterIP サービスを公開する唯一の方法は、 kube-proxyのようなものを利用することですが、これが適切なシナリオはほとんどありません。 限定的な例としては、ラップトップ上のサービスへのアクセス、サービスのデバッグ、監視とメトリックの確認などが挙げられます。

ノードポート

NodePort サービスは、クラスター内のすべてのノードで特定のポートを開き、そのポートでノードに送信されたトラフィックを対応するアプリに転送します。これは、トラフィックをアプリに送信する非常に基本的な方法であり、実際のトラフィック管理のユースケースでは多くの制限があります。 NodePort ごとに 1 つのサービスのみを持つことができ、30000 から 32767 の範囲のポートのみを使用できます。 2,768 個のポートは多いように思えるかもしれませんが、Kubernetes を大規模に実行する組織ではすぐに不足するでしょう。 また、NodePort はレイヤー 4 ルーティング ルールと Linux iptablesユーティリティを使用して、レイヤー 7 ルーティングを制限します。

ルーティングの制限に加えて、NodePort を使用する場合には他に 3 つの大きな欠点があります。

• ダウンストリーム クライアントは、各ノードに接続するためにその IP アドレスを知っている必要があります。ノードの IP アドレスまたは仮想マシン ホストが変更されると、これが問題になります。

• NodePort は複数の IP アドレスにトラフィックをプロキシできません。

• 図に示すように、NodePort は Kubernetes クラスター内で負荷分散を提供しないため、トラフィックはサービス間でランダムに分散されます。 これにより、サービスの過負荷やポート枯渇が発生する可能性があります。

  

ロードバランサー

LoadBalancer サービスは外部トラフィックを受け入れますが、そのトラフィックのインターフェースとして外部ロードバランサーが必要です。 外部ロードバランサが適切に調整され、実行中のポッドにマップするように再構成されている場合、これはレイヤー 7 ルーティング (ポッド IP アドレスへ) をサポートします。 LoadBalancer は、サービスを外部に公開する最も一般的な方法の 1 つです。 これはクラウド プラットフォームで最もよく使用され、小規模で静的な展開に適しています。

マネージド Kubernetes サービスを使用している場合は、クラウド プロバイダーによって選択されたロード バランサーが自動的に取得されます。 たとえば、Google Cloud Platform では LoadBalancer サービスタイプを使用してネットワーク ロード バランサを起動できますが、AWS ではアプリケーション ロード バランサ (ALB) がデフォルトです。 公開する各サービスには、すべてのトラフィックを転送する独自のパブリック IP アドレスが付与されますが、フィルタリングやルーティングは行われないため、ほぼすべての種類のトラフィック (HTTP、TCP/UDP、WebSocket など) を送信できます。 あるいは、クラウド プロバイダーのツールを使用したくない場合 (たとえば、より高度な機能やプラットフォームに依存しないツールが必要な場合) は、 F5 BIG-IP (外部ロード バランサーとして) やF5 Container Ingress Services (LoadBalancer 機能で動作するオペレーターとして) などに置き換えることができます。 このパターンの詳細については、弊社のブログの「同じアーキテクチャで BIG-IP と NGINX Ingress Controller をデプロイする」を参照してください。

変化する需要レベルに合わせてアプリ ポッドを拡張する必要がある動的な環境では、LoadBalancer を使用してアプリを公開することが困難になります。 各サービスには独自の IP アドレスが割り当てられるため、人気のあるアプリでは管理する IP アドレスが数百、あるいは数千に及ぶこともあります。 ほとんどの場合、外部ロード バランサは、次の図に示すように、NodePort を介してサービスに接続します。 これにより、トラフィックがノード間で均等に分散されることが保証されますが、サービスへの負荷分散は依然として不可能であるため、サービス過負荷とポート枯渇が発生します。

Kubernetes Ingress コントローラーとは何ですか?

Kubernetes のドキュメントによると、「コントローラーはクラスターの状態を監視し、必要に応じて変更を加えたり要求したりする制御ループです。 各コントローラーは、現在のクラスターの状態を目的の状態に近づけようとします。」 コントローラーは、リソースの適切な割り当て、永続ストレージの指定、cron ジョブの管理など、さまざまなタスクについて Kubernetes の状態を管理するために使用されます。

ルーティングのコンテキストでは、 Ingress コントローラーはNodePort と LoadBalancer の制限を克服する方法です。

Ingress コントローラーは、特定のサービスにラベル付けされたポッドとの外部のやり取りを構成および管理するために使用されます。 Ingress コントローラは、動的レイヤー 7 ルーティングを第一級オブジェクトとして扱うように設計されています。 つまり、Ingress コントローラーは、より少ない労力で、よりきめ細かい制御と管理を提供します。 Ingress コントローラは、Ingress トラフィックを制御するだけでなく、サービス レベルのパフォーマンス メトリックを提供したり、セキュリティ ポリシーの一部として使用したりするためにも簡単に使用できます。 Ingress コントローラには、TLS 終了、複数のドメインと名前空間の処理、そしてもちろんトラフィックの負荷分散など、従来の外部ロードバランサの多くの機能があります。 Ingress コントローラは、サービス レベルごとではなくリクエストごとにトラフィックを負荷分散できるため、レイヤー 7 トラフィックをより適切に把握でき、SLA をより適切に適用できます。

そしてもう一つボーナスがあります！ Ingress コントローラは、特定のポッドから特定の外部サービスへの送信トラフィックのみを許可する出力ルールを適用したり、トラフィックが mTLS を使用して相互に暗号化されるようにしたりすることもできます。 mTLS の要求は、医療、金融、通信、政府などの業界で規制されたサービスを提供するために不可欠であり、エンドツーエンド暗号化 (E2EE) 戦略の重要な要素です。 同じツールから送信トラフィックを制御すると、サービスへのビジネス ロジックの適用も簡素化されます。 イングレスとエグレスの両方が同じコントロール プレーンにリンクされている場合、適切なリソース ルールを設定するのがはるかに簡単になります。

次の図は、Ingress コントローラーによってクライアントの複雑さが軽減され、サービスの IP アドレスやポートを知る必要がなくなる様子を示しています。 サービス間でのトラフィックの分散が保証されます。 一部の Ingress コントローラは、柔軟性と制御性を高めるために複数の負荷分散アルゴリズムをサポートしています。

Ingress コントローラを使用したロードバランサのデプロイ

「同じアーキテクチャで BIG-IP と NGINX Ingress Controller をデプロイする」で説明したように、多くの組織では、Ingress コントローラ (またはほとんどの場合、複数の Ingress コントローラ インスタンス) を備えた外部ロード バランサをデプロイすることでメリットを得られるユースケースがあります。 これは、組織が Kubernetes を拡張したり、高コンプライアンス環境で運用したりする必要がある場合に特によく見られます。 ツールは通常、異なるチームによって管理され、異なる目的で使用されます。

• ロードバランサー（または ADC）：

  • 所有者： NetOps（またはSecOps）チーム
  • 使用事例： Kubernetes の外部では、クラスター外部のユーザーに配信されるサービスとアプリの唯一の公開エンドポイントとして機能します。 セキュリティを促進し、より高度なネットワーク管理を実現するように設計された、より汎用的なアプライアンスとして使用されます。

• イングレス コントローラ:

  • 所有者： プラットフォームオペレーションまたはDevOpsチーム
  • 使用事例： Kubernetes 内で、North-South トラフィック (HTTP2、HTTP/HTTPS、SSL/TLS 終端、TCP/UDP、WebSocket、gRPC) のきめ細かい負荷分散、API ゲートウェイ機能、および集中化されたセキュリティと ID を実現します。

この図は、ロード バランサーが複数のクラスター間でトラフィックの分散を処理し、クラスターに Ingress コントローラーがサービスへの均等な分散を保証する様子を示しています。

次のステップ

ここまで読んでもまだ頭を悩ませている場合は、Linux Foundation のウェビナー「Ingress コントローラーが必要な理由とその選び方」をご覧ください。このウェビナーでは、NGINX の専門家が Kubernetes ネットワークの入門書を提供し、Ingress コントローラーを詳細に説明し、Ingress コントローラーの状況について説明します。

Ingress コントローラーの使用方法と、要件に最適なコントローラーを選択する方法の詳細については、 「Ingress コントローラーの選択ガイド、パート 1」をお読みください。 要件を特定する 私たちのブログで。