サービス管理 - Container Service for Kubernetes - Alibaba Cloud ドキュメントセンター

Kubernetes において、サービスは、一連の Pod 上で実行されているアプリケーションをネットワークサービスとして公開する抽象化です。Pod に対して安定した DNS 名と負荷分散を提供します。本トピックでは、Kubernetes サービスの仕組み、重要な考慮事項、およびサービスタイプの選択に関する推奨事項について説明します。

基本概念

サービス

Pod の作成後に直接アクセスすると、いくつかの問題が発生する可能性があります。

Deployment などのコントローラーは、いつでも Pod を終了および再作成できるため、直接アクセスは信頼できません。
Pod の IP アドレスは起動時に動的に割り当てられるため、事前に予測することはできません。
アプリケーションは、多くの場合、同じイメージを実行する複数の Pod で構成されるため、各 Pod に個別にアクセスすることは実用的ではありません。

これらの問題を解決するため、Kubernetes にはサービスオブジェクトが用意されており、Pod に安定したネットワークインターフェースと永続的な IP アドレスを提供します。サービスは、ラベルセレクターを使用してターゲットとなる Pod のグループを識別し、負荷分散を用いてトラフィックを分散します。このアプローチにより、Pod への直接アクセスに関する問題が解決され、アプリケーションの高い可用性と効率が確保されます。

エンドポイント

Kubernetes において、エンドポイントは、サービスがサービス検出に使用する重要なリソースです。サービスのセレクターに一致する Pod の変更をリアルタイムで追跡します。Pod が削除または再作成されて IP アドレスが変更されると、エンドポイントリソースは Pod の IP アドレスとポートのリストを即座に更新します。これにより、サービスは常にアクティブで正常な Pod にトラフィックを転送できます。

IPVS

IPVS は、Linux カーネルの Linux Virtual Server (LVS) 機能に基づくロードバランサーです。仮想 IP を作成してバックエンド Pod にリクエストを分散することで、サービストラフィックを管理します。

Kubernetes でサービスを作成すると、kube-proxy は IPVS テーブルにルールを設定します。これらのルールは、ノードの仮想 IP からバックエンド Pod へのトラフィック転送方法を定義します。クラスターノード上の現在の IPVS ルーティングテーブルとルールは、ipvsadm コマンドを使用して表示できます。

重要

ipvsadm ツールがインストールされていない場合は、sudo yum install ipvsadm コマンドを実行してインストールしてください。

iptables

iptables は、設定可能なテーブルとチェーンのセットで動作します。各チェーンには、ネットワークパケットの流れを制御する一連のルールが含まれています。

Kubernetes でサービスを作成すると、kube-proxy は対応するルールを iptables に追加します。これらのルールは、サービスのラベルセレクターを使用して、正しい Pod にパケットを転送します。クラスターノード上の現在の iptables NAT テーブルとルールは、iptables -t nat -L コマンドを使用して表示できます。

nftables

nftables は、iptables を置き換えるために設計された、Linux カーネルの次世代パケットフィルタリングフレームワークです。統一されたルールセットとより効率的なパケットマッチングメカニズムを使用して、ネットワークトラフィックルールを処理します。

Kubernetes クラスターでサービスを作成すると、kube-proxy は nftables API を使用して、サービスのトラフィック転送ルールを管理するテーブルとチェーンを作成します。クラスターノード上のすべてのアクティブな nftables ルールとテーブル構造は、nft list ruleset コマンドを使用して表示できます。

サービスタイプ

重要

Cloud Controller Manager のバージョンが v2.5.0 以降の場合、コンソールで CLB インスタンスを使用してサービスを作成する機能は、従量課金のみをサポートするホワイトリスト機能となります。コンソールで CLB タイプのサービスを作成するには、クォータセンターページでリクエストを送信してください。

