【Nginx応用講座 第8回】Kubernetes Ingress Controller入門。クラウドネイティブ時代のNginx運用

サーバー管理からの卒業。「クラスタ」を支配する門番になれ。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
全8回にわたるNginx応用講座、ついに最終回です。

これまでは、「サーバーにSSHでログインして、confファイルを書き換えて、reloadする」という運用をしてきました。
しかし、サーバーが100台、1000台になったらどうしますか？
手作業での管理は限界を迎えます。

そこで登場するのが、Googleが開発したコンテナオーケストレーションシステム「Kubernetes（K8s）」です。
K8sの世界では、Nginxはもはや手作業で設定するものではありません。
コード（YAML）で定義し、自動的にデプロイされ、勝手にスケールする「Ingress Controller」として振る舞います。

本記事では、Kubernetes環境におけるNginx Ingress Controllerの役割、Helmを使ったインストール、YAMLファイルによるルーティング定義、そしてAnnotations（アノテーション）を使った高度な設定変更までを解説します。

---

第1章：なぜK8sにNginxが必要なのか？ (Service vs Ingress)

Kubernetesには、コンテナへのアクセスを管理するリソースとして Service (Type: LoadBalancer) があります。
しかし、これだけでは不十分なのです。

LoadBalancerの限界

• コストが高い: サービスごとにクラウドのロードバランサー（AWS CLB/ALBなど）が作成され、課金される。
• L7機能が弱い: 細かいパスベースルーティングやリライト設定などが難しい（またはベンダー依存になる）。

Ingressの登場

そこで登場するのが Ingress です。
Ingressは「ルール（定義）」であり、それを実際に処理するのが Ingress Controller（実体はNginxなど）です。

メリット:

1. IPアドレスの節約: 1つのロードバランサー（入り口）で、複数のサービスへ振り分けられる（バーチャルホスト機能）。
2. 高度な機能: Nginxの強力な機能（Basic認証、レートリミット、Luaスクリプトなど）がそのまま使える。
3. 環境非依存: AWSでもオンプレミスでも、同じNginxの設定（YAML）で動作する。

---

第2章：「2つのNginx Ingress」問題。どっちを使うべき？

実は、”Nginx Ingress Controller” と呼ばれるものには、大きく分けて2種類あります。
ここを間違えると、設定が全く動かないので注意が必要です。

種類	開発元	Dockerイメージ名	特徴
Community版	Kubernetesコミュニティ	registry.k8s.io/ingress-nginx/controller	デファクトスタンダード。機能豊富で情報が多い。通常はこちらを使う。
Nginx Inc版	F5 Nginx (公式)	nginx/nginx-ingress	Nginx社が開発。軽量で高速だが、設定の書き方（Annotations）が異なる。

---

第3章：Helmを使った爆速インストール

K8sへのインストールは、マニフェストファイルを一つ一つ適用するのではなく、パッケージマネージャーである Helm を使うのが現代の常識です。

手順1：Helmリポジトリの追加

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

手順2：インストール

ingress-nginx という名前空間（Namespace）を作ってインストールします。

helm install my-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx --create-namespace

手順3：確認

kubectl get pods -n ingress-nginx

my-nginx-ingress-nginx-controller-xxxxx というPodが Running になっていれば成功です。
また、kubectl get svc -n ingress-nginx で EXTERNAL-IP が割り当てられていることを確認してください（クラウドの場合）。

---

第4章：Ingressリソースの書き方（ルーティング定義）

いよいよNginxの設定です。
しかし、nginx.conf を直接編集することはありません。
代わりに Ingressリソース（YAMLファイル） を作成し、K8sに適用します。
すると、Ingress Controllerがそれを検知し、自動的に内部の nginx.conf を書き換えてリロードしてくれます（魔法のようです！）。

基本的な設定例 (ingress.yaml)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    # ここにNginx特有の設定を書く（後述）
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

解説:

• host: myapp.example.com: バーチャルホストの設定（server_name）。
• path: /api: パスベースルーティング（location /api）。
• backend: 転送先のService（proxy_pass）。

これを kubectl apply -f ingress.yaml で適用するだけで、ルーティングが完了します。

---

第5章：アノテーションの魔術（confを書かずに設定する）

