---
title: Kubernetes Load Balancing について
tags:  #kubernetes  
author: [sou (08thse)](https://www.docswell.com/user/08thse)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/VEPKW4KZ78.jpg?width=480
description: Kubernetes の Load Balancing 周りについて技術メンタリングで活用した資料を一般にも公開しておきます。  ＃AI に資料作成を手伝ってもらっており、レイアウト等に少し課題感ありますが妥協です😅
published: June 11, 26
canonical: https://www.docswell.com/s/08thse/ZY8VME-2026-06-11-002718
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/VEPKW4KZ78.jpg)

Kubernetes Load Balancing 入門
CILIUM BLOG READING SESSION
Service・Ingress・kube-proxy・eBPF まで
— トラフィックがPodに届くまでの旅 —


# Page. 2

![Page Image](https://bcdn.docswell.com/page/27VV8XVM7Q.jpg)

本日お話すること
08THSE TECH STUDY — KUBERNETES LOAD BALANCING
AGENDA
CHAPTER 01
CHAPTER 02
Service・Pod・なぜLBが必要なのか
East-West / North-South / Service Type
Kubernetes ロードバランシングの基本
内部 vs 外部 ロードバランシング
CHAPTER 03
CHAPTER 04
L2 (ARP) / L4 (TCP) / L7 (HTTP)
kube-proxy 置き換え・Maglev・DSR
OSI レイヤーで見るLB
Cilium と eBPF / XDP の世界
💡 想定レベル：Kubernetesの基礎（Pod / Service / Deployment）を知っている方を対象。eBPF・BGP等は都度補足します。
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/5JGL5VLX7L.jpg)

08THSE TECH STUDY — KUBERNETES LOAD BALANCING
Kubernetes ロードバランシング
の基本
CHAPTER 01
そもそも「Kubernetesにおけるロードバランシング」とは何か。
Service・Pod・Endpoint の関係から振り返ります。
✓ Service とは
✓ なぜLBが必要
✓ Service Type の違い
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/47QYZ6Y5EP.jpg)

なぜロードバランシングが必要か
08THSE TECH STUDY — KUBERNETES LOAD BALANCING
WHY LOAD BALANCING
Kubernetes では同じアプリが複数Podで動く。healthyな全インスタンスにトラフィックを分散 することで、3つの目的を達成する。
GOAL 01
GOAL 02
GOAL 03
Health Check と Readiness Probe で 失敗中のPodを除外。
死んだPodにトラフィックが届かない。
複数レプリカに分散することで、 単一Pod・ノード障害でも
停止しない。
負荷を均等配分して 水平スケール を実現。Pod増設＝処理
能力増加。
信頼性 / Reliability
可用性 / Availability
性能 / Performance
分散の重みは アルゴリズム 次第（Round Robin / Least Connection / Maglev など）。 どこで・どのレイヤーで分散するか が本日のポイント。
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/KE4W34WVJ1.jpg)

Service / Pod / Endpoint の関係
08THSE TECH STUDY — KUBERNETES LOAD BALANCING
KNOWLEDGE REFRESH
Pod の IP は 寿命が短く再起動の度に変わる。だから「安定した宛先」が必要 — それが Service。
POD
アプリの実行単位。動的IP、寿命短い、replicaで複数並ぶ
SERVICE
仮想IP（VIP）と宛先の抽象化。Selector で対象Podを動的にひも付け
ENDPOINTSLICE
Selectorに合致したPodのIP一覧。実際の分散先リスト
Traffic Flow
① Client
curl http://my-svc:80
↓
② Service (VIP)
10.96.42.1:80
↓ kube-proxy / Cilium
③ EndpointSlice
10.244.1.5 10.244.2.7
↓ select one
④ Pod
10.244.3.9
10.244.2.7:8080
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/L71Y14Y4JG.jpg)

