🗺️
概念 #Kubernetes #ネットワーク #CNI #BGP #VXLAN #eBPF #前提知識 📚 Kubernetesセキュリティ

K8sを理解するための前提ネットワーク知識

VXLAN・BGP・CNI・eBPF・IPAMなど、Kubernetesを読む前に知っておくべきネットワーク概念・用語を体系的に整理。

この記事の目的

K8sのドキュメントや構成図には、前提なしでは意味を取りにくいネットワーク用語が頻出する。 「CNIって何？」「BGPが出てきたけどルーターの話？」という状態でK8sを学ぶと、表面的な操作は覚えられても「なぜそうなっているか」が見えない。

ここでは K8s を理解する前に押さえておくべきネットワーク概念を、K8s文脈と結びつけながら整理する。

L2 と L3：スイッチとルーターの違い

K8sのCNI選択を理解するうえで最も重要な基礎。

L2（データリンク層）= 同じネットワーク内の転送
  識別子：MACアドレス
  機器：スイッチ
  範囲：同一セグメント（ブロードキャストが届く範囲）
  例：社内LAN、同じVPC内のサブネット

L3（ネットワーク層）= 異なるネットワーク間の転送
  識別子：IPアドレス
  機器：ルーター
  範囲：インターネット全体
  例：東京オフィス → 大阪オフィス、異なるVPC間

K8s との関係： CNIプラグインによって「Node間のPod通信をL2で解決するか（VXLAN）L3で解決するか（BGP）」が変わる。L2方式はシンプルだがスケールに限界がある。L3方式はルーティング設定が必要だが大規模環境に強い。

Overlay と Underlay：ネットワークの2層構造

Underlay ネットワーク = 物理・実際のネットワーク
  （クラウドのVPC、データセンターのスイッチ/ルーター）
  → ノードのIPアドレス（例：192.168.1.10, 192.168.1.20）

Overlay ネットワーク = Underlayの上に仮想的に作るネットワーク
  （トンネリングで実現）
  → PodのIPアドレス（例：10.244.0.2, 10.244.1.5）

  Node A (192.168.1.10)
    Pod A: 10.244.0.2
         ↓ UDPでラップして送る（カプセル化）
  ─────────────────── Underlay（物理ネットワーク）───
         ↓ 受信してデカプセル化
  Node B (192.168.1.20)
    Pod B: 10.244.1.5

K8s との関係： K8sはデフォルトでPodが独自のIPアドレス空間を持つ（Overlay）。Underlayのネットワーク設計を変えずにK8sを動かせるのはこのため。ただしオーバーヘッドが生じる。

VXLAN：L2をUDPでトンネリングする

VXLANはEthernetフレームをUDPパケットの中に包んで送る技術。

【VXLANのカプセル化】

元パケット（Pod間通信）：
  src: 10.244.0.2  dst: 10.244.1.5

VXLANでラップ後（Node間転送）：
  外側: src: 192.168.1.10  dst: 192.168.1.20  (UDP:4789)
  内側: 元パケットがそのまま入っている

VTEP（VXLAN Tunnel End Point）：
  カプセル化・デカプセル化を行う仮想NIC
  K8sでは flannel.1 や cilium_vxlan がこれに相当

特徴：

  • Underlayが単純なL3ネットワークでも動く（物理ネットワークの設定変更不要）
  • 24ビットのVNI（VXLAN Network Identifier）で最大1677万のセグメントを識別
  • オーバーヘッド：約50バイト追加 → MTUを1450バイト程度に下げる必要がある

K8s との関係： FlanelのデフォルトモードがVXLAN。Calicoも設定次第でVXLANを使う。

BGP：ルーター間での経路情報の交換

BGP（Border Gateway Protocol）はルーター同士が「このIPアドレス範囲への経路は私経由で到達できる」と伝え合うプロトコル。インターネットのバックボーンを支えている。

【BGPによる経路広告のイメージ】

Node A (192.168.1.10) に Pod CIDR 10.244.0.0/24 が割り当てられている
Node B (192.168.1.20) に Pod CIDR 10.244.1.0/24 が割り当てられている

BGP ピアリング後：
  Node A → Node B: 「10.244.0.0/24 は俺経由で到達できる」
  Node B → Node A: 「10.244.1.0/24 は俺経由で到達できる」

Node A からPod B (10.244.1.5) に送る場合：
  ルーティングテーブルに「10.244.1.0/24 → 192.168.1.20 経由」が登録済み
  → カプセル化なしで直接Nodeに届く

