1. Kubernetes Ingressで外部公開を実現する全体像と最短設定パス
    1. Ingressの役割とクラスター外部公開の基本
    2. なぜNginx Ingress Controllerが推奨されるのか
    3. 最短でIngressを導入するための準備と考慮事項
  2. Kubernetes Ingressコントローラー導入とリソース定義のステップ
    1. Nginx Ingress Controllerのデプロイ手順
    2. Ingressリソースの基本的な記述方法
    3. サービスの公開とアクセス確認のポイント
  3. Nginx Ingress Controllerを活用した外部公開とTLS設定の実践例
    1. TLS証明書の導入とHTTPS通信の有効化
    2. バーチャルホストとパスベースルーティングの設定例
    3. リダイレクトやアノテーションによる詳細設定
  4. セキュリティと運用効率を高めるための注意点とトラブルシューティング
    1. Ingress ControllerのEOLと代替ソリューションへの移行計画
    2. 運用のベストプラクティスとセキュリティ対策
    3. トラブルシューティングの一般的なアプローチ
  5. 【ケース】証明書エラーで外部公開に失敗、原因特定と適切な設定への改善
    1. 架空のケーススタディ：証明書エラーの発生状況
    2. エラー原因の特定とトラブルシューティングプロセス
    3. 適切な設定への改善と再公開
  6. まとめ
  7. よくある質問
    1. Q: IngressとLoadBalancerの違いは何ですか？
    2. Q: Nginx Ingress Controllerの選び方は？
    3. Q: IngressのTLS設定で注意すべき点は何ですか？
    4. Q: `fake certificate`はいつ利用すべきですか？
    5. Q: Ingress Classとはどのような機能ですか？

Kubernetes Ingressで外部公開を実現する全体像と最短設定パス

Ingressの役割とクラスター外部公開の基本

KubernetesにおけるIngressは、クラスター内部で稼働するアプリケーション（サービス）を外部に安全かつ効率的に公開するためのAPIオブジェクトです。具体的には、HTTP/HTTPSリクエストをクラスター内の適切なサービスにルーティングする役割を担います。NodePortやLoadBalancerといった既存の公開方法と比較して、Ingressは単一の外部IPアドレスとロードバランサーを通じて、複数のサービスをホスト名やパスに基づいて公開できるため、IPアドレスの節約や管理の簡素化が図れます。例えば、example.com/app1とexample.com/app2を別々のサービスに振り分けることが可能です。これにより、運用コストを抑えつつ、柔軟な外部公開を実現します。

なぜNginx Ingress Controllerが推奨されるのか

数あるIngressコントローラーの中でも、Nginx Ingress Controllerは業界で広く採用されており、そのシェアは2025年11月時点で約40%に達すると推計されています（出典：F5）。この高い採用実績は、その安定性、高性能、そして豊富な機能によるものです。Nginx Ingress Controllerは、リバースプロキシとして広く使われているNginxを基盤としているため、高性能なルーティングやロードバランシング機能を提供します。また、TLS（SSL）終端をIngressコントローラー側で行うことで、バックエンドのアプリケーションにかかる負荷を軽減し、セキュリティを一元的に管理できる点も大きなメリットです。ただし、長年標準とされてきた「kubernetes/ingress-nginx」プロジェクトのメンテナンスが2026年3月に終了するため、今後の新規構築や移行では代替ソリューションの検討が必須となります。

最短でIngressを導入するための準備と考慮事項

Ingressを最短で導入するためには、まず稼働中のKubernetesクラスターが必要です。次に、選択したIngressコントローラー（ここではNginx Ingress Controller）をクラスター内にデプロイします。一般的にはHelmなどのパッケージマネージャーを利用することで、比較的容易にデプロイ可能です。デプロイ後には、外部からのトラフィックを受け付けるためのロードバランサー（クラウドプロバイダーのLBサービスなど）が自動的にプロビジョニングされ、外部IPアドレスが割り当てられます。この外部IPアドレスに対して、公開したいドメイン名をDNSでAレコードとして設定する必要があります。初回の設定では、PodやServiceの起動状況、Ingressリソースの記述ミス、DNS設定の不備などが原因で接続に失敗することが多いため、各コンポーネントのステータス確認を確実に行うことが重要です。