Service Type は4種類
08THSE TECH STUDY — KUBERNETES LOAD BALANCING
KNOWLEDGE REFRESH
どこからアクセスさせるかで spec.type を選ぶ。
ClusterIP
DEFAULT
クラスタ内部のみ
VIPを払い出してPod間通信用に使う。 East-West (内部) の主役。
LoadBalancer
クラウド/外部LBと連携
クラウドが外部VIPを払い出す。 本番でよく使う公開タイプ。オンプレはMetalLB等が必要。
NodePort
全ノードで特定ポートを公開
どのノードIPでも 30000-32767 番で受け付ける。 外部公開の最も素朴な方法。
ExternalName
CNAMEレコード相当
外部DNS名へのエイリアス。Pod宛ではなく 名前解決の置換。LB処理は発生しない。
ℹ️ 補足: L7（HTTPホスト名・パスベースルーティング）は Ingress または後継の Gateway API が担当（Service の更に上位レイヤー）。
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/G7WG8XGZE2.jpg)

08THSE TECH STUDY — KUBERNETES LOAD BALANCING
トラフィックの
2つの方向
CHAPTER 02
Pod-to-Pod の通信（East-West）と、外部からの流入（North-South）は
LBの仕組みが大きく異なります。
✓ East-West vs North-South
✓ kube-proxy の役割
✓ Ingress / Gateway API
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/4JZL86LLE3.jpg)

East-West と North-South
08THSE TECH STUDY — KUBERNETES LOAD BALANCING
TRAFFIC DIRECTION
INTERNAL LB
East-West (東西 = Pod ⇄ Pod)
クラスタ 内部 のサービス間通信。例：API Pod → DB Pod、frontend → backend。
担当： ClusterIP Service + kube-proxy / Cilium
仕組み： 各ノードで iptables / IPVS / eBPF が DNAT
主目的： マイクロサービス間の疎結合化
EXTERNAL LB
North-South (南北 = Internet ⇄ Pod)
クラスタ 外部 からの流入。例：ユーザのブラウザ → Webアプリの Pod。
担当： NodePort / LoadBalancer / Ingress / Gateway API
VS
仕組み： クラウドLB or MetalLB / Cilium L2/BGP
主目的： サービスをインターネット公開
// pod-A inside cluster
// from public internet
curl http://payment-svc:8080
curl https://api.example.com
💡 本日のテーマ： East-West が圧倒的にトラフィック量が多い のが現代のマイクロサービス。だから「内部LBの性能」が重要。
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/YE6WP2WMEV.jpg)

内部LB の主役 — kube-proxy
08THSE TECH STUDY — KUBERNETES LOAD BALANCING
INTERNAL LOAD BALANCING
Pod A が Pod B に直接 IP を打つことはなく、 Service の VIP を経由する。
その VIP の解決を担うのが各ノード上の kube-proxy。
kube-proxy が行うこと
① Kubernetes API を Watch（Service / EndpointSlice の変更を監視）
② 変更をローカルの ネットワークルール に翻訳
③ VIP宛パケットを DNAT で実Pod IP に書き換え
ポイント： kube-proxy は L4まで。HTTPヘッダーは見ない。あくまで「IP:Port を別の
IP:Port に書き換える」だけのコンポーネント。
3 つの実装モード
iptables モード
DEFAULT
Linuxのpacket filterルールを大量生成。Service増加で 線形に走査コストが増加。
▸ SEQUENTIAL LIST — O(N)
IPVS モード
L4 LB
カーネルの L4LB 機能を使用。 ハッシュテーブル ＋ RR/Least-Conn 等のアルゴリズム。
▸ H A S H - B A S E D — B E T T E R AT S C A L E
eBPF モード (Cilium)
RECOMMENDED
kube-proxy/iptables を 完全置換。カーネル最深部で処理しコンテキストスイッチを排除。
▸ L O W E S T L AT E N C Y , H I G H E S T T H R O U G H P U T
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/GE5MK2MQE4.jpg)