eBGP vs iBGP：

  • eBGP（External）：異なるAS（自律システム）間。ISP間、クラウドとオンプレ接続
  • iBGP（Internal）：同一AS内。データセンター内のルーター間

K8s との関係： CalicoはデフォルトでeBGPを使い、各Nodeをルーターとして動作させる。VXLANより高パフォーマンスだが、物理ネットワークがBGPを通す設定が必要（クラウド環境では注意）。

CNI：K8sがネットワーク実装を差し替える仕組み

CNI（Container Network Interface）はK8sとネットワーク実装をつなぐインターフェース仕様。

K8s（kubelets）
    │
    │ 「このPodのネットワークをセットアップして」
    ↓ （CNI仕様に従った呼び出し）
CNIプラグイン（Flannel / Calico / Cilium / Weave...）
    │
    │ veth pair の作成・IPアドレスの割り当て・ルーティング設定
    ↓
Pod のネットワーク完成

CNIはJSON設定ファイルとバイナリで構成される。K8sは「Podを作るときにCNIを呼ぶ」だけで、実装は何でも良い。

# CNIの設定ファイル（Nodeの /etc/cni/net.d/ に置かれる）
{
  "cniVersion": "0.4.0",
  "name": "k8s-pod-network",
  "type": "calico",
  "ipam": {
    "type": "calico-ipam"
  }
}

K8s との関係： CNIを理解すると「なぜCNIプラグインを変えるとNetworkPolicyの実装が変わるか」「なぜFlannelにはNetworkPolicyがないか」が分かる。

IPAM：IPアドレスの管理方式

IPAM（IP Address Management）はPodにIPアドレスを割り当てる仕組み。

K8sのIPアドレス空間：

  Node CIDR:    192.168.0.0/16  （Nodeが持つIPアドレス）
  Cluster CIDR: 10.244.0.0/16   （Pod全体のIPアドレス空間）
  Service CIDR: 10.96.0.0/12    （ServiceのVIPアドレス空間）

Node ごとに Pod CIDR のスライスが割り当てられる：
  Node A: 10.244.0.0/24  → Pod A: 10.244.0.2, Pod B: 10.244.0.3
  Node B: 10.244.1.0/24  → Pod C: 10.244.1.2, Pod D: 10.244.1.3

主なIPAM方式：

方式説明使用例
host-localNodeごとのサブネットから割り当てFlannel, Calico(デフォルト)
calico-ipamCalicoが中央管理でIPを割り当てCalico
AWS VPC CNIPodがVPCのIPを直接持つEKSのデフォルト
Cilium IPAMeBPFベースの高度な割り当てCilium

AWS VPC CNIが特殊な理由： PodがNodeと同じVPCのIPアドレスを持つため、Security GroupをPod単位で設定できる。VPC Flow Logsで直接Pod通信が見える。オーバーレイが不要になるが、NodeのENI数に引っ張られてPod数が制限される。

Network Namespace：プロセスのネットワーク隔離

LinuxカーネルのNetwork Namespaceは「独立したネットワークスタック」を作る仕組み。

ホスト（デフォルトNamespace）
  eth0: 192.168.1.10
  lo:   127.0.0.1
  ルーティングテーブル A
  iptables A

Pod（独自のNamespace）
  eth0: 10.244.0.2  ← veth pair でホストと接続
  lo:   127.0.0.1
  ルーティングテーブル B
  iptables B        ← ホストのiptablesとは完全に独立

各Namespaceは独立した ip addr・ip route・iptables を持つ。コンテナが「自分専用のネットワーク」を持てるのはこの仕組みのおかげ。

確認コマンド：

# ホスト上のNetwork Namespace一覧（Pod名で表示されないが存在する）
ip netns list

# NodeでPodのNetns内でコマンドを実行（デバッグ）
# Pod のPID を取得してから
nsenter -t <PID> -n ip addr

veth pair：Namespace間の仮想ケーブル

veth（Virtual Ethernet）は必ず2つセットで作られる仮想NIC。片方に入れると必ずもう片方から出る。

Pod Namespace                   Host Namespace
┌──────────────┐               ┌──────────────────┐
│  eth0        │◄══════════════►│  veth_abc123     │
│  (PodのIP)   │   仮想ケーブル  │  (bridgeに接続)  │
└──────────────┘               └──────────────────┘

