DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

適切なKubernetesサービスタイプの選択：ClusterIP、NodePort、LoadBalancerの比較

ClusterIP、NodePort、LoadBalancerを比較し、適切なServiceタイプでKubernetesアプリを公開する方法を解説します。

適切なKubernetes Serviceタイプの選択: ClusterIP vs NodePort vs LoadBalancer

適切なKubernetes Serviceタイプを選ぶことで、誰がアプリにアクセスできるか、トラフィックがどのように到達するかが決まります。間違ったタイプを選ぶと、アプリに到達できなくなったり、過剰に公開されたり、不要なクラウドリソースが発生する可能性があります。

このガイドでは、3つの基本的なKubernetes Serviceタイプ（ClusterIP、NodePort、LoadBalancer）を包括的に比較します。各タイプのユースケース、実装メカニズム、関連するトレードオフを理解することで、アプリケーションのネットワーク要件に完全に合致した情報に基づいた意思決定が可能になり、内部通信と外部アクセシビリティの両方を効果的に管理できます。

Kubernetes Serviceの理解

具体的なタイプに入る前に、Kubernetes Serviceの役割を理解することが重要です。Podは一時的な存在であり、作成、破棄、再スケジュールに応じてIPアドレスが変わります。Serviceは、動的に変化するPodのセットに対して安定したエンドポイント（固定IPアドレスとDNS名）を提供し、クラスター内での信頼性の高い通信を可能にします。

ServiceはServiceオブジェクトマニフェストを使用して定義され、通常は関連するPodを見つけるためのselectorと、Serviceの公開方法を定義するtypeを指定します。

ClusterIP: 内部通信

ClusterIP はデフォルトで最も基本的なServiceタイプです。クラスター内の内部IPアドレスでServiceを公開します。このServiceは、クラスター内からのみアクセス可能です。

ClusterIPのユースケース

  • バックエンドサービス: 同じKubernetesクラスター内で動作する他のサービスやフロントエンドアプリケーションとのみ通信する必要があるデータベース、内部API、キャッシュレイヤー、マイクロサービスに最適です。
  • 内部ディスカバリ: Kubernetesの内部DNSを活用して、安定したサービスディスカバリ名（例: my-database.namespace.svc.cluster.local）を提供します。

実装の詳細

ClusterIPサービスが作成されると、Kubernetesはクラスターネットワークファブリック内部でのみルーティング可能な仮想IPアドレスを割り当てます。外部トラフィックはこのIPに直接到達できません。

マニフェスト例 (ClusterIP):

apiVersion: v1
kind: Service
metadata:
  name: internal-api
spec:
  selector:
    app: backend-service
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

ヒント: すべてのコンポーネントがクラスター内に存在する分散システムのみを構築している場合、ClusterIPは不要な外部公開を避けるため、最も安全で効率的な選択肢です。

NodePort: クラスターノードを介したサービスの公開

NodePort はServiceを外部に公開する最も簡単な方法です。クラスター内のすべてのノード（VMまたは物理マシン）に特定のポートを開き、そのポートに到着した外部トラフィックをServiceにルーティングします。

NodePortのユースケース

  • 開発とテスト: フルクラウドロードバランサーのセットアップが過剰な場合に、開発中に外部からアクセス可能なサービスを迅速にテストするのに便利です。
  • 非クラウド環境: ネイティブなクラウドロードバランシング統合が利用できないベアメタルやオンプレミスのKubernetesインストールで不可欠です。

実装の詳細

NodePortサービスが作成されると、Kubernetesは設定された範囲（デフォルトは30000～32767）内の静的ポートをすべてのノードに選択します。Serviceは以下の方法でアプリケーションを公開します:

http://<NodeIP>:<NodePort>

IPが10.0.0.1、10.0.0.2、10.0.0.3の3つのノードがあり、NodePortが30080の場合、ポート30080でこれらのIPのいずれかを介してサービスにアクセスできます。

マニフェスト例 (NodePort):

apiVersion: v1
kind: Service
metadata:
  name: test-web-app
spec:
  selector:
    app: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
      nodePort: 30080 # オプション: 外部ポートを指定するか、Kubernetesが選択
  type: NodePort

