Kubernetes Pod 通信の全貌：Service 経由でどう繋がるのか？【株式会社ライトコード】

この記事で学べること

Pod 間の通信が内部でどう処理されるか（DNS → Service → iptables の流れ）
DNS・Service・kube-proxy・NetworkPolicy の順に切り分ける調査チェックリスト
kube-proxy が iptables チェーンを使ってどのように負荷分散するか

対象読者：Kubernetes を使い始めて、ネットワーク周りで詰まった経験がある人。

はじめに

Kubernetes のネットワーク問題は「知識がない」んじゃなくて——十分に慣れていないから、すぐ原因を特定できない、それが本音じゃないだろうか。

実際にはまった典型的なケースがある：

サービス A から user-service を呼ぶと、断続的にタイムアウト。
アプリのログはクリーン、Pod もすべて Running。
見た目は「正常」なのにリクエストが詰まる。

こういう問題が一番きつい——再現しない、目に見えない、ログにも出ない。

だからひとつひとつ、リクエストの経路を追いかけていった。その調査をそのまままとめたのがこの記事だ。

キーワードの整理

本文に入る前に、頻出する用語を簡単に押さえておく。

通信経路の全体像

まず全体の流れを把握しておく。リクエストは以下の順に処理される：

Pod → CoreDNS（名前解決）→ ClusterIP → kube-proxy（iptables DNAT）→ 宛先 Pod

ポイントは、Pod は宛先 Pod の IP を直接知らないという点だ。Service 名から ClusterIP を引いて、カーネルの iptables が裏で宛先を書き換えている。

以下では①〜④を順に確認していく。

Step 1：DNS を確認する（名前解決）

なぜ DNS から始めるのか

curl http://user-service が失敗するとき、最初に確認すべきは「そもそも user-service という名前が解決できているか」だ。DNS が壊れていれば、その先の調査は意味がない。

確認方法

Pod の中に入る：

kubectl

名前解決を試みる：

nslookup user-service

成功時のレスポンス（正常）：

Name:    user-service.default.svc.cluster.local

Address: 10.96.100.50

返ってくるのは Pod の IP ではなく、**Service の仮想 IP（ClusterIP）**であることに注目。

失敗した場合 → CoreDNS が原因。次を確認する：

kubectl get pods -n kube-system | grep coredns

kubectl logs -n kube-system <coredns-pod>

CoreDNS の内部動作

CoreDNS は kube-apiserver を watch して Service 情報をキャッシュに保持している。Pod からの DNS クエリが来るたびに API サーバーへ問い合わせるのではなく、キャッシュから ClusterIP を返す。Pod はこの ClusterIP 宛にパケットを送る。

…