kube-proxyはKubernetesクラスタの各ノードで動く軽量なネットワーク部品で、ClusterIPやNodePortといったServiceに届いた通信を、実際のPod群に振り分ける役割を担います。2014年のKubernetes初期から存在する古参コンポーネントで、Go言語で実装されDaemonSetとして全ノードに常駐します。ユーザーが意識することは少ない裏方ですが、「Service名で呼び出したらPodに届く」というKubernetesの基本的な約束事を成立させているのはこの部品で、止まればクラスタ内通信が一斉に詰まる重要ピースです。
この記事の目次
- iptables・IPVS・nftablesの3モード
- Serviceからの通信が届くまでの流れ
- 監視と障害対応のポイント
- eBPFベースの新世代との比較
- まとめ
iptables・IPVS・nftablesの3モード
kube-proxyは現在3種類の動作モードを選べます。既定はiptablesモードで、Service・Endpointsの変化をwatchしながらLinuxカーネルのiptablesルールを書き換えていく方式です。実装はシンプルでLinux標準の機能だけで完結する半面、Service数が数千を超えるとルール更新のたびに数秒単位の遅延が発生する弱点があります。
大規模クラスタ向けに用意されたのがIPVSモードで、Linuxカーネルが標準で持つロードバランサー機能（IP Virtual Server）を活用します。ハッシュテーブルで宛先を解決するためルール数が増えても性能が劣化しにくく、ラウンドロビンや最小接続といったアルゴリズムも選べます。さらに新しい選択肢としてnftablesモードがKubernetes 1.29で安定化に向けて整備されており、iptablesの後継となる仕組みで将来的な置き換えが進む見込みです。現場では「数百Service程度ならiptables、数千を超えるならIPVS、新規構築なら様子を見つつnftables」が一つの目安です。
Serviceからの通信が届くまでの流れ
kube-proxyの仕事を時系列で追うと、まずユーザーがkubectl apply -f service.yamlでServiceを作成します。APIサーバーはこれをetcdに保存し、同じくクラスタに常駐するEndpointSliceコントローラが「このServiceに紐づくPodのIPはこれです」というEndpointSliceリソースを生成します。
各ノードのkube-proxyはこのEndpointSliceをwatchしていて、変化を検知するとiptables（あるいはIPVS／nftables）のルールを書き換え、ClusterIP宛のパケットを実際のPod IPへDNATする経路を作ります。クライアントPodがService名でアクセスすると、CoreDNSがClusterIPを返し、そのIP宛パケットがカーネルに入った瞬間にkube-proxyが用意したルールが発動して特定のPodへ書き換えられる、という流れです。ネットワークパケット自体はカーネルが扱うため、kube-proxyプロセスは「ルールを書く管理者」であって、毎パケット処理のホットパスには入らない設計になっています。
監視と障害対応のポイント
kube-proxyの健全性を計る代表的なメトリクスはkubeproxy_sync_proxy_rules_duration_secondsで、Service・Endpointsの変化をルールに反映するまでの所要時間を表します。ここが秒単位に伸び続けるようなら、Service数の急増や別プロセスとのiptables競合などを疑います。iptablesモードではノードのCPU負荷も無視できず、Service数が数千を超えるとルール書き換え時に明確にCPUを食います。
もう1つ重要なのが、Linuxカーネルのconntrackテーブル（接続追跡テーブル）の枯渇です。NodePortで大量のショートライブ接続を捌くワークロードではここが詰まりやすく、net.netfilter.nf_conntrack_maxの値を引き上げないと「ある時点から急に通信が落ちる」現象に見舞われます。障害時はノードにログインしてiptables -L -n -t natで実際のルールを確認したり、kubectl get endpointslice -A -o wideでEndpointSliceが想定通り更新されているかを照らし合わせるのが定番手順です。
eBPFベースの新世代との比較
kube-proxyに代わる選択肢として、近年はeBPFベースのCNI実装が注目されています。代表例がCiliumで、ノード上でeBPFプログラムを直接カーネルに差し込み、Serviceの宛先解決を中継処理なしで実現することで、iptablesモードのスケーラビリティ限界を回避します。AWSのEKSやGoogle GKEもCilium経由のkube-proxyレス構成を選択肢として提供し始めています。
ただしkube-proxyが消えるわけではなく、Cilium・Calico eBPFモードなどを明示的に有効化した時にだけ無効化される、オプション的な扱いです。標準の安定運用を最優先するなら従来のkube-proxyを使い続けるのが安全で、数千Service・数万Pod級の規模やネットワーク可視化を強化したい時にeBPF系へ移行する、というのが一般的な判断軸です。「使い慣れたiptables vs 最先端eBPF」という二項対立に見えますが、運用チームのスキルセットや障害時の調査手順も含めて選定するのが現実的です。
まとめ
kube-proxyはKubernetesの各ノードで動き、Service宛の通信を実際のPodへ振り分ける裏方コンポーネントです。iptables・IPVS・nftablesの3モードを使い分け、Service数とパフォーマンス要件に応じて構成を選ぶのが定石です。近年はCilium等のeBPF実装と棲み分けながら、クラスタ通信の標準的な土台として今も第一線で動き続けています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント