Kubernetesロードバランシング：実例で学ぶ5つの技術的選択肢

Kubernetesのロードバランシングとは

Kubernetesのロードバランシングとは、高可用性・スケーラビリティ・最適なパフォーマンスを確保するために、複数のPodへネットワークトラフィックを自動的に分散する仕組みです。クラスター内部での管理と、外部ユーザーへの公開という2つの主要なレイヤーで動作します。

リクエストのルーティングと分散の複雑さを抽象化することで、Kubernetesは開発者がトラフィック分散を手動で管理することなく、スケーラブルなアプリケーションをデプロイできるようにします。この自動化は、現代のコンテナ化された環境における高可用性、耐障害性、パフォーマンスに不可欠です。

Kubernetesでロードバランシングを実装するための技術的選択肢:

• ClusterIP（内部向け）: 仮想IPを使用してクラスター内部のPod間でトラフィックを分散します。内部のサービス間通信におけるデフォルトの選択肢です。
• NodePort: クラスターの全ノード上の静的ポートでServiceを公開し、外部クライアントが <NodeIP>:<NodePort> を通じてアプリケーションにアクセスできるようにします。
• LoadBalancer: クラウドやインフラのロードバランサーと連携し、クラスターノードとバックエンドPodにトラフィックを分散する外部IPアドレスを提供します。
• Ingress: レイヤー7のHTTP/HTTPSルーティングを提供し、ホストベース・パスベースのルーティングルールにより、複数のServiceが単一の外部エンドポイントを共有できるようにします。
• Gateway API: 専用のGatewayリソースとRouteリソースを使用し、複数プロトコルへの対応やチームごとの役割分離をサポートする、ポリシー主導の高度なトラフィック管理を提供します。

本記事はKubernetesスケジューリングに関する連載の一部です。

Kubernetesでロードバランシングが必要な理由

Kubernetes環境は動的です。Podはアプリケーションの需要やクラスターの状態に応じて、いつでも作成・終了・再スケジュール・スケールされる可能性があります。ロードバランシングがなければ、過負荷状態や利用不能なPodにトラフィックが流れ続け、応答の遅延、リクエストの失敗、ダウンタイムを引き起こしかねません。

ロードバランシングにより、Kubernetesはアプリケーションの安定したパフォーマンスと可用性を維持できます。正常なPodにリクエストを分散し、障害発生時にはトラフィックを再ルーティングします。これにより、Podのクラッシュ、ローリングアップデート、インフラの変更中でも、アプリケーションはユーザーへのサービス提供を継続できます。

Kubernetesでロードバランシングが必要とされる主な理由は次のとおりです。

• 単一のPodやノードへのトラフィック集中の防止
• レプリカ間へのリクエスト分散による水平スケーリングのサポート
• Podやノードの障害時における高可用性の維持
• ゼロダウンタイムのデプロイとローリングアップデートの実現
• アプリケーションの応答時間と信頼性の向上
• 動的なコンテナ環境におけるトラフィックルーティングの簡素化
• トラフィックの変化に応じたサービスの自動スケーリング

コンテナは短命であり、ワークロードは常に変化するため、自動化されたロードバランシングは安定したKubernetes運用の中核的な要件です。

Kubernetesロードバランシングの5つの実装方法

1. ClusterIP（内部向け）

ClusterIPはKubernetesのデフォルトのServiceタイプです。クラスター内部からのみ到達可能な仮想IPアドレスを作成するため、フロントエンド、API、データベースといった内部サービス間の通信に適しています。外部クライアントはClusterIPのServiceに直接アクセスできないため、バックエンドサービスをパブリックネットワークから隔離するのに役立ちます。

ClusterIPアドレスにリクエストが送信されると、kube-proxy がトラフィックを捕捉し、Serviceの背後にある正常なPodのいずれかに転送します。Podの追加・削除・入れ替えに応じてルーティングルールが自動的に更新されるため、アプリケーション側でPodのIPアドレスを追跡することなく、利用可能なレプリカ間にリクエストが分散されます。

ロードバランシングの判断には、クラスターの構成に応じて iptables、IPVS、eBPFベースのネットワーク実装のいずれかが使用されるのが一般的です。アプリケーションは安定したServiceエンドポイントと通信し、背後のPodの変化はKubernetesが処理するため、ClusterIPはほとんどの内部サービス間通信の基盤となっています。

2. NodePort

NodePort Serviceは、Kubernetesクラスターの全ノード上の静的ポートでアプリケーションを公開します。クライアントは <NodeIP>:<NodePort> にリクエストを送ることでアプリケーションにアクセスでき、専用のクラウドロードバランサーを用意しなくても外部トラフィックをワークロードに到達させられます。

トラフィックがノードに到着すると、kube-proxy がServiceによって選択されたPodのいずれかにリクエストをルーティングします。対象のPodが別のノードで稼働している場合でも問題ありません。レプリカ数が変化しても、NodePortは一定のまま、Kubernetesが正常なPod間でリクエストの分散を継続します。

すべてのノードが同じポートで待ち受けるため、ユーザーはどのクラスターノードに接続してもアプリケーションに到達できます。NodePortは開発環境やオンプレミスのクラスター、あるいは LoadBalancer のような上位サービスの基盤として一般的に使用されますが、本番環境でNodePortを通じてアプリケーションを直接公開するケースは多くありません。

3. LoadBalancer

LoadBalancer Serviceは、NodePortをベースに、クラウドプラットフォームや対応インフラが提供する外部ロードバランサーとKubernetesを統合します。パブリックまたはプライベートのIPアドレスをプロビジョニングし、クライアントは個々のクラスターノードに直接接続することなくアプリケーションにアクセスできます。

外部ロードバランサーは、受信した接続をクラスターノード間に分散します。リクエストはその後、対応するNodePort Serviceを経由して転送され、kube-proxyが正常なバックエンドPodを選択します。これにより、ノード間のインフラレベルのロードバランシングと、Pod間のKubernetesレベルのロードバランシングの両方が実現されます。

ほとんどのマネージドKubernetesサービスでは、このServiceタイプが作成されると、AWS、Azure、Google Cloudなどのプロバイダーが提供するクラウドネイティブなロードバランサーが自動的にプロビジョニングされます。ヘルスチェックによってトラフィックが正常なノードにのみ送られることが保証され、Podのスケールや入れ替えに応じてKubernetesがバックエンドのエンドポイントを継続的に更新します。

4. Ingress

Ingressは、単一のエントリーポイントを通じて複数のアプリケーションにレイヤー7（HTTP/HTTPS）ルーティングを提供します。各Serviceを個別の外部IPアドレスで公開する代わりに、Ingressリソースがホスト名、URLパス、その他のHTTP属性に基づくルーティングルールを定義します。これらのルールは、TraefikなどのIngressコントローラーが実装します。

クライアントがHTTPまたはHTTPSリクエストを送信すると、Ingressコントローラーはルーティングルールを評価し、適切なKubernetes Serviceにリクエストを転送します。Serviceはその後、バックエンドのPod間にトラフィックを分散します。このアプローチはアプリケーションの公開を簡素化しつつ、TLS終端、リダイレクト、認証、リクエストの書き換えといった機能をサポートします。

複数のServiceが同じ外部エンドポイントを共有できるため、Ingressは必要なパブリックIPアドレスとロードバランサーの数を削減します。HTTPおよびHTTPSトラフィックの一元管理を提供しながら、Webアプリケーション、API、マイクロサービスを公開する用途で広く使われています。

5. Gateway API

Gateway APIは、アプリケーショントラフィックをより柔軟かつ拡張性高く管理できる、比較的新しいKubernetesネットワーキング標準です。インフラ構成とアプリケーションルーティングを分離しており、プラットフォームチームがゲートウェイを管理する一方で、アプリケーションチームは自分たちのサービスがトラフィックをどのように受け取るかを定義できます。