名前	説明	利用シーン	課金
ClusterIP	デフォルトのサービスタイプです。ClusterIP サービスには、クラスター内からのみ到達可能な仮想 IP アドレスが割り当てられます。	同一クラスター内でのみ通信が必要なサービスに最適です。たとえば、フロントエンドアプリケーションの Pod が同じクラスター内のバックエンドデータベースにアクセスする必要がある場合、データベースを ClusterIP サービスとして公開できます。	無料です。
NodePort	NodePort サービスは、クラスター内のすべてのノードで特定のポートを開きます。`<NodeIP>:<NodePort>` を使用して、クラスターの外部からサービスにアクセスできます。このメカニズムは、主に OSI モデルのレイヤー 4 (トランスポート層) で動作します。	開発、テスト、またはその他の低トラフィックのアプリケーション向けにサービスをインターネットに公開するのに適しています。たとえば、NodePort サービスを使用して、テスト環境で Web アプリケーションをデプロイおよびデバッグできます。LoadBalancer サービスとは異なり、ノード間の負荷分散は提供しません。トラフィックは 1 つのノードにのみ送信されるため、リソースのボトルネックになりやすいです。	無料です。パブリックインターネットアクセスを有効にするには、ノードに EIP を関連付ける必要があります。EIP の課金の詳細については、「課金概要」をご参照ください。
LoadBalancer	LoadBalancer サービスは NodePort タイプを拡張したもので、外部ロードバランサーをプロビジョニングして、クラスター内の Pod 全体にトラフィックを分散します。このサービスは、クライアントがアクセスに使用できる外部 IP アドレスを自動的に提供します。レイヤー 4 (TCP/UDP) とレイヤー 7 (HTTP/HTTPS) の両方のトラフィック管理をサポートしています。	パブリッククラウドで実行され、安定した管理しやすい外部エントリポイントを必要とするアプリケーションに最適です。たとえば、Web アプリケーションや API サービスなど、インターネットからのアクセスが必要で、高可用性で大量の外部トラフィックを処理する必要がある本番環境のパブリックサービスが該当します。重要クラスター内通信には、常に `ClusterIP` サービスを使用してください。これは、最も安定し、効率的で、アーキテクチャ的に健全な方法です。対照的に、同一クラスター内から `LoadBalancer` タイプのサービスにアクセスすると、動作が不安定になる可能性があります。その可用性は、以下を含む複数の要因に影響されます。クラウドプロバイダーによる LoadBalancer の特定の実装。クラスターが使用する CNI ネットワークプラグイン (Flannel、Terway-Eniip、Cilium など)。 `kube-proxy` の動作モード (iptables、IPVS、または nftables) とバージョン。サービスの `externalTrafficPolicy` 設定 (`Cluster` または `Local`)。そのため、クラスター内から LoadBalancer の IP にアクセスすると、環境や Kubernetes のバージョンによって動作が大きく異なるか、失敗することさえあります。シナリオ例：Flannel + IPVS + externalTrafficPolicy=Local `LoadBalancer` サービスが `externalTrafficPolicy: Local` で設定されている Flannel CNI ネットワークプラグインを使用するクラスターを考えます。対応するバックエンド Pod がないノードから LoadBalancer の外部 IP にリクエストが送信された場合： Kubernetes バージョン < 1.24：リクエストは正しく転送されず、アクセスは失敗します。 Kubernetes バージョン ≥ 1.24：`kube-proxy` は、クラスター内アクセスをサポートするために `Local` から `Cluster` の動作にフォールバックできます。リクエストは、別のノード上のバックエンド Pod に正常に転送されます。	ロードバランシングインスタンスの料金については、以下をご参照ください。 CLB 課金概要 NLB 課金ルール
ヘッドレスサービス	ヘッドレスサービスには仮想 IP アドレスがありません。サービス名に対する DNS クエリは、単一のサービス IP ではなく、Pod の IP アドレスのリストを返します。これにより、特定の Pod を直接検出し、接続することができます。	プロキシやロードバランサーを介さずに、特定のバックエンド Pod と直接通信する必要があるアプリケーションに最適です。たとえば、ClickHouse データベースサービスのようなステートフルアプリケーションをデプロイする場合、ヘッドレスサービスを使用できます。これにより、アプリケーション Pod は各 ClickHouse Pod に直接アクセスし、データ読み取りのバランスを取ったり、ターゲットを絞った書き込みを実行したりして、データ処理の効率を向上させることができます。	無料です。
ExternalName	ExternalName サービスは、内部サービス名を外部ドメイン名にマッピングします。これにより、クラスター内の Pod は、内部サービス名を使用して外部ドメインにアクセスできます。	クラスターがパブリックドメイン名で公開されているサービスにアクセスする必要がある場合に最適です。たとえば、アプリケーション Pod が外部データベースドメインにアクセスする必要がある場合、ExternalName サービスを使用してドメインを内部サービス名にマッピングし、クラスター内から直接アクセスできるようにします。	無料です。

仕組み

ClusterIP

作成と割り当て
ACK クラスターで ClusterIP サービスを作成すると、コントロールプレーンはクラスター内からのみアクセス可能な仮想 IP アドレス (ClusterIP) を割り当てます。
トラフィック転送
ClusterIP にアクセスすると、kube-proxy がトラフィックをインターセプトし、ラウンドロビンスケジューリングアルゴリズムを使用してバックエンド Pod に転送します。
サービス検出
ClusterIP サービスが作成されると、CoreDNS はその DNS レコードを登録し、サービスが名前で解決およびアクセスできるようになります。フォーマットは service-name.namespace.svc.cluster.local:port で、たとえば nginx.default.svc.cluster.local:80 のようになります。
Pod ラベルとエンドポイント追跡
サービスは、ラベルセレクターを使用してバックエンド Pod を識別します。
コントロールプレーンは、Pod の変更を継続的に監視します。サービスのラベルセレクターに一致する Pod が追加、更新、または削除されると、コントロールプレーンはエンドポイントを更新します。

