サービスを使用したサービス検出と負荷分散の実装 - Container Service for Kubernetes

Kubernetesでは、サービスは、ネットワーク経由でポッドのグループを公開するのに役立つ抽象化です。サービスは、サービスによって公開されるポッドのドメイン名を提供し、ポッド間の負荷分散を実装します。このトピックでは、サービスの仕組みとLoadBalancerサービスの設定に関する注意事項について説明します。このトピックでは、さまざまな種類のサービスを選択してアプリケーションを公開する方法についても説明します。

条件

サービス

ポッドを作成した後、ポッドに直接アクセスすると、次の問題が発生する可能性があります。

ポッドは、そのコントローラ (配置など) によって削除および再作成することができる。したがって、ポッドへのアクセスは不安定です。
IPアドレスは、ポッドの起動後に動的にポッドに割り当てられます。ポッドが起動される前に割り当てられるIPアドレスを予測することはできません。
アプリケーションは、同じイメージを実行する複数のポッドで構成されます。したがって、アプリケーションの個々のポッドにアクセスすることはできません。

上記の問題に対処するために、KubernetesはServiceオブジェクトを提供します。サービスは、サービスによって公開されるポッドの安定したネットワークインターフェイスと永続的なIPアドレスを提供します。サービスは、ラベルセレクタを使用して公開するポッドを選択し、ポッド間の負荷分散を実装します。これにより、前述の問題に対処し、アプリケーションの高可用性と効率を保証します。

Endpoint

Kubernetesでは、サービスに基づくサービス検出の実装においてエンドポイントが重要な役割を果たします。エンドポイントは、サービスのラベルセレクターと一致するポッドの変更をリアルタイムで追跡します。ポッドが削除または再作成されると、ポッドのIPが変更されます。この場合、対応するエンドポイントは新しいポッドのIPアドレスとポートを更新して、サービスが新しいポッドにトラフィックを転送できるようにします。

IPVS

IP Virtual Server (IPVS) は、Linux Virtual Server (LVS) に基づくロードバランサーです。 IPVSは仮想IPアドレスを作成して、サービスが受信したトラフィックをサービスのバックエンドポッドに配信します。

サービスを作成するとき、kube-proxyはIPVSルートテーブルでサービスのルーティングルールを指定します。ルーティングルールは、ノードの仮想IPアドレスからバックエンドポッドにトラフィックを転送する方法を決定します。ノードでipvsadmコマンドを実行して、ノードのIPVSルートテーブルとテーブル内のルーティングルールを照会できます。

iptables

iptablesは、設定可能なテーブルとチェーンのセットを使用して、パケットの送信方法を決定します。各チェーンは、ルールのセットに対応する。

サービスを作成するとき、kube-proxyはiptablesのテーブルでサービスのルーティングルールを指定します。これらの規則は、サービスのラベルセレクターと一致するポッドにパケットを送信する方法を決定します。ノードでiptables -t nat -Lコマンドを実行して、ノード上のiptablesのテーブルとテーブル内のルーティングルールを照会できます。

サービスタイプ

