Kubernetes Load Balancing について

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

本日お話すること 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

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

なぜロードバランシングが必要か 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

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

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

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

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

内部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

外部からクラスタへ — 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

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

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

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

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

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

補足: 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

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

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

本日のまとめ 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

— 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