レッスン 14: Kubernetes ネットワーク モデル

🎯 レッスンの目的

基本から高度な Kubernetes ネットワーク モデルを理解します。各ポッドが独自の IP を持つ理由、4 種類の通信パターン、CNI プラグイン (Cilium 2026 推奨)、nftable を使用した kube-proxy です。

1. Kubernetes ネットワーク要件

Kubernetes には 3 つの主要なネットワーク要件があります:

• すべてのポッドはクラスター内の他のすべてのポッドと通信できる必要があります__HTMLTAG_11___NAT は必要ありません___HTMLTAG_12__HTMLTAG_13___
• すべてのノードがすべてのポッドと通信できる必要がある__HTMLTAG_15___NAT は不要___HTMLTAG_16__HTMLTAG_17___
• _ポッド自体が認識する IP は、他のポッドが認識する IP と同じである必要があります__HTMLTAG_19___

これは、デフォルトの Docker (NAT ベース) とは異なり、「フラット ネットワーク モデル」です。

2. 4 つのコミュニケーション パターン

2.1 コンテナ間 (同じポッド内)

同じポッド内のコンテナはネットワーク名前空間を共有します → localhost.

経由で通信します ___コードブロック_0___

2.2 ポッド間

各ポッドにはクラスター内の個別の IP があります。ポッドは IP 経由で直接通信します — CNI プラグインによりルーティングが保証されます。

___コードブロック_1___

2.3 ポッドからサービス

ポッドは、ClusterIP (仮想 IP) を介してサービスと通信します。 kube-proxy は、実際の Pod IP への DNAT (宛先 NAT) への iptables/nftables ルールを作成します。

___コードブロック_2___

2.4 外部からサービス

NodePort、LoadBalancer、または Gateway API (HTTPRoute) を介したクラスターの外部からサービスへのトラフィック。

3. CNI (コンテナ ネットワーク インターフェイス)

CNI は、Kubernetes とネットワーク プラグイン間の標準インターフェイスです。ポッドが作成されると、kubelet は CNI プラグインを呼び出して次のようにします。

• Pod のネットワーク インターフェイスを作成
• IP アドレスの割り当て_
• ルーティング構成

3.1 Cilium — 2026 年推奨

Cilium はカーネル レベルで eBPF (拡張バークレー パケット フィルター) を使用します。iptables チェーンは必要ありません。

Cilium の利点:

• eBPF: 高速でプログラム可能なカーネルレベルのネットワーキング
• L7 の可視性と負荷分散 (HTTP、gRPC、Kafka)
• __HTMLTAG_71___Hubble による組み込みの可観測性 (リアルタイム ネットワーク トラフィック)
• ネイティブ ゲートウェイ API の実装
• サイドカーレス サービス メッシュ (Envoy サイドカーは不要)
• _ネットワーク ポリシー: L3/L4/L7

___コードブロック_3___

3.2 キャリコ

Calico は、eBPF データプレーンのサポート (オプション)、ベアメタル用の BGP ルーティングを備えた成熟した CNI です。物理ルーターとの広範な互換性または BGP ピアリングが必要な場合に適しています。

3.3 フランネル

Flannel はシンプルでインストールが簡単ですが、__HTMLTAG_88___ネットワーク ポリシーのサポートと可観測性 が不足しています。運用環境には推奨されません。

4. eBPF — iptables より速いのはなぜですか?

iptables は、線形ルール マッチング (n ルールで O(n)) を使用します。クラスターに何千ものサービスがある場合、iptables チェーンは非常に長くなり、パフォーマンスに影響します。

eBPF はハッシュ マップを使用します。サービスの数に関係なく、O(1) ルックアップです。 eBPF プログラムは、ユーザー空間へのコンテキスト切り替えを行わずに、カーネル内で直接実行されます。

___コードブロック_4___

5. kube-proxy モード 2026

kube-proxy は、各ノードでサービスの負荷分散を実装します。

5.1 iptables モード (レガシー)

_サービス エンドポイントごとに iptables DNAT ルールを作成します。まだ動作しますが、スケーラビリティが低下します。

5.2 nftables モード — 2026 年推奨

IPVS モードは K8s 1.35 で非推奨になりました。 nftables は新しいバックエンドで、iptables よりも効率的です。

___コードブロック_5___ ___コードブロック_6___

6. CoreDNS

を使用した DNS

CoreDNS は Kubernetes のデフォルトの DNS サーバーであり、__HTMLTAG_114___kube-system.

でデプロイメントとして実行されます。 ___コードブロック_7___

7。ネットワーク図

___コードブロック_8___

概要

• Kubernetes フラット ネットワーク: 各ポッドには独自の IP があり、NAT はありません
• 4 パターン: コンテナ間 (localhost)、ポッド間 (直接 IP)、ポッドからサービス (ClusterIP + kube-proxy)、外部からサービス (NodePort/ゲートウェイ API)
• Cilium eBPF: CNI 推奨 2026 — 高速、L7 可観測性、ネイティブ API ゲートウェイ
• kube-proxy nftables: IPVS を置き換えます (非推奨の K8s 1.35)
• CoreDNS: DNS 名によるサービス検出