コンテナネットワーク（Kubernetes）の通信性能｜CNI・Overlay・Service経由のオーバーヘッド

Kubernetes環境では、Pod間通信やService経由のアクセスなど、 複雑なネットワーク構成が自動的に構築されます。

一方で、その抽象化の裏側では CNI（Container Network Interface）、Overlayネットワーク、 kube-proxyなど複数のコンポーネントが関与しており、 通信性能に影響を与えます。

本記事では、Kubernetesのネットワーク構造と、 スループット・レイテンシへの影響を体系的に整理します。

Kubernetesネットワークの基本要件

Kubernetesでは以下の要件が定義されています。

• Pod間はNATなしで通信可能
• すべてのPodにユニークなIP
• ノードをまたいだ通信可能

この要件を満たすために、CNIプラグインが利用されます。

CNI（Container Network Interface）

CNIは、コンテナのネットワーク設定を管理する仕組みです。

代表的なCNI

• Flannel
• Calico
• Cilium
• Weave

CNIの種類によって通信性能は大きく異なります。

通信パターン別の性能特性

1. 同一ノード内通信

Pod A → veth → bridge → veth → Pod B

カーネル内で処理されるため高速です。

• 低レイテンシ（数μs〜）
• 高スループット

2. ノード間通信（Overlay）

Pod → VXLAN → UDP → 物理ネットワーク

カプセル化によりオーバーヘッドが発生します。

• 追加遅延
• スループット低下（数％〜）

3. Service経由通信

Pod → kube-proxy → iptables/IPVS → Pod

NAT処理やルールマッチングが発生します。

kube-proxyの影響

iptablesモード

• ルール数増加で性能低下
• 大規模環境で遅延増加

IPVSモード

• 高速ロードバランシング
• 大規模環境に適する

Overlay vs Underlay

方式	特徴
Overlay	柔軟・オーバーヘッドあり
Underlay	高速・設計が複雑

eBPFによる最適化

最新のCNI（Ciliumなど）では、 eBPFを利用してカーネルレベルで高速処理を行います。

• iptables回避
• 低レイテンシ
• 高スループット

MTUとフラグメンテーション

Overlay環境ではMTU設定が重要です。

VXLANヘッダ分減少
→ MTU調整必要

不適切な設定は性能低下の原因になります。

スループットへの影響

• カプセル化オーバーヘッド
• CPU処理負荷
• ルーティング複雑化

通常は数％〜20％程度の低下が発生します。

レイテンシへの影響

• Overlay処理：数μs〜ms追加
• Service経由：ルール処理遅延

実務でのボトルネック

ケース1：CNI選択ミス

パフォーマンス差が大きい。

ケース2：iptables肥大化

ルール処理遅延。

ケース3：MTU不一致

フラグメンテーション発生。

最適化ポイント

• IPVSモード使用
• eBPFベースCNI採用
• Jumbo Frame設定
• トラフィック設計の見直し

よくある誤解

Kubernetesは遅い

→ 設計次第で高速。

Overlayは必須

→ Underlay構成も可能。

CNIはどれでも同じ

→ 性能差が大きい。

まとめ

Kubernetesのネットワーク性能は、 CNI、Overlay、Service処理など複数の要素に依存します。

同一ノード通信は高速ですが、 ノード間通信やService経由ではオーバーヘッドが発生します。

eBPFやIPVSなどの最適化技術を活用することで、 高性能なネットワークを実現できます。

適切な設計とチューニングが、 Kubernetes環境における性能確保の鍵となります。