Kubernetes Ingressコントローラー導入とリソース定義のステップ

Nginx Ingress Controllerのデプロイ手順

Nginx Ingress ControllerをKubernetesクラスターにデプロイする最も一般的な方法は、Helmチャートを利用することです。まず、Nginx Ingress ControllerのHelmリポジトリを追加し、その後`helm install`コマンドを実行します。この際、クラウド環境で利用する場合は、Serviceの種類をLoadBalancerに設定することで、クラウドプロバイダーが自動的に外部ロードバランサーをプロビジョニングし、外部IPアドレスを割り当ててくれます。デプロイ後には、`kubectl get pods -n `でコントローラーのPodが稼働しているか、`kubectl get svc -n `でingress-nginx-controllerサービスに外部IPアドレスが割り当てられているかを確認します。これにより、外部からのトラフィックを受け入れる準備が整います。

Ingressリソースの基本的な記述方法

Ingressコントローラーがデプロイされたら、次にIngressリソースを定義してアプリケーションを公開します。IngressリソースはYAML形式で記述され、`apiVersion`, `kind`, `metadata`, `spec`の主要なフィールドで構成されます。`spec`セクションには、ルーティングルールを定義する`rules`と、TLS設定を行う`tls`が含まれます。`rules`の中では、トラフィックを受け付ける`host`名、ルーティングパスを定義する`http.paths`、そしてそのパスにマッチしたトラフィックを転送するバックエンドサービスとポートを指定します。例えば、`example.com`へのリクエストをmy-app-serviceというサービスに転送する場合、ホスト名とパス、サービス名を適切に記述することで、外部公開の準備が整います。

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

サービスの公開とアクセス確認のポイント

IngressリソースをKubernetesクラスターに適用した後、実際に外部からアプリケーションにアクセスできるか確認することが重要です。まず、`kubectl get ingress my-app-ingress`コマンドを実行し、Ingressリソースに外部IPアドレスが割り当てられていることを確認します。このIPアドレスに対して、DNSで事前に設定したドメイン名（例: myapp.example.com）が解決されるようにAレコードを登録してください。DNSの変更が反映された後、ウェブブラウザや`curl`コマンドを使って設定したドメイン名にアクセスし、アプリケーションのページが正しく表示されるかを確認します。もしアクセスできない場合は、Ingressコントローラーのログ、Ingressリソースのイベント、バックエンドサービスのステータスなどを確認し、エラー原因を特定するトラブルシューティングが必要になります。

Nginx Ingress Controllerを活用した外部公開とTLS設定の実践例

TLS証明書の導入とHTTPS通信の有効化

現代のウェブアプリケーションにおいて、HTTPSによる暗号化通信は必須です。Nginx Ingress Controllerでは、TLS証明書を導入することでHTTPS通信を容易に有効化できます。まず、Let’s Encryptなどの認証局から証明書を取得し、それをKubernetesのSecretリソースとして登録します。その後、Ingressリソースの`spec.tls`セクションに、HTTPS通信を有効にするホスト名と、先ほど作成したSecretの名前を指定します。これにより、Nginx Ingress ControllerがTLS終端を行い、外部からのHTTPSリクエストを安全にバックエンドのHTTPサービスに転送します。この仕組みにより、個々のアプリケーションでTLS設定を行う手間を省き、一元的なセキュリティ管理が可能になります。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-secure-ingress
spec:
  tls:
  - hosts:
    - myapp.example.com
    secretName: myapp-tls-secret
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80

バーチャルホストとパスベースルーティングの設定例

