IngressとNodePortの違いを徹底解説｜Kubernetes公開経路をやさしく比較

---

はじめに：IngressとNodePortの違いをわかりやすく整理する

クラウドやコンテナの世界でアプリを「外部に見える形」で公開する方法にはいくつかの道があります。特に Kubernetes を使うときには「Ingress」と「NodePort」という用語をよく耳にします。この2つは“公開の入口”を作る仕組みですが、役割や使い方がぜんぜんちがいます。本記事では中学生にも分かるよう、丁寧な例と図の代わりになる説明で、IngressとNodePortの違いと、それぞれが適している場面を整理します。まずはそれぞれの基本を整理し、次に実践的な使い分けの判断基準を示します。具体的な設定の手順は触れず、まずは全体像を頭に入れてから詳しい手順へ進むのがおすすめです。IngressとNodePortはどちらも「外部から内側のサービスへ道を作る」点は同じですが、外部の見せ方や管理の複雑さ、 TLS の扱い、そしてスケールの観点で大きく異なります。よくある誤解は「どちらか一方を使えば良い」という発想ですが、それぞれ長所と短所があり、状況に合わせて選ぶことが大切です。

この章を読めば、まずは「公開経路の基本の地図」が頭に入り、以降の章で実務の判断基準をすぐ使えるようになります。

基本の違いを掴む：Ingressとは何か、NodePortとは何か

IngressはHTTP/HTTPSのルーティングに向いた高度な入口で、外部からのリクエストは Ingress Controller によって受け取り、URL パスやホスト名に応じてバックエンドのサービスへ振り分けます。これにより、1つの公開エンドポイント（例: example.com）で複数のサービスを分岐させることが可能です。Ingress を使うには「Ingressリソース」と「Ingress Controller」が必要です。Ingress Controller はクラスタ内に配置され、外部からのトラフィックを受け取る役割と、証明書の TLS 終端処理を行うことが多いです。設定の基本は、ルール（ホスト名・パス）とバックエンドのサービスを結びつけることです。準備としては、クラウド環境であれば AWS の ALB Ingress Controller などが有名で、オンプレミス寄りの構成では Nginx Ingress Controller がよく使われます。エンドポイントは通常 single IP の公開URLを用意しますが、実際にはクラスタ外部のロードバランサやクラウドのエントリポイントと組み合わせて運用します。
一方、NodePortはクラスタの各ノードにポートを開いて外部からの接続を受ける、比較的単純な公開方法です。NodePort を使うと、外部からは nodeIP:nodePort という形で直接アクセス可能です。Kubernetesの Service で Type: NodePort を設定すると、Kubernetes は自動的に各ノードの決まった範囲（デフォルトは 30000–32767 のポート）にポートを割り当て、バックエンドの Pod へトラフィックを転送します。ここでの重要なポイントは「単に外部と内部を結ぶ道を作る」という点で、ルーティングの柔軟性は低め、TLS終端や複雑なURLルーティングは自前のロードバランサやプロキシを別途用意する必要があるという点です。加えて NodePort はセキュリティ面での配慮も必要で、直接ポートを公開することが攻撃窓を広げるリスクがあります。これらの特徴が、どちらを選ぶべきかを判断する大切な材料になります。

Ingressのしくみと使い方

IngressはURLベースのルーティングを central に管理する“入口管理者”です。複数のバックエンドサービスを、1つの外部公開エンドポイントで振り分けます。ここで重要なのは「Ingressリソースで定義するルール」と「Ingress Controller が実際のトラフィックを配布する」という分業です。Ingressリソースには host 名や path の指定、どのサービスへ繋ぐかを記述します。たとえば /api へのリクエストを backend-api というサービスへ、 /shop へのリクエストを backend-shop へ、というように分岐を設定します。TLS を利用する場合は、Ingress Controller が TLS 終端を担い、内部は HTTP でバックエンドへ転送する設定を行います。これにより外部のクライアントは、例として https://example.com の1つのエンドポイントだけを意識すればよくなり、複数のサービスを単一の入口で管理できます。Ingressを適切に使うと、運用のスケール性が向上し、証明書管理も簡潔になります。一方で、Ingress Controller の選択や設定が難しくなるため、初学者には少しハードルが高い側面もあります。
また、Ingressには負荷分散機能が組み込まれている場合が多く、バックエンドのポッドが増えてもルーティングのルールを変えずに済む点が大きなメリットです。