機能	説明	シナリオ	課金
ClusterIP	デフォルトのサービスタイプ。 ClusterIPサービスは、クラスタ内仮想IPアドレスを使用します。	このタイプのサービスは、クラスター内でのみアプリケーションを公開する必要があるシナリオに適しています。たとえば、フロントエンドアプリケーションのポッドが同じクラスター内のバックエンドデータベースにアクセスする必要がある場合、ClusterIPサービスを使用してクラスター内のデータベースを公開できます。	無料です。
NodePort	NodePortサービスはノードポートを公開します。 `<NodeIP >:< NodePort>` にリクエストを送信することで、NodePortサービスにアクセスできます。 NodePortサービスは、Open Systems Intercommunication (OSI) モデルのレイヤー4で機能します。	このタイプのサービスは、アプリケーションを一時的にインターネットに公開する必要がある場合や、アプリケーションがポートで少量の外部トラフィックを受信する必要がある場合に適しています。たとえば、テスト環境にwebアプリケーションを配置する場合は、NodePortサービスを使用してアプリケーションを公開できます。 LoadBalancerサービスと比較して、NodePortサービスはノード間の負荷分散を実装していません。 NodePortサービスを使用してアプリケーションにアクセスする場合、トラフィックはリクエストを送信するノードにのみ転送されます。この場合、リソースのボトルネックがノードで発生しやすくなります。	無料です。インターネットアクセスを有効にする場合は、elastic IPアドレス (EIP) をノードに関連付けます。 EIP課金の詳細については、「請求明細」をご参照ください。
LoadBalancer	LoadBalancerサービスは、ロードバランサーで構成されたNodePortサービスに似ています。このタイプのサービスは、トラフィックを複数のポッドに均等に分散できます。 LoadBalancerサービスは、バックエンドポッドを外部アクセスに公開するためのパブリックIPアドレスを自動的に提供します。 LoadBalancerサービスは、レイヤー4でTCPおよびUDPリクエストを処理し、レイヤー7でHTTPおよびHTTPSリクエストを管理できます。	このタイプのサービスは、クラウドにデプロイされたアプリケーションに安定した管理しやすいイングレスを提供するシナリオに適しています。たとえば、LoadBalancer Servicesを使用して、webアプリケーションやAPIサービスなど、本番環境に展開されているパブリックサービスをインターネットに公開できます。これにより、サービスの高可用性が保証され、トラフィックスパイクに耐えることができます。	Server Load Balancer (SLB) は、LoadBalancer Servicesで使用されるSLBインスタンスに対して料金を請求します。詳細については、次をご参照ください： CLB課金の概要と NLB課金ルール
ExternalName	ExternalNameサービスは、サービスを外部ドメイン名にマップするために使用されます。これにより、クラスター内のポッドは、サービスを使用して外部ドメイン名にアクセスできます。	このタイプのサービスは、クラスターがパブリックドメイン名にアクセスする必要があるシナリオに適しています。たとえば、アプリケーションが外部データベースのドメイン名にアクセスする必要がある場合、ドメイン名をExternalNameサービスにマップできます。これにより、アプリケーションのポッドは、クラスター内からExternalNameサービスを使用してドメイン名にアクセスできます。	無料です。
ヘッドレスサービス	ヘッドレスサービスには、固定の仮想IPアドレスがありません。ヘッドレスサービスのバックエンドポッドにアクセスすると、サービスはDNSルックアップを実行し、IPアドレスのリストを返します。その後、要件に基づいてリスト内の任意のIPアドレスに直接接続できます。	このタイプのサービスは、プロキシやロードバランサーの代わりにDNSレコードを使用して個々のバックエンドポッドに直接アクセスする必要があるシナリオに適しています。たとえば、ヘッドレスサービスを使用して、StatefulSetとして配置されるClickHouseアプリケーションを公開できます。これにより、ClickHouseアプリケーションの各ポッドにアクセスできます。これにより、ポッド間で読み取りと書き込みのバランスを取り、データ処理効率を向上させることができます。	無料です。

サービスのしくみ

ClusterIP

作成と割り当て
Container Service for Kubernetes (ACK) クラスターでClusterIPサービスを作成すると、クラスターのコントロールプレーンは、クラスターのサービスCIDRブロックからサービスに仮想IPアドレスを割り当てます。仮想IPアドレスはクラスタIPアドレスです。クラスターIPアドレスは、クラスター内からのみアクセスでき、ポッドCIDRブロックに属していません。
トラフィック転送
クラスター内からClusterIPサービスにアクセスすると、リクエストはkube-proxyによってキャプチャされます。 kube-proxyは、iptablesまたはIPVSルールに基づくラウンドロビンスケジューリングアルゴリズムを使用して、リクエストをバックエンドポッドに転送します。
サービス検出
ClusterIPサービスを作成すると、新しいDNSレコードがCoreDNSに追加されます。 DNSレコードを使用して、ClusterIPサービス名をそのクラスターIPアドレスに解決できます。 ClusterIPサービスにアクセスするには、Service.Namespace.svc.cluster.local:port形式 (nginx.de fault.svc.cluster.local:80など) のエンドポイントにリクエストを送信します。
ポッドラベルとエンドポイントの追跡
各サービスには、バックエンドポッドの選択に使用される一連のラベルセレクターがあります。
クラスターモニタポッドの制御プレーンは、クラスター内でリアルタイムに変化します。新しいポッドがサービスのラベルセレクターと一致するか、ラベルセレクターと一致する既存のポッドが更新または削除されると、クラスターの制御プレーンによってサービスのエンドポイントが更新されます。

NodePort

作成と割り当て
NodePortサービスを作成すると、クラスターはクラスターIPアドレスをサービスに割り当て、サービスのノードポートを公開します。ノードポートは、特定のポート範囲 (デフォルトでは30000 32767) から自動的に割り当てられます。カスタムノードポートを指定することもできます。
トラフィック転送
kube-proxyは、クラスター内の各ノードでNodePortサービスに対して公開されているノードポートをリッスンします。外部リクエストがノードのノードポートに到達すると、kube-proxyはリクエストをクラスターIPアドレスにルーティングしてからバックエンドポッドにルーティングします。
外部アクセス
NodePort Serviceにアクセスするには、<NodeIP >:< NodePort> 形式で外部エンドポイントにリクエストを送信します。