Pod→外部への通信：
  Pod eth0 → veth_abc123 → bridge(cni0) → ホストのルーティング → 外部
# veth pairの追跡（コンテナのeth0がホスト側で何番か）
# Pod内で
cat /sys/class/net/eth0/iflink  # 例: 14 と表示

# ホスト上で
ip link | grep "^14:"  # index 14 の veth を特定

iptables / netfilter：カーネルのパケットフィルタリング

Linuxカーネルのnetfilterフレームワークをユーザーランドから操作するツールがiptables。

パケットの通過ポイント（Hook）：

受信 ─→ PREROUTING ─→ ルーティング決定 ─→ INPUT ─→ プロセス
                              │
                              └─→ FORWARD ─→ POSTROUTING ─→ 送信

iptables はこれらのHookにルールを挿入する

K8sでの主な使われ方：
  PREROUTING(NAT): Service IP → Pod IP への DNAT（kube-proxy が設定）
  POSTROUTING(NAT): Pod IP → Node IP への MASQUERADE（外部通信時）
  FORWARD: Pod間転送の許可/拒否（NetworkPolicyの実装）
# kube-proxyが作るServiceのDNATルールを確認
iptables -t nat -L KUBE-SERVICES -n
iptables -t nat -L KUBE-SVC-<hash> -n  # 特定Serviceのルール

K8sとの関係： kube-proxyのiptablesモードはServiceごとにiptablesルールを生成する。Serviceが数千になるとルール数が爆増してO(n)の性能劣化が起きる。これを解決するのがIPVSモードとCiliumのeBPF置き換え。

eBPF：カーネルを安全に拡張する仕組み

eBPF（extended Berkeley Packet Filter）はカーネルモジュールを書かずにカーネルの動作を拡張できるサンドボックス機構。

従来のアプローチ：
  カーネルモジュール → バグがあるとカーネルパニック（危険）

eBPFのアプローチ：
  eBPFプログラム → Verifierが事前検証 → 安全なら動的にカーネルに注入
                                         バグがあっても隔離される

【ネットワークでの使われ方】
  XDP（eXpress Data Path）：NICドライバレベルで動作。最高速
  TC（Traffic Control）：NICとネットワークスタックの間
  Socket filter：ソケット操作のフック
  kprobe/tracepoint：カーネル関数呼び出しの監視

K8sとの関係： Ciliumはiptablesを完全にeBPFで置き換え、kube-proxyも不要にできる。ネットワークポリシーの適用がO(1)になる。またHubble（Ciliumの可観測性ツール）はeBPFでPod間の全通信を監視できる。

まとめ：K8s用語との対応表

K8sで見かける用語        前提となるネットワーク概念
──────────────────────────────────────────────────
CNI plugin            CNI仕様 + Overlay/Underlay + IPAM
flannel / calico      VXLAN（Flannel）/ BGP（Calico）
cilium                eBPF + XDP
Pod CIDR / Cluster CIDR   IPAM + サブネット設計
NetworkPolicy         iptables / eBPF のフィルタリング
kube-proxy            iptables DNAT / IPVS
Service（ClusterIP）  仮想IP + NAT
VTEP                  VXLANのトンネル終端点
veth pair             Network Namespace間の接続

各概念が K8s のどの動作に対応しているかが見えてくると、 「なぜこのCNIを選ぶのか」「なぜこの設定が必要なのか」が芋づる式に理解できるようになる。

📚 Kubernetesセキュリティ 13件
  1. 1. 🗺️K8sを理解するための前提ネットワーク知識
  2. 2. 🕸️Kubernetesネットワーク全体図
  3. 3. ⚔️K8s vs ECS：設計思想とアナロジーで理解する
  4. 4. 📋Kubernetesマニフェスト読解ガイド
  5. 5. 🏗️K8s・ECSのIaC管理（Terraform・Helm・GitOps）
  6. 6. ⎈Kubernetes セキュリティ概要・脅威モデル
  7. 7. 🎫Kubernetes RBAC・ServiceAccount
  8. 8. 🛡️Pod Security・SecurityContext
  9. 9. 🔌Kubernetes NetworkPolicy
  10. 10. 🗝️Kubernetes Secrets 管理
  11. 11. 🔗Kubernetes サプライチェーンセキュリティ
  12. 12. 👁️Kubernetes ランタイムセキュリティ（Falco・eBPF）
  13. 13. 📋Kubernetes 監査ログ・SIEM 連携・CIS Benchmark