トラフィックはまず、ネットワークのエントリーポイントを表すGatewayに入ります。HTTPRoute などのルーティングリソースが、リクエストをどのようにマッチさせてKubernetes Serviceに転送するかを指定します。リクエストが選択されたServiceに到達すると、Kubernetesは標準のロードバランシング機構を用いて利用可能なPod間に分散します。

Ingressと比較して、Gateway APIはルーティングポリシー、トラフィック分割、マルチテナント環境に対するより細やかな制御を提供します。また、HTTPだけでなくTCPやgRPCを含む複数のプロトコルをサポートしており、複雑なネットワーク要件や大規模なKubernetesデプロイメントにより適しています。

Kubernetes LoadBalancer vs. Ingress vs. API Gateway

これらの選択肢の違いを以下の表にまとめます。

Kubernetesロードバランシングのユースケース

内部サービス間ロードバランシング

内部サービス間ロードバランシングは、同じKubernetesクラスター内で稼働するアプリケーション間のトラフィックを分散します。サービスは安定したエンドポイントを通じて通信でき、Kubernetesが利用可能なPodへ自動的にリクエストをルーティングします。このアプローチは、ワークロードのスケールやPodの入れ替えが発生してもパフォーマンスと可用性を維持するのに役立ちます。

関連技術: Kubernetes Service（ClusterIP）、kube-proxy、eBPFベースのネットワーキング、サービスメッシュ、DNSベースのサービスディスカバリー。

外部ロードバランシング

外部ロードバランシングは、ユーザー、アプリケーション、外部システムからクラスターに入ってくるトラフィックを管理します。パブリックなエントリーポイントを提供し、受信リクエストを正常なバックエンドサービス間に分散します。これにより、障害、メンテナンス、スケーリング操作の最中でも可用性を維持しながら、より大量のトラフィックを処理できます。

関連技術: LoadBalancer Service、レイヤー4ロードバランサー、Ingress、Gateway API、TLS終端。

ノースサウス（North-South）トラフィック管理

ノースサウストラフィック管理は、外部クライアントとクラスター内で稼働するワークロードの間を流れるトラフィックを扱います。一般公開されるアプリケーション、API、パートナー連携で一般的に使用されます。ロードバランシングに加えて、外部リクエストが内部サービスにアクセスする方法を制御するために、ルーティング、セキュリティの適用、トラフィックのフィルタリング、暗号化を含むことが多くあります。

関連技術: Ingress、Gateway API、レイヤー7ルーティング、TLS終端、認証・認可ポリシー、Webアプリケーションファイアウォール連携。

イーストウエスト（East-West）トラフィック管理

イーストウエストトラフィック管理は、クラスター内、または接続された複数のKubernetes環境間でのサービス間通信に焦点を当てます。マイクロサービスアーキテクチャではアプリケーションが内部で頻繁にリクエストをやり取りするため、効率的なトラフィック分散はパフォーマンスと信頼性にとって極めて重要です。この種のロードバランシングは、サービス間の可観測性、セキュリティポリシー、トラフィック制御もサポートします。

関連技術: Kubernetes Service、kube-proxy、サービスメッシュ、eBPFベースのネットワーキング、mTLS、トラフィックポリシー、サービスディスカバリー。

マルチクラスターおよびグローバルロードバランシング

マルチクラスターおよびグローバルロードバランシングは、異なるリージョン、アベイラビリティゾーン、クラウドプロバイダー、データセンターに配置された複数のKubernetesクラスター間でトラフィックを分散します。単一のクラスターが障害点になることを防いでレジリエンスを高め、ユーザーを最適なロケーションに誘導することでレイテンシーを低減できます。ディザスタリカバリー、グローバルアプリケーション、大規模デプロイメントで一般的に使用されます。

関連技術: Gateway API、グローバルロードバランシング、DNSベースのトラフィックルーティング、マルチクラスターネットワーキング、サービスメッシュ、トラフィックフェイルオーバー、ジオルーティング。

