kube-proxy とは？初心者でもわかるKubernetesのネットワークの要点ガイド共起語・同意語・対義語も併せて解説！

この記事を書いた人

高岡智則

年齢：33歳性別：男性職業：Webディレクター（兼ライティング・SNS運用担当）居住地：東京都杉並区・永福町の1LDKマンション出身地：神奈川県川崎市身長：176cm 体系：細身〜普通（最近ちょっとお腹が気になる）血液型：A型誕生日：1992年11月20日最終学歴：明治大学・情報コミュニケーション学部卒通勤：京王井の頭線で渋谷まで（通勤20分）家族構成：一人暮らし、実家には両親と2歳下の妹恋愛事情：独身。彼女は2年いない（本人は「忙しいだけ」と言い張る）

kube-proxy とは？ Kubernetes のネットワークを動かす秘密の味方

kube-proxy は Kubernetes クラスタのノード上で動く小さなプログラムです。クラスタ内の複数のコンポーネントが作るサービスという概念を、実際のネットワークに結びつける役割を担います。

kube-proxy の役割

サービスに対するアクセスを受け取り、適切な Pod に転送するのが主な役割です。これにより、アプリが複数の Pod に分散していても、クライアントは同じ Service IP だけを使えばよくなります。

どこで動くの？

通常は各ノードで動作します。クラスタのすべてのノードに kube-proxy が存在することで、どのノードにアクセスしても正しく Pod に届くようになっています。

どうやって転送するの？

kube-proxy は Linux の iptables や ipvs を使って、Service へのトラフィックを適切な Pod のアドレスへ転送します。モードとしては、古い時代の userspace、現在は推奨される iptables または ipvs があります。

モードの比較と仕組みのイメージ

以下の表は、kube-proxy がどのように動くかをざっくりイメージするのに役立ちます。

モード	説明	長所	短所
userspace	初期の実装で、サービスの宛先を kube-proxy が受け取り、転送を試みる	互換性が高い、設定が単純	性能が低いことがある
iptables	Linux の netfilter ルールを使って転送	パフォーマンスが安定、広く使われる	規模が大きくなると複雑さが増す
ipvs	IPVS でロードバランスを実現	高性能、数百〜数千のサービスに強い	設定が少し難しくなる場合がある

実務での基本的な流れ

サービスを作成すると Kubernetes API サーバーが EndPoints を作り、実際の Pod のアドレスを kube-proxy に知らせます。kube-proxy はこの情報を使ってネットワークのルールを自動的に更新します。トラフィックが発生すると、Service IP に来たパケットは、kube-proxy が選んだ Pod の IP アドレス へ転送され、Pod が受け取って処理します。

運用のポイントと注意点

クラスタを運用すると、ノードが増減したり、Pod が再配置されることがあります。そのたびに kube-proxy のルールも更新され、トラフィックの流れは崩れません。監視やログを有効にしておくと、不具合の原因を特定しやすくなります。

よくある疑問

Q: kube-proxy は本当に必須ですか？

A: ほとんどの Kubernetes クラスタでは必須です。Service の背後にある Pod へトラフィックを振り分ける仕組みを提供します。

Q: どのモードが良いですか？

A: 環境にもよりますが、最新の推奨は iptables または ipvs です。特に大量のリクエストがある場合は ipvs が有利です。

このように kube-proxy は、私たちが普段使う「サービス」という概念を、実際の Pod へと橋渡しする橋渡し役です。ネットワークの設定を自動的に行い、アプリケーションの可用性と拡張性を支えています。

実際の運用例と学習のヒント

初心者向けの学習としては、まず minikube などのローカルクラスタを試してみましょう。Service を作成し、kubectl get svc で Service の IP を確認します。次にその IP アドレスとポートに対して curl してみると、kube-proxy がどのように動作しているかを体感できます。トラフィックが正しく流れると、同じ Service IP に対して複数のリクエストが、背後の Pod に均等に振り分けられることが分かります。

kube-proxyの同意語