警告: サービスはすべてのノードで公開されるため、外部ルーティングレイヤーは依然として異常なノードを回避する必要があります。デフォルトのNodePort範囲は30000-32767ですが、クラスター管理者は別の範囲を設定できます。

LoadBalancer: クラウドネイティブな外部公開

LoadBalancer は、クラスターにプロビジョニング可能な統合機能がある場合に、外部ロードバランサーを介してServiceを公開します。これはマネージドクラウドKubernetesプラットフォームで一般的です。多くの本番環境では、アプリごとに1つのロードバランサーを作成する代わりに、複数の内部Serviceの前にIngressやGatewayを配置することもあります。

LoadBalancerのユースケース

  • 本番環境デプロイ: クラウドプロバイダーのインフラストラクチャとシームレスに統合する、堅牢で高可用性の外部アクセスを提供します。
  • 自動IP管理: 個々のノードIPを把握したり、ポートの競合を管理する必要がなくなります。

実装の詳細

サポートされている環境でタイプLoadBalancerのServiceが作成されると、クラウドコントローラーマネージャーまたはロードバランサーコントローラーが外部ロードバランサーをプロビジョニングし、Serviceにトラフィックをルーティングするように設定します。

外部アドレスはプロバイダーによって割り当てられます。Serviceの存続期間中は安定している可能性がありますが、プロバイダー固有の設定で構成しない限り、常に予約済みの静的IPであるとは限りません。

マニフェスト例 (LoadBalancer):

apiVersion: v1
kind: Service
metadata:
  name: public-web-service
spec:
  selector:
    app: public-facing
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

これが作成されると、出力（kubectl get svcを使用）に割り当てられた外部IPが表示されます:

NAME                  TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
public-web-service    LoadBalancer   10.96.45.11   34.120.200.55    80:30021/TCP   1m

アプリケーションはhttp://34.120.200.55でアクセス可能になります。

ベストプラクティス: HTTPSには、プラットフォームが最も適切にサポートするパターン（クラウドロードバランサーのアノテーション、Ingressコントローラー、Kubernetes Gateway API）を使用してください。TLS設定をすべてのPodに分散させるのではなく、適切に管理された1つのレイヤーにまとめてください。

比較表の概要

機能 ClusterIP NodePort LoadBalancer
主な用途 内部サービス通信 シンプルな外部アクセス（テスト/ベアメタル） 本番環境、クラウドネイティブな外部アクセス
到達可能性 クラスター内のみ 静的ポート（30000-32767）上のすべてのノード クラウドプロバイダーが管理する外部IP
IPの安定性 安定した内部IP 安定したノードIPだが、ポートを知る必要がある 安定しているが、静的IPには追加設定が必要な場合がある
クラウド依存性 なし なし ロードバランサーの統合が必要
コスト 外部ロードバランサーなし ノードリソースを使用 通常、外部ロードバランサーリソースとして課金
設定の複雑さ 最も低い 低い 中程度（クラウド設定が必要）

まとめ

適切なServiceタイプの選択は、Kubernetesネットワーキングの基本的なステップです:

  1. 内部から開始（ClusterIP）: サービスがクラスター外からアクセスされる必要がまったくない場合は、常にClusterIPを使用してください。これにより、攻撃対象領域とオーバーヘッドが最小限に抑えられます。
  2. テスト/ベアメタル（NodePort）: 基本的な外部テストが必要な場合、または主要なクラウド環境外でKubernetesを実行している場合は、NodePortが即時的ではあるものの、堅牢性に劣る外部アクセスを提供します。
  3. 本番環境クラウド（LoadBalancer）: AWS、GCP、Azureでホストされている本番アプリケーションで、耐久性があり安定した専用の外部エントリポイントが必要な場合は、LoadBalancerが適切な選択肢であり、クラウドインフラストラクチャを活用して回復力を実現します。

Serviceタイプを必要なアクセシビリティとデプロイ環境に合わせることで、コンテナオーケストレーションアーキテクチャ内で最適なパフォーマンス、セキュリティ、統合を確保できます。