Kubernetesロードバランシングの実装例

本セクションの例はKubernetesドキュメントを基にしています。

Kubernetes Serviceの例

以下のDeploymentは、NGINXアプリケーションのレプリカを3つ作成します。各Podには app: nginx というラベルが付けられており、Kubernetes ServiceがこれらのPodを選択してトラフィックを送信できるようになります。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 10

このDeploymentは3つのNGINX Podを稼働状態に保ちます。Podが削除されたり障害が発生したりすると、DeploymentのReplicaSetが代わりのPodを作成します。Readiness Probeは、各PodがServiceを通じてトラフィックを受け取る準備ができたタイミングをKubernetesが判断するのに役立ちます。

ClusterIP Serviceの例

以下のClusterIP Serviceは、NGINX Deploymentをクラスター内部に公開します。このServiceは app: nginx ラベルを持つPodを選択し、Serviceのポート80から選択されたPodのポート80にトラフィックを転送します。

apiVersion: v1
kind: Service
metadata:
  name: nginx-clusterip
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

このServiceにはクラスター内部から到達できます。クラスターDNSが利用可能であれば、他のPodはService名 nginx-clusterip を使って接続できます。

LoadBalancer Serviceの例

以下のServiceは、外部ロードバランサーをサポートするクラウドプロバイダーなどの環境で、同じNGINX Podを外部に公開します。

apiVersion: v1
kind: Service
metadata:
  name: nginx-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

対応環境でこのServiceを作成すると、Kubernetesは外部ロードバランサーをプロビジョニングまたは構成し、外部アドレスをServiceのステータスに記録します。外部アドレスに送信されたトラフィックはServiceに転送され、その後、条件に合致するバックエンドPodに送られます。

Ingressの例

以下のIngressは、example.com 宛てのHTTPトラフィックを内部の nginx-clusterip Serviceにルーティングします。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nginx-clusterip
                port:
                  number: 80

このIngressはHTTPルーティングルールを定義しますが、機能するにはクラスター内でIngressコントローラーが稼働している必要があります。Ingressコントローラーがルーティングの動作を実装し、条件に合致するリクエストをバックエンドServiceに転送します。

API Gatewayの例

以下の例では、Kubernetes Gateway APIを使用して、Gatewayを経由するHTTPトラフィックを内部の nginx-clusterip Serviceにルーティングします。Gateway APIは、動的なインフラプロビジョニングと高度なトラフィックルーティングのためのKubernetesネットワーキングAPIファミリーであり、HTTPRouteリソースはHTTPリクエストをマッチさせてKubernetes Serviceに転送できます。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: nginx-gateway
spec:
  gatewayClassName: nginx
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      hostname: api.example.com
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: nginx-api-route
spec:
  parentRefs:
    - name: nginx-gateway
  hostnames:
    - api.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: nginx-clusterip
          port: 80

この例では、Gateway がAPIゲートウェイのエントリーポイントを表し、HTTPRoute がHTTPリクエストのルーティング方法を定義します。api.example.com/api に送信されたリクエストはGatewayリスナーで受け付けられ、ルートにマッチし、nginx-clusterip Serviceに転送されます。Serviceはその後、条件に合致するNGINX Pod間にトラフィックを分散します。

注: この例ではゲートウェイクラスの実装としてNGINX Gateway Fabricを使用しています。これはコミュニティによってメンテナンスされているIngress NGINXコントローラーとは別のものです。

このアプローチはIngressに似ていますが、Gateway APIはより表現力が高く、ロール指向のモデルを提供します。インフラチームがGatewayリソースを管理し、アプリケーションチームが HTTPRoute などのルートリソースを管理できます。ホスト名ベースのルーティング、パスベースのルーティング、トラフィックポリシー制御、そしてプラットフォーム構成とアプリケーションルーティングの明確な分離を必要とするAPIゲートウェイパターンにおいて有用です。