kube-proxy: Kubernetesノード上で動作するネットワークプロキシ。サービスの clusterIP へのトラフィックを適切なポッドへ転送するためのルールをノードレベルで設定します。
Kubernetes proxy: 英語表記の同義語。Kubernetesクラスタ内のサービス間の通信をルーティングし、トラフィックをポッドへ負荷分散します。
kube proxy: スペース入りの表記。基本的には kube-proxy と同義で、ノード上の代理機能を指します。
Kubernetesネットワークプロキシ: Kubernetesにおけるネットワーク通信を仲介するプロキシ機能の総称。サービスのルーティングとポリシー適用を担います。
Kubernetesサービスプロキシ: Kubernetesのサービスに対するトラフィックを転送・分散する役割を表す表現。ポートの転送やロードバランシングを含みます。
ノード上のKubernetesプロキシ: 各ノードで動作する kube-proxy の機能を指す説明表現。ノード内のトラフィックを適切に振る舞います。
iptablesベースのプロキシ: kube-proxy が実装する転送ルールの一形態。iptablesを用いてトラフィックをポッドへ振り分けます。
IPVSベースのプロキシ: kube-proxy の実装の一つで、IPVSを用いてロードバランシングと転送を実現します。
Kubernetesサービスロードバランサ: クラスタ内のサービスへ来るトラフィックをポッドへ分散させるロードバランシング機能を指す表現。kube-proxy の役割の一部です。

kube-proxyの対義語・反対語

直接通信: クライアントとポッドが直接通信する構成で、kube-proxyを介さない状態を指す。
プロキシなし: ノード上のkube-proxyなどのプロキシ機能を使わずに通信を実現する考え方。
サイドカープロキシ: 各ポッド内にプロキシを配置してトラフィックを処理する設計。kube-proxyの代替として使われることがある。
アプリケーションレベルロードバランサー: L7レイヤでロードバランシングを行うソリューション（例：IngressやEnvoy）を使い、L4のkube-proxyの代わりにトラフィックを分配する構成。
DNSベースロードバランシング: DNSを用いて複数のエンドポイントを返し、トラフィックを分散する方法。kube-proxyに依存しない負荷分散の考え方。
直接エンドポイントアクセス: サービスの実エンドポイント（ポッドIP）へ直接アクセスする方法。kube-proxyを経由しない前提。
ノード間直接ルーティング: ノード間のトラフィックを直接ルーティングする設計で、kube-proxyの介在を減らす／なくす方向性。
プロキシレス構成: 全体としてプロキシ機能を使わずに通信を成立させる設計思想。

kube-proxyの共起語

サービス: Kubernetes Service の概念。クラスタ内のポッド群を1つの仮想的なエンドポイントとして外部/内部から参照できる入口を提供します。
ClusterIP: クラスタ内で共通に使う仮想IP。サービスの内部宛先としてポッドへトラフィックを振り分ける入口です。
NodePort: ノード上の特定ポートを公開し、外部からそのノードのIPとポートでサービスにアクセスできるようにする仕組み。
LoadBalancer: クラウド環境の外部ロードバランサと連携し、サービスへの外部アクセスを実現します。
ExternalIPs: クラスタ外部の固定IPをサービスに割り当て、外部からの直接ルーティングを可能にします。
ExternalTrafficPolicy: 外部から来たトラフィックのバックエンドへどの経路で配るかを制御します。Local または Cluster の2択。
Endpoints: サービスに紐づく実際のポッド（エンドポイント）の集合。kube-proxyはこれを監視してルーティングを決定します。
EndpointSlices: エンドポイントを分割して管理する新しい形式。大規模クラスターでの拡張性を向上させます。
iptables: kube-proxyがiptablesルールを操作して、サービスのトラフィックをポッドへ転送するデフォルトのモードの一つ。
IPVS: kube-proxyがIPVSでロードバランシングを実現するモード。パフォーマンスとスケーラビリティを向上させます。
ユーザースペースモード: 旧来の実装モード。kube-proxyがポート転送をGoプログラム経由で行うため、パフォーマンスが低下することがあります。
iptablesモード: iptablesを使ってサービスのルールを管理するモードの名称。kube-proxyの代表的な動作モードの一つ。
IPVSモード: IPVSを使ってサービスのロードバランシングを実現するモード。高性能なルーティングが特徴です。
ノード: kube-proxyは各ノード上で動作し、ローカルのネットワーク規則を設定してトラフィックを制御します。
Kubernetes APIサーバー: kube-apiserver。クラスタ状態の変更を通知・取得する中心部。kube-proxyはこのAPIを監視します。
エンドポイント監視: ServiceとEndpointの変化をリアルタイムで検知して、ルーティング設定を更新します。
クラウドプロバイダ連携: LoadBalancerの実体提供など、クラウド環境と統合して動作する場面があります。
DNS/サービスディスカバリ: CoreDNSなどを用いた名前解決とサービス発見。kube-proxyはサービス名解決と紐づけで関係します。
ネットワークプラグイン(CNI): CNIはネットワーク機能の実装全体。kube-proxyはCNIと併走してクラスタ内の通信を整えます。
ネットワークポリシー: 通信制御ポリシー。直接は kube-proxy の責務ではないが、サービスアクセスに影響します。
メトリクス/監視: kube-proxyの挙動を監視する指標や /metrics による可観測性。パフォーマンスの検証に使われます。

