--- title: "Kubernetesネットワーク設計｜Service・Ingress・Pod間通信とCNI選定の実装判断" url: "https://www.issoh.co.jp/tech/details/15292/" published: 2026-07-17 updated: 2026-10-19 categories: ["Kubernetes・コンテナ"] publisher: "株式会社一創" --- # Kubernetesネットワーク設計｜Service・Ingress・Pod間通信とCNI選定の実装判断 Kubernetesのネットワークは、Pod間のフラットな通信、Serviceによる負荷分散、Ingress／Gateway APIでの外部公開、CNIとNetworkPolicyによる経路と制御という複数の層が重なって動きます。本記事が扱うのは、この層をどう設計判断へ落とすかです。「なぜPod同士がIPで直接届くのか」から、ClusterIP・NodePort・LoadBalancerの使い分け、Ingressの凍結とGateway APIへの移行、CNI（Cilium／Calico）の選定基準までを実装者の粒度で整理します。2026年3月に退役するingress-nginxを踏まえた新規クラスタの入口設計と、小規模チームが過剰投資しないための境界も条件付きで示します。 ## まとめ：Kubernetesネットワークは通信レイヤーと入口方式の選定で決まる Kubernetesのネットワーク設計は、内部通信（Pod間・Service）と外部公開（NodePort／LoadBalancer／Ingress・Gateway API）を分けて考えると迷いません。Pod間はCNIが張るフラットネットワークで直接届き、Serviceが可変なPod群に固定の仮想IPとDNS名を与え、外部からのL7ルーティングはIngressまたはGateway APIが束ねます。 2026年時点の判断の勘所は3つです。第一に、外部公開の入口はServiceのLoadBalancerで足りるか、L7ルーティングが要るならIngressか、新規ならGateway APIかを先に決めること。第二に、ingress-nginxコントローラは2026年3月でメンテナンスが止まるため、新規クラスタはGateway API対応コントローラかクラウドマネージドの入口を第一候補にすること。第三に、CNIは標準機能で足りる場面と、eBPFの可観測性やNetworkPolicyの細粒度制御が要る場面を分け、後者でCiliumやCalicoを選ぶことです。マネージドKubernetesの構築やネットワーク設計の相談は[AWS・Google Cloud・Azureのインフラ構築](https://www.issoh.co.jp/service/system/aws/)で対応しています。 ## Kubernetesネットワークを構成する4つの通信レイヤーとCNIの役割 Kubernetesのネットワークは単一の仕組みではなく、通信の向きごとに役割の異なる層が積み重なる構造です。まずこの層構造を分解すると、どこにServiceを置き、どこにIngressを置くかが定まります。基礎となるKubernetes自体の仕組みは[Kubernetes（K8s）とはの解説](https://www.issoh.co.jp/tech/details/2928/)に譲り、ここではネットワーク面に絞ります。 ### Pod間通信を成立させるフラットなネットワークモデルの前提と要件 Kubernetesは「すべてのPodがNATなしで互いのIPに到達できる」というネットワークモデルを要件として定義しています。ノードをまたいでもPodのIPはそのまま宛先になり、送信元IPも書き換わりません。この前提があるため、Podは相手がどのノードにいるかを意識せず通信できます。実際にこの経路を敷設するのはKubernetes本体ではなく、後述のCNIプラグインです。Pod IPはPodの再作成で変わる揮発的なアドレスで、固定の宛先にはServiceを介します。 ### ClusterIPとkube-proxyが担うServiceの負荷分散の仕組み Serviceは、ラベルセレクタで選んだPod群に対して固定の仮想IP（ClusterIP）とDNS名を割り当てる抽象化です。呼び出し側はDNS名を引くだけで、背後のPodが増減してもエンドポイントの追従はKubernetesが行います。この仮想IP宛のパケットを実際のPodへ振り分ける担い手がkube-proxyです。iptablesモードやIPVSモード、CiliumのようなeBPFベースの実装が経路を書き換えます。DNS解決はクラスタ内DNS（CoreDNS）が担い、`service名.namespace`形式で名前解決できます。 ### PodネットワークとノードネットワークをつなぐCNIプラグインの選択肢 CNI（Container Network Interface）は、Pod作成時にネットワークインターフェースを割り当て、IPを配布し、ノード間の経路を張る差し込み式のプラグインです。オーバーレイ方式（VXLAN等でカプセル化）とルーティング方式（BGP等で素の経路を配る）があり、代表的な実装にCalico、Flannel、Ciliumがあります。CNIを差し替えるとネットワークの性能・可観測性・ポリシー機能が変わるため、クラスタ設計の初期に決める要素です。eBPFベースのCiliumの詳細は[CiliumとCalicoの比較・導入判断](https://www.issoh.co.jp/tech/details/13265/)で扱っています。 ## Service公開方式とIngress・Gateway APIの選定判断 外部からアクセスさせる方法はServiceのtypeとIngress／Gateway APIの組み合わせで決まります。まず4種類のServiceの守備範囲を押さえ、L7ルーティングが要る場面でIngress層を重ねる、という順で判断します。 ### ClusterIP・NodePort・LoadBalancerの使い分け条件 ServiceのtypeはClusterIPを基点に機能が積み上がる構造です。NodePortはClusterIPに全ノードの公開ポートを足し、LoadBalancerはさらにクラウドの外部ロードバランサを足します。内部通信だけならClusterIP、外部公開はクラウド上ならLoadBalancerが基本形です。 | type | 到達範囲 | 払い出すもの | 主な用途 | | ------------ | ----------- | --------------- | ---------------- | | ClusterIP | クラスタ内のみ | 仮想IP＋DNS名 | 内部サービス間通信（既定値） | | NodePort | ノードIP＋ポート | 30000〜32768のポート | 検証・LB前段・オンプレ暫定公開 | | LoadBalancer | インターネット等の外部 | クラウドの外部LB | クラウド上の外部公開の標準 | | ExternalName | 外部ホストへ転送 | CNAMEマッピング | 外部エンドポイントの別名化 | NodePortを本番の直接公開に使うと、ポート範囲の管理とノード障害時の可用性が課題になります。オンプレでLoadBalancerが使えない場合はMetalLB等でLB機能を補うのが実務的な選択です。MetalLBがどうやってExternal IPを配り、L2モードとBGPモードをどう選び分けるかは[MetalLBの仕組みとL2・BGPの選び方](https://www.issoh.co.jp/tech/details/15775/)で扱っています。 ### 複数サービスを1つの入口で束ねるIngressのL7ルーティング LoadBalancer型Serviceはサービスごとに外部LBを1つ払い出すため、公開サービスが増えるとコストとIPが膨らみます。Ingressは1つの入口でホスト名やパスに応じたL7（HTTP/HTTPS）ルーティングを行い、TLS終端やパスベースの振り分けを1箇所に集約します。ただしIngressリソースは仕様で、実際にトラフィックを捌くのはIngressコントローラ（別途デプロイするソフトウェア）です。リソースを書いてもコントローラが無ければ何も起きません。 ### Ingressの凍結とGateway APIへの標準化の現在地 Ingress APIはv1.19（2020年）でGAに達した後、機能追加が凍結（feature-frozen）されています。凍結は非推奨とは異なり、既存のIngressは引き続き動作しますが、新しい要件は後継のGateway APIへ移っています。Gateway APIはロール分離（インフラ担当のGatewayとアプリ担当のRoute）とL4/L7の統一的な表現を持ち、2026年前半のv1.5で多くの機能が標準（Stable）へ昇格し、AWS Load Balancer ControllerもGateway API対応をGA化しました。新規に入口を設計するなら、Ingressで作り込む前にGateway APIの適合コントローラを検討する段階に来ています。Istioを実装に使う場合のGatewayとHTTPRouteの設定例は、[Istio Gatewayの設定方法](https://www.issoh.co.jp/tech/details/18571/)にまとめています。 ## 実装現場のKubernetesネットワーク設計判断｜入口・CNI・ポリシーの決め方 ここからは競合記事が概念説明で止まりがちな部分に踏み込み、2026年時点で実際にどう決めるかを条件付きで言い切ります。判断軸は入口方式、CNI、そしてPod間通信の制御（NetworkPolicy）の3つです。 ### ingress-nginx退役（2026年3月）を踏まえた新規クラスタの入口設計 広く使われてきたingress-nginxコントローラは、2025年11月に退役が告知され、best-effortでのメンテナンスも2026年3月で終了します。以降は新規リリースも脆弱性修正も提供されません。既存デプロイは即座に止まるわけではありませんが、セキュリティ更新が絶たれる入口を長期運用するのは避けるべきです。新規クラスタでは、クラウドマネージドの入口（各クラウドのLBコントローラ）かGateway API対応コントローラ（Envoy Gateway、Istio、各クラウドのGateway実装等）を第一候補にします。既存のingress-nginx運用がある場合は、動くうちに移行先を確定し、TLS設定やアノテーション依存の棚卸しから着手するのが現実的な順序です。NGINX Ingressという呼称が指す2つの実装の違いと、退役後にどの移行先を選ぶかの判断基準は[退役したingress-nginxとF5版NGINX Ingress Controllerの違い・移行判断](https://www.issoh.co.jp/tech/details/15773/)で扱っています。 ### CNI選定の判断基準｜標準構成で足りる場面とCiliumを選ぶ条件 CNIは「とりあえず高機能」を選ぶ対象ではありません。マネージドKubernetes（EKS・GKE・AKS）では各クラウド既定のCNIで大半の要件は満たせ、まずはそれで足ります。標準構成を超えてCiliumやCalicoを積極採用するのは、次のいずれかに当てはまる場合に絞ります。第一に、NetworkPolicyをL3/L4だけでなくL7（HTTPメソッドやパス単位）で細かく制御したいとき。第二に、eBPFによるカーネルレベルの通信可観測性（サービス間の実トラフィック把握）が運用要件のとき。第三に、kube-proxyを置き換えて大規模クラスタのService処理性能を引き上げたいときです。逆に、数ノード規模で標準的なWeb三層を動かすだけなら、CNIを差し替える運用コストは投資に見合いません。Ciliumの機能差と移行判断は[Ciliumの導入判断の記事](https://www.issoh.co.jp/tech/details/13265/)にまとめています。 ### NetworkPolicyによるPod間通信の最小権限設計の基本 既定のKubernetesは、すべてのPodが相互に通信できる「全開放」の状態です。本番でこの状態を放置すると、1つのPodが侵害された際に横方向へ被害が広がります。NetworkPolicyは、Podへの入り（Ingress方向）と出（Egress方向）の通信を、名前空間やラベル、ポート単位で許可リスト方式に絞る仕組みです。設計の起点は「まず全遮断のデフォルトポリシーを敷き、必要な通信だけを明示的に開ける」最小権限です。ただしNetworkPolicyを解釈・強制するのはCNIで、CNIがポリシー非対応だと定義しても効きません。ここでCNI選定とポリシー設計が連動します。 ### 小規模チームがKubernetesネットワークで過剰投資しない境界 Kubernetesのネットワーク機能は強力ですが、全チームに必要なわけではありません。単一リージョンで数コンテナを動かすだけの構成なら、Serviceの数種類とマネージド入口を押さえれば十分で、独自CNIやサービスメッシュまで導入するのは過剰です。ネットワークの設計判断が重くなるのは、複数チームが同一クラスタを共有する、コンプライアンス上の通信分離が要る、サービス間通信が数十を超えるといった段階からです。そもそもKubernetesを採用すべきかの損益分岐は[コンテナオーケストレーションの必要性の判断](https://www.issoh.co.jp/column/details/13003/)で整理しており、ネットワーク設計はその採用判断の後に来ます。自社の規模に合った構成の見極めや、クラウド上のネットワーク構築は[インフラ構築の支援](https://www.issoh.co.jp/service/system/aws/)でも承っています。 ## Kubernetesネットワーク設計と運用でよくある質問と回答 Service・Ingress・Pod間通信・CNIをめぐって、設計初期に迷いやすい質問への回答をまとめます。 ### Kubernetesのネットワークはどういう仕組みで動いていますか？ Pod間はCNIが張るフラットなネットワークでIPどうしが直接届き、可変なPod群にはServiceが固定の仮想IP（ClusterIP）とDNS名を与えて負荷分散します。外部公開はNodePortやLoadBalancer型Service、L7ルーティングはIngressまたはGateway APIが担います。内部通信と外部公開を分けて捉えるのが理解の近道です。 ### ClusterIP・NodePort・LoadBalancerはどう使い分けますか？ 内部サービス間の通信だけならClusterIP（既定値）、外部公開はクラウド上ならLoadBalancerが基本です。NodePortは検証やLB前段の中継、オンプレの暫定公開向けで、本番の直接公開ではポート管理と可用性が課題になります。3種は機能が積み重なる関係にあり、LoadBalancerはNodePortとClusterIPの機能を内包します。 ### IngressとLoadBalancer型Serviceのどちらを使うべきですか？ 公開するのが1サービスで単純な転送だけならLoadBalancer型Serviceで足ります。ホスト名やパスで複数サービスを1つの入口に束ね、TLS終端を集約したい場合にIngress（またはGateway API）を重ねます。ただし新規設計では、Ingressが凍結済みでGateway APIへ標準化が進んでいる点を踏まえ、Gateway API対応コントローラの検討が第一候補です。 ### ingress-nginxが退役すると既存のIngressはどうなりますか？ Ingress API自体は残るため、既存の設定がすぐ動かなくなるわけではありません。止まるのはingress-nginxという特定のコントローラのメンテナンスで、2026年3月以降は新規リリースも脆弱性修正も出ません。セキュリティ更新が絶たれるため、Gateway API対応コントローラやクラウドマネージドの入口、あるいは他のIngressコントローラへ、動くうちに移行を進めるのが安全です。 ### CNIは何を基準に選べばよいですか？ マネージドKubernetesでは各クラウド既定のCNIでまず足ります。L7単位のNetworkPolicyやeBPFによる通信可観測性、kube-proxy置換による大規模時の性能が要件になった段階で、CiliumやCalicoを検討します。NetworkPolicyの強制はCNIに依存するため、ポリシーで細かく通信を絞る設計とCNI選定はセットで決めるのが実務です。 ## 関連記事 - [Kubernetes（K8s）とは？読み方・意味から仕組みまで](https://www.issoh.co.jp/tech/details/2928/)：本記事の前提となるKubernetes全体の役割とアーキテクチャの基礎。 - [Ciliumとは？eBPFベースのCNIの仕組みとCalico比較・導入判断](https://www.issoh.co.jp/tech/details/13265/)：CNI選定を掘り下げる主従先。eBPF/L7ポリシー/kube-proxy置換の詳細。 - [コンテナオーケストレーションとは？Kubernetesの必要性の判断](https://www.issoh.co.jp/column/details/13003/)：ネットワーク設計の前段、Kubernetesを採用すべきかの損益分岐。 - [Kubernetes監視・モニタリングの設計｜メトリクス・ログ・アラート閾値の実装判断](https://www.issoh.co.jp/tech/details/15303/)：ネットワークと並ぶ運用設計の柱である監視基盤の構成とアラート設計。 - [CoreDNSとは？Kubernetesの名前解決の仕組みとCorefile設計を解説](https://www.issoh.co.jp/tech/details/15771/)：Service名を引く側の実装層。Corefileのオプションとndots:5のチューニング判断。 --- 出典: [Kubernetesネットワーク設計｜Service・Ingress・Pod間通信とCNI選定の実装判断]()（株式会社一創）