「client_max_body_sizeを増やしたい」「Basic認証をかけたい」「CORSを許可したい」。
これらの細かい設定は、YAMLの metadata.annotations に記述します。
これこそがNginx Ingress Controllerの真骨頂です。

よく使うアノテーション集

1. アップロードサイズ制限の緩和

nginx.ingress.kubernetes.io/proxy-body-size: "50m"

2. Basic認証の適用

nginx.ingress.kubernetes.io/auth-type: basic
nginx.ingress.kubernetes.io/auth-secret: my-auth-secret
nginx.ingress.kubernetes.io/auth-realm: "Authentication Required"

3. レートリミット（DDoS対策）

nginx.ingress.kubernetes.io/limit-rps: "5"

4. スティッキーセッション（Cookie維持）

nginx.ingress.kubernetes.io/affinity: "cookie"

このように、nginx.conf で数行書いていた設定が、1行のアノテーションで完結します。
使用可能なアノテーションの一覧は公式ドキュメントに膨大にあります。

---

第6章：高度な運用（カナリアリリースとLet’s Encrypt）

K8sを使う最大のメリットの一つが、高度なデプロイ戦略です。

カナリアリリース（Canary Release）

「新バージョンのアプリを、全ユーザーの10%だけに公開して様子を見たい」。
これをNginx Ingressでは簡単に実現できます。

既存のIngressとは別に、もう一つIngress（Canary用）を作成します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: canary-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10" # 10%のトラフィックを流す
spec:
  ingressClassName: nginx
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: new-version-service # 新しいアプリ
            port:
              number: 80

これだけで、Nginxが自動的にリクエストの10%を新サービスへ振り分けます。
Luaスクリプトを書く必要すらありません。

Cert-managerによるSSL自動化

Let’s Encryptの証明書取得・更新も完全自動化できます。
cert-manager を導入し、Ingressに以下のアノテーションを付けるだけです。

annotations:
  cert-manager.io/cluster-issuer: "letsencrypt-prod"

これで証明書の期限切れに怯える日々とはおさらばです。

---

第7章：トラブルシューティングとログ解析

「設定したのに繋がらない！」
そんな時は、K8sならではのデバッグ方法があります。

1. Nginxの設定ファイルの中身を確認する

Ingress ControllerのPodの中に入り、生成された nginx.conf を直接見ます。

# Pod名を確認
kubectl get pods -n ingress-nginx

# コマンド実行（cat nginx.conf）
kubectl exec -it -n ingress-nginx [POD名] -- cat /etc/nginx/nginx.conf

アノテーションの設定が正しく反映されているか、grepして確認しましょう。

2. コントローラーのログを見る

設定ミスがある場合、コントローラーがリロードに失敗している可能性があります。

kubectl logs -n ingress-nginx [POD名]

ここに “invalid number of arguments” などのNginxエラーが出ていないかチェックします。

3. アクセスログをtailする

リクエストが来ているかリアルタイムで確認します。

kubectl logs -n ingress-nginx [POD名] -f

---

講座総まとめ：インフラエンジニアの未来

全8回の応用講座、本当にお疲れ様でした！
これまでの学びを振り返りましょう。

1. 第1回: 負荷分散とキャッシュで、大量アクセスをさばく基礎を作りました。
2. 第2回: WAFでアプリケーションを守る盾を手に入れました。
3. 第3回: gRPCやWebSocketなど、モダンなプロトコルを統合しました。
4. 第4回: Luaを使って、Nginxに知能（ロジック）を与えました。
5. 第5回: Keepalivedで、絶対に止まらない可用性を確保しました。
6. 第6回: Prometheus/Grafanaで、見えない不調を可視化しました。
7. 第7回: カスタムビルドで、自分だけの最強バイナリを錬成しました。
8. 第8回: そして今回、Kubernetesでクラウドネイティブな運用へと昇華させました。

Nginxは、19年前の登場以来、Web技術の進化と共に成長し続けてきました。
そして今、クラウドネイティブの時代においても、その重要性は減るどころか増しています。
「Nginxを制する者は、Webインフラを制す」。この言葉は決して大袈裟ではありません。

あなたがこの講座で得た知識は、オンプレミス、クラウド、コンテナ、どんな環境でも通用する「普遍的な武器」です。
自信を持って、現場の課題に立ち向かってください。

これからのエンジニアライフが、よりエキサイティングで実りあるものになることを願っています。
Good Luck, and Happy Hacking!