導入：なぜ外部公開手法の選定が重要なのか
Kubernetes環境において、サービスを外部公開する手法は複数存在します。しかし、安易にすべてをLoadBalancerで公開すると、クラウドの利用コストが肥大化したり、管理が複雑化したりするリスクがあります。本記事では、NodePort、LoadBalancer、Ingressの特性を整理し、実務でコストと運用のバランスを最適化するための判断基準を解説します。
基礎知識：各手法の仕組みと役割
NodePort: 全てのノードの特定のポート（デフォルト30000-32767）を解放し、直接トラフィックを受け付ける方式です。
LoadBalancer: クラウドプロバイダー（AWS, GCP, Azure等）のマネージドロードバランサーを自動作成します。IPアドレスが個別に割り当てられるため、サービスごとにLB料金が発生します。
Ingress: L7（アプリケーション層）のルーティング機能です。1つのLBで複数のホスト名やパスを振り分けることができ、SSL終端も一元管理可能です。
実装と解決策
実務では、以下の基準で選定を行うのが一般的です。
1. 開発環境や検証: NodePortで十分。
2. 単一の公開サービス: LoadBalancerを最小構成で使用。
3. 本番環境のWebAPIやマイクロサービス: Ingressを使用してLBの数を集約し、コストを最適化。
サンプルプログラム：Ingressによるルーティング集約
以下は、1つのIngressリソースで2つの異なるサービスをパスで振り分ける定義例です。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
annotations:
# 外部LBがSSL終端を行うための設定例
kubernetes.io/ingress.class: “nginx”
spec:
rules:
- host: example.com
http:
paths:
- path: /api/v1
pathType: Prefix
backend:
service:
name: api-service # API用サービスへルーティング
port:
number: 80
- path: /web
pathType: Prefix
backend:
service:
name: web-service # フロントエンド用サービスへルーティング
port:
number: 80
応用・注意点：現場での落とし穴
コスト最適化の罠: Ingressは便利ですが、Ingress Controller自体がダウンすると全サービスが停止します。冗長化構成（レプリカ設定）を必ず検討してください。
SSL終端の場所: クラウドのLBで終端するか、Ingress Controller（Nginx等）で終端するかで証明書の管理方法が変わります。Cert-managerを利用した自動更新の仕組みを導入することで、運用負荷を大幅に下げることができます。
NodePortの注意点: NodePortはセキュリティグループの設定が広範囲になりがちです。可能であれば、内部公開用としてのみ利用し、外部からの直接アクセスは控えるのが安全です。
コメント