kube-proxyの関連用語

kube-proxy: Kubernetesクラスタ内でServiceとPodの間のトラフィックを橋渡しするデーモン。Serviceの仮想IP（ClusterIP）を実際のPodへ転送します。ノード上で動作し、DaemonSetとして展開されることが多いです。
iptables: Linuxのパケットフィルタリングとルーティングを実現する仕組み。kube-proxyのモードのひとつで、iptablesルールを使ってServiceのトラフィックをPodに振り分けます。
ipvs: Linuxの IP Virtual Server。kube-proxyのモードの一つで、IPVSの仮想サーバとしてトラフィックを分散します。大規模環境で性能が高いです。
Userspaceモード: kube-proxyの古い動作モード。代理サーバとして動作し、クライアントとPodの間を直接行き来させます。
iptablesモード: iptablesを用いてServiceのルーティングを設定するkube-proxyのモード。現代ではipvsに置換されつつあることが多いです。
ipvsモード: IPVSを用いたkube-proxyのモード。高性能・高スケールでのロードバランシングを提供します。
Service: Kubernetesの抽象概念で、Pod集合への安定したアクセス手段。ClusterIP、NodePort、LoadBalancerのタイプを持ちます。
ClusterIP: Serviceに内部的に割り当てられる仮想IP。クラスター内からこのIPでサービスにアクセスします。
NodePort: Serviceをノードの特定ポートで公開するタイプ。外部からのアクセスをノードのIPとポートで受けられるようにします。
LoadBalancer: クラウドプロバイダのロードバランサーを介してServiceを公開するタイプ。外部トラフィックをクラスターへ誘導します。
Endpoints: Serviceと実際のPodを結ぶエンドポイント情報の集合。PodのIPとポートを保持します。
EndpointSlices: Endpointsより新しいエンドポイント表現。小さな単位でエンドポイントを管理でき、規模の大きい環境で効率化します。
VIP: Serviceが持つ仮想IPの略称。ClusterIPと関連して使われます。
DaemonSet: クラスタ内の各ノードで1つずつ実行されるPodを作るリソース。kube-proxyは通常DaemonSetとして動作します。
CNI: Container Network Interface。ネットワークを提供するプラグインの枠組みで、kube-proxyはCNIと連携して動作します。
DNS(CoreDNS): サービス名をIPに解決する名前解決システム。クラスター内の通信で重要です。
NetworkPolicy: ポッド間の通信を許可・拒否するルールを定義する機能。クラスタのセキュリティを強化します。
Masquerade: NATの一種。ノード間のトラフィックの送信元を隠し、応答が正しく返るようにします。
NAT: Network Address Translation。アドレス変換の総称。kube-proxyのルーティングにも関係します。
ExternalTrafficPolicy: 外部からのトラフィックをどのノードで受けるかを制御する設定。NodePort/LoadBalancerの挙動に影響します。
APIサーバー(Kubernetes API): KubernetesのAPIの中心。リソースの作成・更新を行うエントリポイントです。