【入門編】 Kubernetes Service（NodePort/LoadBalancer）におけるkube-proxyのiptables/IPVSとNATの連携 – クラウド＆コンテナネットワーク実践ガイド

Kubernetesの「魔法の郵便局」：ServiceとNATが裏側でやっていること

こんにちは！SREとして日々クラウドと格闘していると、時折「Kubernetesって、なんであんなに魔法みたいに通信が繋がるの？」という質問をいただきます。

特に Service（NodePort や LoadBalancer）の仕組みは、初学者にとって最大の難関ですよね。今日は、パケットがKubernetesという巨大な都市の中でどうやって目的地（Pod）にたどり着いているのか、その「裏側の郵便配達」の仕組みを紐解いていきましょう。

—

そもそも、なぜNATが必要なの？

Kubernetesの世界では、Podが生まれては消え、IPアドレスも頻繁に変わります。「今日のPodの住所はここ、明日はあっち」という状況で、外部からサービスにアクセスしたい場合、毎回変わる住所を追いかけるのは不可能です。

そこで登場するのが Service です。これは「架空の郵便番号（ClusterIP）」を一つ持っておき、そこに届いた荷物を、その時稼働しているPodたちへ適宜転送してくれる仕組みです。この時、「宛先を書き換える」という処理が必要になります。これが「NAT（Network Address Translation）」の正体です。

—

郵便局員 kube-proxy の仕事

各ノードには kube-proxy という小さな郵便局員が常駐しています。彼らは、APIサーバーから「どのサービスにどのPodが紐付いているか」という最新の配送リストを受け取り、ノードの交通整理ルール（iptables または IPVS）を更新し続けています。

1. iptables（伝統的な交通整理）

昔ながらの方法です。交差点に立っている交通整理員が、「この宛先（ClusterIP）に来たパケットは、あっちのPodのIPに書き換えて（DNAT）流せ！」という指示書を大量に持っている状態です。

メリット: 非常にシンプルで、どんな環境でも動く。
デメリット: ルールが増えすぎると、交通整理員（CPU）が確認作業に追われて遅延が発生する。

2. IPVS（高速道路の料金所）

こちらは、宛先をハッシュテーブルという「一覧表」で管理します。まるで高速道路の料金所のように、パケットが来たら即座に「お前はあのレーンへ行け」と仕分けます。ルールが何千個あっても速度が落ちない、現代の主流です。

—

実践：DNATの動きを覗いてみる

実際に iptables がどのような設定になっているか、ノードに入って覗いてみましょう。

# 現在のnatテーブルのルールを確認するコマンドです
# 複雑ですが、'KUBE-SERVICES' というチェインが交通整理の司令塔です
sudo iptables -t nat -L KUBE-SERVICES -n

出力結果の中に、以下のようなものを見つけたことはありませんか？

# 10.96.0.10 というClusterIP宛てのパケットを
# KUBE-SVC-XXX という処理ルールへ飛ばす、という意味です
DNAT  tcp  --  0.0.0.0/0  10.96.0.10  tcp dpt:80  /* ... */  to:192.168.1.5:8080

ここで起きているのが DNAT（宛先アドレス変換） です。
1. パケットがノードに届く。
2. iptables が「おっ、宛先が 10.96.0.10 だな？じゃあ実体である 192.168.1.5 に書き換えよう！」とヘッダーを書き換える。
3. 書き換えられたパケットは、そのままPodへと配送される。

—

初学者が押さえておくべきポイント

この仕組みを理解する上で、以下の3点を意識するだけで、トラブルシューティングの精度が劇的に変わります。

1. Serviceは「実体」ではない:
ClusterIP はノード上のどこにも割り当てられていない「仮想的な宛先」です。ping を打っても返ってこないのは、これが単なる「ルールの宛先ラベル」だからです。

2. 負荷分散はランダム:
iptables での分散は、基本的にはランダムです。もし「特定のユーザーを特定のPodに固定したい（セッション維持）」という場合は、Service の設定で sessionAffinity: ClientIP を指定する必要があります。

# サービスの設定例
apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080
  sessionAffinity: ClientIP # これで同じIPからのアクセスは同じPodへ送られます

3. NATは「帰りの道」も覚えている:
DNATで書き換えた場合、戻りの通信（レスポンス）もそのままではPodのIPのままになってしまいます。そのため、kube-proxy は帰りの通信に対しても「送信元を元の ClusterIP に戻す（SNAT）」という逆の処理を裏で行っています。パケットは往復で帳尻が合うようになっているのです。

—

まとめ：ネットワークは「見えない流れ」

Kubernetesのネットワークを理解することは、目に見えないパケットの旅を想像することです。「なぜ繋がらないのか？」と悩んだ時、まずは「このパケットは今、どの交差点で、どの交通整理員（iptablesルール）に止められているのか？」を想像してみてください。

最初は難しく感じるかもしれませんが、パケットという名の郵便物が、ルールに従って目的地へ運ばれる仕組みをイメージできれば、Kubernetesはもっと面白くなりますよ！

次回は、この「魔法の交通整理」がクラウドのロードバランサーとどう連携しているのか、より深い階層まで潜っていきましょう。それでは、良いコンテナライフを！