Ingressの強力な機能の一つが、バーチャルホストとパスベースルーティングです。これにより、単一のIngressコントローラーと外部IPアドレスで、複数の異なるドメイン名やパスに対するトラフィックを異なるバックエンドサービスにルーティングできます。例えば、app1.example.comをservice-app1に、app2.example.comをservice-app2にルーティングするバーチャルホスト設定や、api.example.com/v1をapi-v1-serviceに、api.example.com/v2をapi-v2-serviceにルーティングするパスベース設定が可能です。Ingressリソースの`rules`セクションに複数の`host`エントリや`path`エントリを追加するだけで、これらの複雑なルーティングルールを簡潔に定義し、柔軟なマイクロサービスアーキテクチャを実現できます。

リダイレクトやアノテーションによる詳細設定

Nginx Ingress Controllerは、Nginxの豊富な機能を利用するためのアノテーションを提供しており、これにより高度な設定が可能です。例えば、HTTPからHTTPSへの強制リダイレクトは、`nginx.ingress.kubernetes.io/force-ssl-redirect: “true”`というアノテーションを追加するだけで簡単に実現できます。他にも、カスタムのNginx設定を適用するためのアノテーションや、リクエストの書き換え（rewrite-target）など、多様なユースケースに対応します。しかし、アノテーションを多用すると、Ingressリソースの設定が複雑になり、可読性やメンテナンス性が低下する可能性があります。将来的なGateway APIへの移行も視野に入れつつ、必要最小限のアノテーション利用を心がけ、設定の標準化と簡潔さを維持することが推奨されます。

セキュリティと運用効率を高めるための注意点とトラブルシューティング

Ingress ControllerのEOLと代替ソリューションへの移行計画

Kubernetes Ingressの運用において最も重要な注意点の一つは、長年標準的に利用されてきた「kubernetes/ingress-nginx」プロジェクトのメンテナンスが2026年3月に終了することです（出典：F5）。これは、セキュリティ修正を含むパッチが提供されなくなることを意味し、継続利用は重大なセキュリティリスクを伴います。そのため、現在「kubernetes/ingress-nginx」を使用している場合は、早期に代替となるF5社の「NGINX Ingress Controller」や、Kubernetesの次世代APIである「Gateway API」への移行計画を立てることが不可欠です。新規構築においては、最初からサポートが継続される代替プロダクトやGateway APIの採用を強く推奨します。

重要
2026年3月のメンテナンス終了を控え、既存の「kubernetes/ingress-nginx」を利用している環境では、早期の代替ソリューションへの移行計画が不可欠です。セキュリティパッチやバグ修正が提供されなくなるため、運用リスクが著しく高まります。新規構築においては、最初からF5 NGINX Ingress ControllerやKubernetes Gateway APIの採用を強く推奨します。

出典：F5（Ingress NGINX廃止発表に伴う代替案）

運用のベストプラクティスとセキュリティ対策

Ingressコントローラーの運用においては、以下のベストプラクティスとセキュリティ対策を講じることが重要です。まず、Ingressコントローラーのバージョンは常に最新の状態に保ち、セキュリティ脆弱性への対策を徹底します。次に、TLS証明書は定期的に更新し、常に有効な状態を維持してください。WAF（Web Application Firewall）との連携や、レートリミット設定を導入することで、DDoS攻撃や不正アクセスからの保護を強化できます。また、Ingressコントローラーのログを詳細に監視し、異常を検知した際には迅速に対応できるようアラートシステムを構築することが望ましいです。RBAC（Role-Based Access Control）を用いて、Ingressリソースに対する操作権限を最小限に制限することも、セキュリティを高める上で有効です。

トラブルシューティングの一般的なアプローチ

Ingressが期待通りに動作しない場合、以下の一般的なアプローチでトラブルシューティングを進めます。

  1. コンポーネントのステータス確認: `kubectl get pods -n `でIngressコントローラーのPodが稼働しているか、`kubectl get svc -n `でServiceに外部IPが割り当てられているか確認します。
  2. Ingressリソースの確認: `kubectl describe ingress `を実行し、イベントやルーティングルール、TLS設定に誤りがないか確認します。
  3. コントローラーのログ確認: `kubectl logs -n `でコントローラーのログを確認し、エラーメッセージがないか探します。特にルーティング設定や証明書ロードに関するエラーに注意してください。
  4. バックエンドサービスの確認: IngressがルーティングしているDeploymentやServiceが正常に稼働しているか、期待するポートでリッスンしているか確認します。
  5. ネットワーク設定の確認: DNS設定が正しいか、クラウドプロバイダーのファイアウォールやセキュリティグループが適切に設定されているかを確認します。