NodePortのしくみと限界

NodePortは、クラスタ内のすべてのノードに同じポート番号を開き、外部からそのノードの IP アドレスとポート番号で直接アクセスできるようにする公開方法です。便利な点は設定が比較的シンプルで、外部に公開する最小の構成をすぐに作れることです。ただし制約も多く、ポート範囲が限られている点、負荷分散機能がIngressほど強力でない点、TLS終端を自前で別機構に任せる必要がある点などが挙げられます。大規模な外部トラフィックや複雑なルーティングを行う場合には、NodePort だけでは対応しきれないことが多いです。実務では、NodePort を土台にして外部ロードバランサを介してリクエストをコントロールしたり、開発環境でのテストとして使うケースが多く見られます。NodePort の強みを活かすには、シンプルな公開が最優先で、複雑なルーティングが不要なケースに限定するのが現実的です。
これらを踏まえると、Ingress は「大規模で柔軟な公開」を目指す場面、NodePort は「小規模で直感的な公開」を目指す場面に向いていると整理できます。

現場での使い分けガイド

現場で最初に意識するべきは、公開したい経路が「URL/ホスト名ベースの分岐」を必要とするかどうかです。もし yes なら Ingress の導入を検討します。複数のマイクロサービスを1つのエンドポイントで扱いたい場合も Ingress が有利です。逆に、テスト環境程度の公開で、設定を極力シンプルに保ちたい場合や、狭い範囲の通信だけを公開したい場合は NodePort から始めても良いでしょう。実務では、Ingress を採用してTLS終端を統一し、バックエンドは複数のサービスへと柔軟に振り分ける構成が一般的です。運用を安定させるコツは、インフラの現状と要件を整理した上で、段階的に導入を進めることです。最初は小さなルールから始め、徐々に複雑なルールへ拡張していくと失敗が減ります。

比較表

able> 観点 Ingress NodePort 公開経路 URLベースのルーティング、1つのエンドポイントで複数サービスを振り分け ノードのIPとポートへ直接接続。単純な公開 TLS/終端 Ingress Controller が TLS終端を担当することが多い TLS終端は別の機構で実装することが多い スケーリング/管理 多数のバックエンドを統合して管理しやすい 単純で小規模向き、拡張性は低め 設定の複雑さ 設定は複雑になる場合がある 設定が比較的簡単 ble>

まとめと実践のコツ

IngressとNodePortは、目的と状況に応じて使い分けるのが大切です。大規模な公開や複雑なルーティングが必要ならIngress、直感的な公開や小規模・開発環境ならNodePortを選ぶのが基本的な考え方です。この記事で挙げたポイントを押さえれば、初めての Kubernetes 環境でも適切な公開経路を選択できるようになります。今後は自分のクラスの環境やプロジェクトの要件に合わせて、Ingress Controller の種類を比較したり、TLS証明書の管理方法を整えたりすることをおすすめします。
そして、実際の運用では以下の順序で検討すると良いです：1) 何を公開したいのかを明確にする、2) シンプルさを優先する場合は NodePort から始める、3) 将来的に複雑なルーティングが必要そうなら Ingress に移行する、4) TLSを統一してセキュリティを確保する、5) 監視とロギングを整えて運用を安定させる。

ピックアップ解説

konetaは友だちと放課後に学校の情報教室でIngressとNodePortの違いを深掘りした話です。Ingressは、まるで学校の受付のようにURLやホスト名で来訪者を適切な教室へ案内する役割を持つとたとえ話をしました。受け付けには“誰が来たか”と“どの教室へ行くのか”を判断するルールが必要で、それをIngressリソースとして設定します。対してNodePortは、教室の窓口のように、特定のノードのポートを開放して直接アクセスを受ける仕組み。直感的で分かりやすいが、混雑時の振り分けやTLSの処理を自分たちで工夫する必要がある、という話が印象的でした。結局、現場では大勢の学生が使う大規模な公開にはIngress、手早く公開したい場面にはNodePort、という結論で話がまとまりました。まさに現場の“使い分けのコツ”を体感した瞬間でした。

---