※ 本記事は、Ajay Chhabriaによる”Using a network load balancer for Kubernetes services“を翻訳したものです。
2022年5月10日
コンテナ化されたアプリケーションと、本番でのKubernetesの導入は急増しており、Oracle Cloud Infrastructure（OCI）のお客様全体にその傾向が見られます。 Kubernetesクラスタ管理者の主な考慮事項の1つは、可用性、セキュリティ、特にKubernetesクラスタへのトラフィック・パスを維持して関連するマイクロサービスにアクセスすることです。 Kubernetesサービス用のOCIフレキシブル・ロード・バランシング（タイプ: Load Balancer）などのロード・バランサは、インターネットにサービスを公開する標準的な方法です。ロード・バランサは、一連のワークロードを一連のリソースに分散するのに役立ち、ネットワーク・トラフィックをクラスタ内の複数のワーカー・ノードに誘導する汎用ネットワーキング・サービスを提供します。フレキシブル・ロード・バランサは、クライアントとOracle Container Engine for Kubernetes（OKE）クラスタで実行されているアプリケーションの間のプロキシとして機能します。フレキシブル・ロード・バランサへの受信アプリケーション・トラフィックは、複数のワーカー・ノードに分散されます。
最近、OKE: フレキシブル・ネットワーク・ロード・バランサで、別のタイプのロード・バランサのサポートが追加されました。ネットワーク・ロード・バランサは非プロキシ・ロード・バランシング・ソリューションであり、レイヤー3およびレイヤー4のワークロード（Transmission Control Protocol （TDP）、User Datagram Protocol（UDP）およびInternet Control Message Protocol（ICMP））のパススルー・ロード・バランシングを実行します。このロード・バランシング・ソリューションは、リアルタイム・ストリーミング、VoIP、Internet of Things、取引プラットフォームなどのレイテンシセンシティブなワークロードに最適です。ネットワーク・ロード・バランサは接続レベルで動作し、IPプロトコル・データに基づいて受信クライアント接続を正常なバックエンド・サーバーに分散します。
ネットワーク・ロード・バランサを使用する利点
ネットワーク・ロード・バランサは、1秒当たり数万件のリクエストを処理しながら、超低レイテンシで高いスループットを維持し、ユーザーの労力をかけずに設計されています。最小または最大帯域幅の構成要件なしでクライアント・トラフィックに基づいてスケール・アップまたはスケール・ダウンでき、高可用性と低レイテンシのメリットが得られます。この多重化機能を提供することで、ネットワーク・ロード・バランサはスケーラブル・サービスの基本的な構成ブロックになります。
Kubernetesクラスタ管理者として、OKEクラスタに入っているすべてのパケットを検査し、悪意のあるトラフィックをブロックするようにファイアウォールを構成するタスクがあります。モードがTransmission Control Protocol（TCP）に設定されている場合、OCIフレキシブル・ロード・バランサから取得されるHTTP Xヘッダーは、ネットワーク・パケットでは使用できません。ネットワーク・ロード・バランサは、パケット特性を変更せず、クライアント・ソースおよび宛先IPヘッダー情報を保持する、ワイヤ内のレイヤー3の透過的ロード・バランサとして機能します。ソースIPと宛先IPが保持されていると、インターネットに直接接続されているロード・バランサの背後にあるアプリケーションへのアクセスを許可できます。
OCIネットワーク・ロード・バランサは、OSIレイヤー3および4（TCP/UDP/ICMP）ワークロードのパススルー・ロード・バランシングを実行する非プロキシlayer-4ロード・バランシング・ソリューションです。これには、レイヤー4のパススルー・ロード・バランシングおよびクライアント・ヘッダーの保持が含まれます。ネットワーク・ロード・バランサは接続レベルで動作し、受信クライアント接続を正常なOKEワーカー・ノードに分散します。ロード・バランシング・ポリシーは、ハッシュ・アルゴリズムを使用して受信トラフィックを分散します。デフォルトのロード・バランシング分散ポリシーは、ソースおよび宛先のIPアドレス、ポートおよびIPプロトコル情報の5タプル・ハッシュに基づきます。この5タプル・ハッシュ・ポリシーは、特定のTCPまたはUDPセッション内のセッション・アフィニティを提供します。このセッション内のパケットは、ネットワーク・ロード・バランサの背後にある同じバックエンド・サーバーに送られます。3タプル（ソースIP、宛先IPおよびプロトコル）または2タプル（ソースIPおよび宛先IP）のロード・バランシング・ポリシーを使用して、特定のセッションの存続期間を超えてセッション・アフィニティを提供できます。
ネットワーク・ロード・バランサ・サービスの作成
クライアントIPアドレスを保持するアプリケーションの場合、注釈oci.oraclecloud.com/load-balancer-type: “nlb”をサービス定義に追加できます。
ネットワーク・ロード・バランサによってバックアップされるサービスを作成するには、サービス・マニフェストのメタデータ・セクションで注釈を指定します。
apiVersion: v1
kind: Service
metadata:
name: my-nginx-svc
labels:
app: nginx
annotations:
oci.oraclecloud.com/load-balancer-type: "nlb"
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: nginxセキュリティのベスト・プラクティスとして、Oracleでは、ネットワーク・セキュリティ・グループ（NSG）またはサブネット・セキュリティ・リストの一部として、ロード・バランサのネットワーク・セキュリティ・ルールを指定することをお薦めします。
ネットワーク・セキュリティ・グループをネットワーク・ロード・バランサに関連付けるには、次の注釈をサービス定義に追加します。
oci.oraclecloud.com/oci-network-security-groups: "ocid1.networksecuritygroup.oc1.xxxx"外部トラフィック・ポリシーの構成
Kubernetes仕様externalTrafficPolicyは、クライアントIPが保持されているかどうかを示します。ネットワーク・ロード・バランサの使用方法とそれぞれの利点については、2つの異なるモードまたはアーキテクチャについて見てみましょう。
外部トラフィック・ポリシーを構成する2つのモードは、cluster(default)とlocalです。クラスタ・モードでは、クライアント・ソースIPがわかりにくくなり、別のノードへの2回目のホップが発生する可能性がありますが、全体的なロード・スパンは良好です。localオプションは、アプリケーション・ポッドまでのすべての方法で、パケットのヘッダーに発信元IPアドレスを保持します。
externalTrafficPolicy: クラスタ
クラスタは、Kubernetesサービスのデフォルトの外部トラフィック・ポリシーです。均等に分散されているサービスを実行しているすべてのポッドにトラフィックをルーティングし、クライアントIPアドレスを保持することを想定しています。これは、ノード上のそのサービスのトラフィックをポッドが処理できるかどうかに関係なく、クラスタのすべてのワーカー・ノードで30000から32767の範囲からランダム・ポートを開くことによって動作します。 Kubernetesは、そのポートのワーカーに送信されたすべてのトラフィックを、そのサービスのポッドの1つに転送します。
このモードでは、クラスタ内のポッドの状態に依存しないため、多くの場合、クラスタのバックエンドの回数が少なくなります。任意のリクエストを任意のノードに送信でき、Kubernetesはそれを適切な場所に取得します。これにより、ワーカー・ノード間でネットワーク・ロード・バランサからのロード・スパンが良好になります。
トラフィックがKubernetesノードに到達すると、ロード・バランサのタイプに関係なく、ノードは同じ方法で処理されます。ネットワーク・ロード・バランサは、クラスタ内のどのノードがサービスのポッドを実行しているか認識していません。リージョナル・クラスタでは、クラスタのリージョンのすべての可用性ドメイン内のすべてのノードに負荷が分散されます。
トラフィックがノードにルーティングされると、ノードはトラフィックをポッドにルーティングします。ポッドは、同じノードまたは別のノードで実行できます。このノードは、kube-proxyがノード上で管理するiptablesルールを使用して、ランダムに選択されたポッドにトラフィックを転送します。
このモードでは、関連するポッドを実行していないノードでも、クラスタ内のすべてのノード間でトラフィックがロード・バランシングされます。ネットワーク・ロード・バランサはバックエンドのヘルス・チェックに合格し、リクエストによってネットワーク・ホップが余分になります。これは、正しいポッドが付いていないノードに到達してから、別のノードに送信する必要があるためです。
externalTrafficPolicy: ローカル
HTTPリクエストでクライアントIPを保持する場合は、サービス仕様で”externalTrafficPolicy: Local”を指定します。この外部トラフィック・ポリシーでは、プロキシ・ルールは、配置された場所に関係なく、サービスのすべてのポッドではなく、同じノード（ローカル）に存在するポッドに対してのみ、特定のNodePort（30000-32767）に構成されます。このモードでは、クラスタ・モードからの余分なネットワーク・ホップが回避されますが、適切に構成されていない場合、トラフィックが不均衡になる可能性があります。
ネットワーク・ロード・バランサでは、すべてのKubernetesノードをバックエンドとして追加する必要がありますが、ネットワーク・ロード・バランサのヘルス・チェック機能に依存して、対応するNodePortがレスポンシブで適切なポッドが実行されているバックエンドにのみトラフィックを送信できます。
このアーキテクチャでは、イングレス・トラフィックは、そのサービスの対応するポッドを実行しているノードに配置する必要があり、そうしないとトラフィックは削除されます。ネットワーク・ロード・バランサはKubernetesクラスタのポッド配置を認識していないため、各バックエンド（Kubernetesノード）がトラフィックの均等な分散を受信するとみなされます。図に示すように、この仮定では、他のポッドよりも多くのトラフィックを受信するアプリケーションのポッドを選択できます。
クライアントIPを保持するには、ワーカー・ノードは、クライアントが存在するインターネットまたはCIDRからのトラフィックを受け入れる必要があります。ワーカー・ノードのイングレス・セキュリティ・ルールに、適切なCIDRからのトラフィックを許可するルールがあることを確認します。
...
spec:
type: LoadBalancer
externalTrafficPolicy: Local
...OKEでのUser Datagram Protocolアプリケーションの公開
多くの場合、Kubernetes内でHTTPベースではないサービスを実行する必要があります。User Datagram Protocol（UDP）は、リアルタイム・ストリーミング、オンライン・ゲーム、Internet of Things（IoT）などのワークロードに最適な低レイテンシ・プロトコルです。UDPトラフィックを収集するためにプロキシ・サーバーのフリートを維持する必要がなくなり、TCPトラフィックとUDPトラフィックの両方に同じロード・バランサを使用できるようになりました。OCIフレキシブル・ネットワーク・ロード・バランサにより、Oracle Container Engine for Kubernetesで任意のTCPまたはUDPアプリケーションをデプロイおよびスケーリングできます。UDP、Kubernetesおよびネットワーク・ロード・バランサを組み合せると、顧客は敏捷性を向上させながら、低レイテンシの要件を満たすことができます。
たとえば、ゲーム・エンタープライズは、ネットワーク・ロード・バランサを使用してUDPベースのゲーム・サーバーをデプロイしようとしています。デプロイに使用されるアーキテクチャは、次のコンポーネントで構成されています。
- Oracle Container Engine for Kubernetes（OKE）クラスタおよびArmベースのOracleプロセッサを搭載したOracle Linuxインスタンスのノード・プール
- UDPゲーム・サーバーは、ネットワーク・ロード・バランサを使用するサービスであるOKEにデプロイされます。
- ゲーム サーバーにはUDPヘルス プローブも組み込まれており、これはlivenessプローブとして使用されます。
- ネットワーク・ロード・バランサには、単一のバックエンド・セットに関連付けられたUDPリスナーがプロビジョニングされています。このバックエンド・セットは、バックエンドを登録するように構成され、UDPプロトコルを使用してバックエンドに対してヘルス・チェックを実行します。
OKEがLoadBalancerタイプのKubernetesサービスにネットワーク・ロード・バランサをプロビジョニングする場合、リスナーが接続リクエストを受け入れるプロトコルを指定することで、リスナーが受け入れるトラフィックのタイプを定義できます。プロトコルを明示的に指定しない場合、TCPはデフォルト値として使用されます。
spec:
type: LoadBalancer
ports:
- port: 80
protocol: UDPまとめ
ロード・バランシングは、ミッションクリティカルなKubernetesクラスタを大規模に稼働させ、かつ安全に保つために不可欠です。OCIフレキシブル・ロード・バランサやフレキシブル・ネットワーク・ロード・バランサなどの多くのロード・バランサは、これらのリスクの多くを管理するのに有効ですが、これらのロード・バランサが提供する機能を最も活用するには、Kubernetes環境を正しく構成することが重要です。
詳細は、OCIドキュメントのLoadBalancerタイプのKubernetesサービスの定義およびOCIネットワーク・ロード・バランシングを参照してください。これらの新機能と、Oracle Cloud Infrastructureが提供するエンタープライズ・グレードのすべての機能を体験したいと考えています。今すぐAlways Freeアカウントを作成し、300米ドルの無料クレジットでロード・バランサ・オプションを試してください。