LoadBalancer

作成と割り当て
SLBインスタンスを指定せずにLoadBalancerサービスを作成すると、クラスターのコントロールプレーンが自動的にサービスのSLBインスタンスを作成します。詳細については、「既存のSLBインスタンスを使用してアプリケーションを公開する」および「自動作成されたSLBインスタンスを使用してアプリケーションを公開する」をご参照ください。
トラフィック転送
外部リクエストがSLBインスタンスの外部IPアドレスに到達すると、SLBインスタンスは、負荷分散ポリシーに基づいて、ノード上のノードポートにリクエストをルーティングします。次に、ノードのkube-proxyは、iptablesまたはIPVSルールに基づいて要求をバックエンドポッドに転送します。
ルーティングとヘルスチェックの設定
SLBインスタンスは、Service YAMLファイルで指定されたリスニングポートを自動的に使用し、ポートで受信したリクエストをServiceのラベルセレクターと一致するポッドに転送します。さらに、SLBはSLBインスタンスのヘルスチェック設定を自動的に設定して、リクエストが正常なポッドにのみルーティングされるようにします。

外部トラフィックポリシー: ローカルとクラスター

externalTrafficPolicyパラメーターを指定して、LoadBalancerまたはNodePortサービスの外部トラフィックポリシーを設定できます。外部トラフィックポリシーは、外部リクエストをバックエンドポッドにルーティングする方法を指定します。ローカルとクラスターの2つの外部トラフィックポリシーがサポートされています。外部トラフィックポリシーの機能は、クラスターで使用されるネットワークプラグインによって異なります。次のセクションでは、Terway-EniipまたはFlannelをネットワークプラグインとして使用する場合の外部トラフィックポリシーの機能について説明します。

説明

ACKコンソールにログインします。 [クラスター] ページで、クラスターの名前をクリックします。 [基本情報] タブで、[クラスター情報] セクションでクラスターのネットワークプラグインを表示できます。

Flannel

クラスターがFlannelネットワークプラグインを使用している場合、ノードのNodePortサービスはトラフィックをバックエンドポッドに転送します。

ローカル: トラフィックは、リクエストの送信先ノードのポッドにのみルーティングされます。
クラスター: トラフィックは、クラスター内の他のノードのポッドにルーティングできます。

次の表に、ローカルポリシーとクラスタポリシーの違いを示します。

項目	ローカル	クラスター
バックエンドサーバー	バックエンドポッドがデプロイされているノードのみが、バックエンドサーバーとしてSLBインスタンスに追加されます。	クラスター内のすべてのノードがバックエンドサーバーとしてSLBインスタンスに追加されます。
SLBリソースのクォータ	このポリシーは少量のSLBリソースを消費し、高いSLBリソースクォータを必要としません。 SLBリソースクォータの詳細については、「クォータ」をご参照ください。	クラスター内のすべてのノードがバックエンドサーバーとしてSLBインスタンスに追加されるため、このポリシーでは高いSLBリソースクォータが必要です。 SLBリソースクォータの詳細については、「クォータ」をご参照ください。
SLBインスタンスのIPアドレスへのアクセス	バックエンドポッドがデプロイされているノードのみが、SLBインスタンスのIPアドレスにアクセスできます。	クラスター内のすべてのノードがSLBインスタンスのIPアドレスにアクセスできます。
ポッド間の負荷分散	デフォルトでは、ポッド間の負荷分散は無効になっています。ポッド間の負荷分散を有効にするには、`service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler:"WRR"` アノテーションをService YAMLファイルに追加して、スケジューリングアルゴリズムをwrr (加重ラウンドロビン) に設定します。	デフォルトでは、ポッド間の負荷分散が有効になっています。
ソースIPの保存	対応	非対応
セッション維持	対応	非対応
利用シナリオ	クライアントIPアドレスをログに記録する必要があるアプリケーションなど、クライアントIPアドレスを保持する必要があるアプリケーション。	大規模なwebアプリケーションクラスタなど、高可用性を必要とするがクライアントIPアドレスを保持する必要のないアプリケーション。

Terway-エニップ

クラスターがTerway-Eniipネットワークプラグインを使用している場合、使用されている外部トラフィックポリシーに関係なく、トラフィックはバックエンドポッドに直接転送されます。