NodePort

作成と割り当て
NodePort サービスを作成すると、クラスターは外部からのアクセスを許可するために、ノード上にポート (NodePort) を開きます。
トラフィック転送
kube-proxy は、デフォルトの範囲 30000-32767 から自動的に選択される NodePort をリッスンします。外部リクエストを ClusterIP にルーティングし、それがバックエンド Pod に転送されます。
外部アクセス
<NodeIP>:<NodePort> の形式で、ノードの IP アドレスと静的ポート (NodePort) を使用して、外部からサービスにアクセスできます。

LoadBalancer

作成と割り当て
LoadBalancer サービスを作成すると、コントロールプレーンは自動的にロードバランシングサービスと対話し、トラフィックを処理するためのロードバランサーインスタンスを作成します。詳細については、「既存の Server Load Balancer インスタンスを使用してアプリケーションを公開する」および「自動プロビジョニングされた LoadBalancer サービスでアプリケーションを公開する」をご参照ください。
トラフィック転送
外部トラフィックがロードバランサーインスタンスの外部 IP に到達すると、ノード上のポートにルーティングされます。その後、kube-proxy がトラフィックをバックエンド Pod に転送します。
ルートとヘルスチェック設定
ロードバランサーは、リスナーポートを自動的に設定し、ヘルスチェックを実行して、トラフィックが正常な Pod にのみルーティングされるようにします。

外部トラフィックポリシー

LoadBalancer および NodePort サービスには、外部トラフィックのルーティング方法を制御する externalTrafficPolicy 設定があります。この設定の動作は、Terway-Eniip と Flannel ネットワークプラグインを使用するクラスターで異なります。

説明

ACK コンソールにログインします。[クラスター] ページで、クラスターの名前をクリックします。[基本情報] タブで、クラスターが使用している CNI ネットワークプラグインを確認できます。

Flannel ネットワークプラグイン

項目	Local	Cluster
バックエンドサーバーのアタッチ	バックエンド Pod をホストするノードのみが、ロードバランサーのバックエンドサーバーとして追加されます。	クラスター内のすべてのノードが、ロードバランサーのバックエンドサーバーとして追加されます。
ロードバランサーのクォータ	消費するロードバランサーのクォータリソースが少なくなります。詳細については、「クォータ制限」をご参照ください。	すべてのクラスターノードがバックエンドとしてアタッチされるため、多数のロードバランサーのクォータリソースを消費します。詳細については、「クォータ制限」をご参照ください。
サービスへのクラスター内アクセス	サービスのバックエンド Pod をホストするノードのみがアクセスできます。	クラスター内のどのノードからでもサービスにアクセスできます。
Pod の負荷分散	Pod 間の負荷分散はデフォルトで無効になっています。負荷分散を有効にするには、サービスにアノテーション `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler:"wrr"` を追加して、スケジューラを WRR に設定します。	Pod 間の負荷分散はデフォルトで有効になっています。
ソース IP の保持	サポートされています。	サポートされていません。
セッション永続化	サポートされています。	サポートされていません。
利用シーン	ソース IP に基づくロギングなど、元のクライアント IP アドレスを保持する必要があるアプリケーション。	高いサービス可用性が要求され、ソース IP の保持が問題にならない場合 (大規模な Web アプリケーションクラスターなど)。

Terway-Eniip ネットワークプラグイン

項目	Local	Cluster
バックエンドサーバーのアタッチ	Pod は、ロードバランサーにバックエンドサーバーとして直接追加されます。
ロードバランサーのクォータ	アプリケーション Pod のみがアタッチされるため、消費するロードバランサーのクォータリソースが少なくなります。詳細については、「クォータ制限」をご参照ください。
サービスへのクラスター内アクセス	クラスター内からサービスにアクセスする場合、トラフィックはノード上の kube-proxy を通過し、`externalTrafficPolicy` の影響を受けます。その結果、サービスのバックエンド Pod をホストするノードのみがアクセスできます。	クラスター内のどのノードからでもサービスにアクセスできます。
Pod の負荷分散	Pod 間の負荷分散はデフォルトで有効になっています。
ソース IP の保持	サポートされています。
セッション永続化	サポートされています。

注意事項

サービスの負荷分散機能を使用する前に、関連する考慮事項を確認してください。詳細については、「サービスの負荷分散を設定する際の考慮事項」をご参照ください。

Container Service for Kubernetes:サービス管理