外部からクラスタへ — 4つの選択肢
08THSE TECH STUDY — KUBERNETES LOAD BALANCING
EXTERNAL LOAD BALANCING
1
NodePort L 4 / 各ノードの 3 0 0 0 0 - 3 2 7 6 7
2
Service Type: LoadBalancer L 4 / クラウド連携
3
Ingress L 7 / S M A R T R O U T E R
4
Gateway API
全ノードIPで特定ポートを開けて受け付け。 最も素朴。クラウド非依存だが、外部LBは別途必要。
クラウドプロバイダのLB（AWS NLB / GCP LB等）と統合し外部VIPを払い出す。 本番標準。
ホスト名 / パスベースのルーティング、SSL終端。NodePort/LoadBalancer の 背後に立つL7。
SUCCESSOR OF INGRESS L 4 + L 7 /
次世代 A P I
Ingress の後継。動的なインフラ provisioning と高度なルーティング。 Cilium はネイティブサポート（Envoy + eBPFデータパス、Hubbleで全リクエスト可視化）。
オンプレ・ベアメタルの場合： クラウドのような Type=LoadBalancer がデフォルトでは動かない。 Cilium LB / MetalLB を使い、ARP (L2) または BGP (L3) でVIPを広告して同等の
体験を実現する。
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/9729W49WJR.jpg)

08THSE TECH STUDY — KUBERNETES LOAD BALANCING
OSI レイヤー
で見るLB
CHAPTER 03
L2（ARP）/ L4（TCP/UDP）/ L7（HTTP）
それぞれが「速度」「賢さ」「柔軟性」のトレードオフを持つ。
✓ L2-Aware (ARP / BGP)
✓ L4 (iptables / IPVS)
✓ L7 (HTTP / gRPC)
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/DJY4LM497M.jpg)

L2 / L4 / L7 — 役割の違い
08THSE TECH STUDY — KUBERNETES LOAD BALANCING
L AY E R S OV E R V I E W
「下層ほど速い・上層ほど賢い」 — 用途に応じて使い分ける。
D ATA L I N K L AY E R
T R A N S P O R T L AY E R
A P P L I C AT I O N L AY E R
ARP / NDP の応答で「Service IP は この MAC アドレス です
よ」と LAN に広告。
ARPでMAC通知
BGPなしでもOK
オンプレ向け
パケットの中身は見ず、 IP:Port のヘッダーだけで宛先決
定。低オーバーヘッド。
高スループット
L7情報は不可視
標準ClusterIP/LB
HTTPヘッダー・URLパス・gRPCメソッドを 解釈してルーテ
ィング。最も賢い。
パス/ホスト分岐
SSL終端/A-Bテスト
処理コスト高め
L2-Aware LB
例 : C I L I U M L 2 A N N O U N C E M E N T S / M E TA L L B
L4 LB (TCP/UDP)
例 : K U B E - P R OX Y / I P V S / C I L I U M E B P F
L7 LB (HTTP/gRPC)
例 : I N G R E S S / G AT E WAY A P I / E N V O Y
🔀 処理経路： Client → 物理LAN (L2でMAC解決) → ノードIP (L4で宛先Pod決定) → アプリ (L7でパス分岐) → Pod
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/V7NY4WYDE8.jpg)

L2-Aware LB — オンプレの「最後の1ホップ」
08THSE TECH STUDY — KUBERNETES LOAD BALANCING
L AY E R 2 — D ATA L I N K
Pod に届ける前に、まず物理ネットワークが 「Service IP は誰のもの？」 を解決する必要が
ある。クラウドはSDNが裏でやってくれるが、 オンプレは自前で解決 が必要。
補足 : A R P とは？
IPアドレスから MAC アドレスを引くプロトコル（IPv4）。
「10.0.0.5 を持っているのは誰？」 → 「私です。MACは aa:bb:cc:..」と返答する仕組み。
IPv6 では NDP (Neighbor Discovery Protocol) が同じ役割。
C I L I U M L 2 A N N O U N C E M E N T S の動作
① リーダーノード選出： 各 Service につき、ARPに応答する「1ノード」を選ぶ
② ARP/NDP応答： External IP / LoadBalancer IP に対する問い合わせに、自身のMACで応
答
③ N/S LB： そのノードがNorth-South LB として動き、内部のPodへ分散
④ フェイルオーバ： リーダー障害時は別ノードが引き継ぐ
L2 (ARP) で広告
同じLAN内ならルータ不要。 小〜中規模のオンプレ向け。
▸ オフィス / 自宅ラボ
L3 (BGP) で広告
ルーター越しに到達可能。 大規模データセンター向け。
▸ E C M P 負荷分散も可能
L2 Pod Announcements
個々のPodにLAN範囲のIPを直接付与し、物理スイッチに広告。 PodがLAN上のホスト
と同等 に見えるモード。
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/YJ9PQXP873.jpg)

iptables vs IPVS — スケール時の課題
08THSE TECH STUDY — KUBERNETES LOAD BALANCING
L AY E R 4 — T R A N S P O R T
どちらも Linux カーネル機能を使った L4 LB だが、 スケール時の挙動が決定的に異なる。
L E G A C Y / D E FA U LT
iptables
IMPROVED L4 LB
IPVS
Service 1つ × Endpoint数 分のルールを Linux Netfilter チェーンに追加。 先頭から順次マッチ
Linux カーネル組み込みの L4 LB専用機能 （IP Virtual Server）。ハッシュテーブル管理＋多彩
ング。
なアルゴリズム。
仕組み： NATテーブルに DNATルールを大量挿入
仕組み： カーネル内ハッシュテーブル参照
VS
アルゴリズム： ランダム probability ベース
アルゴリズム： RR / Least-Conn / SH / DH 他多数
計算量： O(n) リスト走査
計算量： O(1) ハッシュ参照
⚠️ 課題: Service が 数千 → 数万になると、ルール更新で 秒オ
ℹ️ 注意: iptables より高速だが、 付随するルールはやはり
ーダの停止、レイテンシ悪化。
iptables 経由。完全な解決にはならない。
そして登場するのが： eBPF によるカーネル内 L4 LB。次章で詳しく見る。
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/GJ8DG2DZJD.jpg)

08THSE TECH STUDY — KUBERNETES LOAD BALANCING
Cilium と
eBPF / XDP
CHAPTER 04
kube-proxy / iptables を完全置換。
NICドライバ直近で処理する超高速 L4LB の世界へ。
✓ eBPF 入門
✓ XDP L4LB の動作
✓ Maglev / DSR / Passthrough
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/LJLMG2M1ER.jpg)

補足: eBPF と XDP とは何者か
08THSE TECH STUDY — KUBERNETES LOAD BALANCING
KNOWLEDGE REFRESH
パケット処理位置の違い
eBPF
E X T E N D E D B E R K E L E Y PA C K E T F I LT E R
Linux カーネルに サンドボックス内で安全な小さなプログラム を動的に注入できる仕組み。カ
ーネルを再起動・再コンパイルせずに「カーネルを書き換える」ような事ができる。
使われる場所
ネットワーク・セキュリテ
ィ・トレース・観測
代表ツール
Cilium / Falco / Pixie /
Hubble
↑ User Space (App)
↑ Socket Layer
↑ iptables (Netfilter)
遅い
↑ IP/TCP Stack
↑ XDP (eBPF)
最速 ← Cilium
↑ NIC Driver / Hardware
入口
最遅
XDP は 割り込みも skb 確保も発生する前 にパケットに触れる。
XDP
E X P R E S S D ATA PAT H
eBPF を NICドライバの最も早い段階 でフックする仕組み。割り込み・バッファ確保・ファイ
アウォールチェーン すべてをスキップ してパケットを処理できる。
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/47MYQ8Y57W.jpg)

Cilium XDP L4LB の動作 — 4ステップ
08THSE TECH STUDY — KUBERNETES LOAD BALANCING
C I L I U M S TA N D A L O N E X D P L 4 L B
外部パケットがノードのNICに到達した瞬間に始まる、Cilium のパケット処理パイプライン。
XDP Hook
NICドライバに装着された eBPF プログラム
が パケットを最速でインターセプト。
1
Maglev Lookup
consistent hashing でバックエンドPodを
選択。同フローは常に同じPodへ。
2
Encap or DSR
VXLAN/Geneve で カプセル化、または
DSR で対象ノードへ転送。
3
XDP_TX
同じNICから 即TXバウンス。OSネットワー
クスタックを完全バイパス。
4
Maglev Consistent Hashing が効く場面
通常のランダム選択： ノード障害でフェイルオーバすると、新ノードは「失敗ノードのフロー状態」を知らない → コネクション切断
Maglev： すべての LB ノードが 同じ順序のバックエンドテーブル を持つので、フェイルオーバ後も同フローは同Podへ
DSR (Direct Server Return): Pod の応答が LB を経由せず クライアントへ直接戻る。LB の bottleneck 解消。
▸ I P V 4 / I P V 6 D U A L - S TA C K 対応 / K U B E R N E T E S と独立してデプロイも可能
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/P7R9859ZE9.jpg)

L4 LB の動作モード — Passthrough vs Proxy
08THSE TECH STUDY — KUBERNETES LOAD BALANCING
O P E R AT I N G M O D E S
L4 ロードバランサーは、TCPコネクションを 「素通しする」か「終端して張り直す」か の2モードに分類できる。
HIGH PERFORMANCE
HIGH FLEXIBILITY
パケットの中身を見ずに転送。 Client → Backend で1本のTCPコネクションを維持。LBはコ
ネクションを終端しない。
LB が Client 側のコネクションを 終端 し、別途 Backend へ新しいコネクションを張る。 2本の
TCP。
Passthrough Mode
フロー
Client → LB → Backend
Client ← DSR ← Backend
応答は LB を経由せず Backend → Client へ直接
✓ 超低レイテンシ・高スループット
✓ DSR でLB帯域消費を削減
× SSL証明書の終端は不可
Proxy Mode
VS
フロー
Client ⇄ LB (Term) ⇄ Backend
2本のTCPを LB が中継・変換
✓ SSL終端 / リトライ / 認証 が可能
✓ 柔軟なルーティング判断
× レイテンシとCPU負荷が増える
使い分け： XDP L4LB は Passthrough + DSR で最高性能を出し、L7（Ingress / Gateway API）の Envoy が Proxyモード として機能する。 層を分けて両取り するのが Cilium のア
ーキテクチャ。
18


# Page. 19

![Page Image](https://bcdn.docswell.com/page/PJXQ8KQ17X.jpg)

本日のまとめ
08THSE TECH STUDY — KUBERNETES LOAD BALANCING
K E Y TA K E AWAY S
Kubernetes Load Balancing は、 「短命なPod」と「固定された宛先」のギャップを埋める ための仕組み。各レイヤーがそれぞれの役割を持ち、Cilium は eBPF で全層を統合する。
01
02
03
オンプレ・ベアメタルでも Cilium / MetalLB が ARP / BGP
で VIP を広告し、クラウド相当のLB体験を実現。
XDP + eBPF + Maglev + DSR で iptables の限界を突破。 大規
模クラスタでも低レイテンシ を維持。
Gateway API + Envoy + Hubble で アイデンティティ認識の
L7ルーティングと完全な可視性 を提供。
Foundation (L2/L3)
Performance (L4/XDP)
Intelligence (L7/Gateway)
Next Action — 今日からできること
→ 小さく試す： kind / minikube に Cilium を入れて cilium status を眺める
→ 観測する： Hubble UI で East-West / North-South を可視化
→ 置換える： kube-proxy 無効モードで Cilium を導入してみる
→ 読む： Cilium Standalone L4LB ブログ・公式ドキュメント
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/3JK9K59MJD.jpg)

— END OF SESSION —
Thank.
You.
ご清聴ありがとうございました
Questions & Discussion are welcome.
REFERENCES & FURTHER READING
🔗 Original Article (Cilium Blog)
cilium.io/blog/2026/04/25/understanding-kubernetes-load-balancing/
📘 L2 Announcements Docs
docs.cilium.io/en/stable/network/l2-announcements/
⚡ Standalone XDP L4LB
cilium.io/blog/2022/04/12/cilium-standalone-L4LB-XDP/
🔬 eBPF Documentation
ebpf.io / Learning eBPF