これらのステップを踏むことで、ほとんどのIngress関連の問題の原因を特定し、解決に導くことができるでしょう。

【ケース】証明書エラーで外部公開に失敗、原因特定と適切な設定への改善

架空のケーススタディ：証明書エラーの発生状況

ある日、開発チームが新しいWebアプリケーションをKubernetesクラスターにデプロイし、Nginx Ingress Controllerを使って外部公開を試みました。Ingressリソースを設定し、HTTPSを有効にするためにTLS証明書をSecretとして登録しました。しかし、ブラウザからアプリケーションのURL（例: newapp.example.com）にアクセスすると、「NET::ERR_CERT_COMMON_NAME_INVALID」や「証明書が信頼されていません」といった証明書エラーが表示され、安全な通信が確立できませんでした。HTTPアクセス（例: http://newapp.example.com）では問題なくページが表示されるため、ルーティング自体は機能しているようです。

エラー原因の特定とトラブルシューティングプロセス

この証明書エラーのトラブルシューティングは、以下のステップで進めました。

  1. `kubectl describe ingress newapp-ingress`でIngressリソースの詳細を確認しました。`TLS`セクションに`Hosts`と`SecretName`が正しく記述されていることは確認できました。
  2. 次に、`kubectl get secret newapp-tls-secret -o yaml`でTLS証明書が保存されているSecretの中身を確認しました。ここで、発行された証明書の`Common Name`または`Subject Alternative Names (SANs)`に、Ingressで指定したホスト名(`newapp.example.com`)が含まれていないことが判明しました。具体的には、証明書はワイルドカード(`*.example.com`)で発行されているべきところが、特定のサブドメイン(`oldapp.example.com`)に限定されて発行されていることが分かりました。
  3. さらに、Nginx Ingress ControllerのPodログを確認すると、証明書のロードに関する警告やエラーメッセージが記録されており、特定の証明書とホスト名の不一致が示唆されていました。

原因は、Ingressリソースで指定したホスト名と、Secretに登録されたTLS証明書がカバーするドメイン名が一致していなかったことでした。

チェックリスト：証明書エラー解決のために

  • Ingressリソースの`spec.tls.hosts`と`spec.rules.host`が発行した証明書のドメイン名と完全に一致していますか？ (例: `example.com`と`www.example.com`は別扱い)
  • TLS証明書を含むKubernetes Secretの名前がIngressリソースの`spec.tls.secretName`に正しく指定されていますか？
  • Secretに保存された証明書の有効期限は切れていませんか？
  • cert-managerを使用している場合、Certificateリソースが`Ready`状態になっていますか？
  • Nginx Ingress ControllerのPodログに証明書関連のエラーメッセージが出ていませんか？

適切な設定への改善と再公開

原因が特定されたため、以下の改善策を実施しました。

  1. 証明書の再発行または変更: `newapp.example.com`に対応するTLS証明書を再発行するか、既に持っているワイルドカード証明書(`*.example.com`)を使用するようにSecretの内容を更新しました。今回は、既存のワイルドカード証明書を利用する形に変更しました。
  2. Secretの更新: 更新された証明書情報を含むSecretをKubernetesに再度適用しました。
  3. Ingressリソースの確認: Ingressリソースの`spec.tls.secretName`が正しいSecretを参照しているか、また`hosts`フィールドに`newapp.example.com`が正しく記載されているか最終確認しました。

これらの修正を適用後、再度ブラウザから`https://newapp.example.com`にアクセスすると、無事にHTTPS接続が確立され、アプリケーションが安全に公開されました。このケースから、Ingressリソースのホスト名とTLS証明書の内容が正確に一致していることの重要性が改めて確認できました。