Docker や Kubernetes のネットワークを理解しようとすると、veth、Linux bridge、network namespace という用語がすぐに出てきます。これらはコンテナランタイム固有の部品ではなく、Linux が持つネットワーク分離と仮想接続の仕組みです。
前回整理した macvlan / ipvlan は、親インターフェースから L2 または L3 の接続点を作り、コンテナを物理ネットワークへ近い形で参加させる技術でした。一方、一般的なコンテナネットワークでは、まず network namespace でネットワーク空間を分け、その間を veth ペアで接続し、ホスト側では Linux bridge に収容します。
本記事では、veth と Linux bridge が何を分離し、何を接続しているのかを、CNI や Docker の bridge ネットワークまでつながる形で整理します。
network namespace はネットワーク空間を分ける
network namespace は、Linux 上でネットワークスタックを分離する仕組みです。namespace ごとにネットワークインターフェース、IP アドレス、ルーティングテーブル、ARP / NDP テーブル、ソケット、iptables / nftables の見え方などが分かれます。
| 分離されるもの | 意味 |
|---|---|
| インターフェース | namespace ごとに見える NIC が異なる |
| IP アドレス | 同じホスト上でも別の namespace なら別の IP 設計を持てる |
| ルーティングテーブル | 宛先ごとの転送判断を namespace ごとに分けられる |
| ARP / NDP | L2 隣接情報を namespace ごとに分離できる |
| ソケット | プロセスが属する namespace のネットワークだけを使う |
ただし、network namespace は分離するだけです。分離した namespace が外部と通信するには、どこかに接続点が必要です。その接続点として頻繁に使われるのが veth ペアです。
veth は namespace 間をつなぐ仮想ケーブル
veth は Virtual Ethernet device の略で、2 つのインターフェースがペアになって動作する仮想ネットワークデバイスです。片方へ入ったパケットは、もう片方から出てきます。物理的なケーブルで 2 つの NIC を直結したような関係を、Linux カーネル内で作る仕組みだと考えると分かりやすいです。
コンテナで使う場合、veth ペアの片方をコンテナ側の network namespace に移動し、もう片方をホスト側に残します。コンテナから見ると、自分専用の NIC が 1 つ存在するように見えます。ホストから見ると、そのコンテナへつながるケーブルの反対側が見えます。
| veth の片側 | 置かれる場所 | 役割 |
|---|---|---|
| コンテナ側 veth | コンテナの network namespace | コンテナが使う NIC として見える |
| ホスト側 veth | ホストの network namespace | bridge やルーティングへ接続する出口になる |
ここで大事なのは、veth 自体はスイッチではないという点です。veth は 2 点を結ぶ仮想ケーブルであり、複数のコンテナをまとめて収容したり、L2 セグメントを作ったりする役割は持ちません。複数の veth を集約するために Linux bridge が使われます。
Linux 上では、概念的には次のようなコマンドで veth ペアを作成できます。これは説明用の最小例であり、実運用では namespace 作成、IP アドレス、経路、bridge 接続、NAT やフィルタリングを合わせて設計します。
ip link add veth-host type veth peer name veth-container
ip link set veth-container netns container-nsLinux bridge はホスト内の仮想スイッチ
Linux bridge は、ホスト内で複数のインターフェースを L2 的に接続する仮想スイッチです。複数のホスト側 veth を bridge に接続すると、コンテナ同士が同じ L2 セグメントにいるように通信できます。
| 構成要素 | 役割 |
|---|---|
| Linux bridge | ホスト内の仮想スイッチ |
| ホスト側 veth | 各コンテナから bridge へつながるポート |
| コンテナ側 veth | コンテナ内の NIC |
| 物理 NIC | 必要に応じて外部ネットワークへ出る出口 |
bridge は MAC アドレスを学習し、宛先 MAC アドレスに応じてフレームを転送します。この点では物理スイッチに近い動作をします。ただし、Linux bridge はホスト内のソフトウェア機能です。物理スイッチのように見えても、実体は Linux カーネル内のブリッジング機能です。
Docker の bridge ネットワークや CNI の bridge プラグインは、この考え方を利用します。コンテナごとに veth ペアを作り、ホスト側を bridge へ接続し、コンテナ側を個別の network namespace へ入れることで、複数のコンテナを同じ仮想 L2 ネットワークに収容します。
veth と bridge は役割が違う
veth と bridge は一緒に登場するため混同されがちですが、役割は明確に異なります。veth は 2 点間の接続を作る部品であり、bridge は複数の接続点を集約する部品です。
| 要素 | 何をするか | 何をしないか |
|---|---|---|
| network namespace | ネットワーク空間を分離する | 外部との接続は作らない |
| veth | 2 つのネットワーク空間を 1 対 1 で接続する | 複数ポートを集約しない |
| Linux bridge | 複数の veth や NIC を L2 的に接続する | namespace 自体を分離しない |
| ルーティング | L3 で経路を選ぶ | L2 セグメントを作るわけではない |
この分担を誤ると、コンテナネットワークの問題を見たときに原因の切り分けが難しくなります。コンテナ内にインターフェースが見えないのか、veth ペアが切れているのか、bridge に接続されていないのか、bridge から外部へ出る経路や NAT がないのかでは、調べる場所が違います。
bridge 構成では通信がどこを通るのか
一般的な bridge 構成では、コンテナから外部へ出る通信は、コンテナ側 veth、ホスト側 veth、Linux bridge、ホスト側のルーティングまたは NAT、物理 NIC という順に進みます。コンテナ同士が同じ bridge に接続されている場合は、bridge 内で L2 転送され、物理 NIC まで出ないこともあります。
- コンテナ内のアプリケーションがパケットを送信する。
- コンテナ側 veth からホスト側 veth へパケットが渡る。
- ホスト側 veth が Linux bridge のポートとして扱われる。
- bridge が宛先 MAC アドレスに基づいて転送先を決める。
- 外部宛てであれば、ホスト側のルーティング、NAT、フィルタリングを経由して物理 NIC へ出る。
この構造では、コンテナは物理ネットワークへ直接ぶら下がっているわけではありません。ホスト内の仮想 L2 ネットワークに収容され、必要に応じてホストが外部ネットワークとの境界になります。ここが macvlan / ipvlan と大きく異なる点です。
書籍
Linux ネットワーク namespace / bridge / veth 関連資料を探す
Linux の network namespace、仮想ネットワーク、CNI、コンテナネットワークを確認したい場合の検索リンクです。価格、在庫、内容はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
CNI bridge プラグインは何を自動化するのか
CNI の bridge プラグインは、コンテナを Linux bridge へ接続する処理を自動化します。CNI はコンテナランタイムから呼び出され、指定された network namespace に対してインターフェース作成、bridge 接続、IP アドレス設定などを行います。処理の流れは、概念的には次のように整理できます。
- ホスト側に Linux bridge を用意する。
- コンテナ用の veth ペアを作成する。
- 片方をコンテナの network namespace に移動する。
- もう片方を Linux bridge に接続する。
- IPAM によって IP アドレスを割り当てる。
- 必要に応じてルーティング、NAT、hairpin、フィルタリングを設定する。
CNI bridge プラグインは、Linux bridge というデータプレーンを新しく発明しているわけではありません。Linux の既存機能を、コンテナ作成と削除のライフサイクルに合わせて呼び出していると見る方が正確です。
Docker bridge ネットワークとの関係
Docker の bridge ネットワークも、基本的には同じ考え方に立っています。Docker デーモンは bridge ネットワークを作成し、コンテナごとに veth ペアを用意し、ホスト側を bridge へ接続します。デフォルトの bridge ネットワークでは、外部通信のために IP マスカレードやポート公開の仕組みも関係します。
ただし、Docker の bridge ネットワークと Kubernetes の CNI bridge 構成は、管理主体や設定モデルが異なります。Docker では Docker デーモンがネットワークを管理します。Kubernetes では kubelet とコンテナランタイムが CNI プラグインを呼び出し、クラスタの Pod ネットワークとして構成します。どちらも Linux の同じ部品を使うことがありますが、運用上の責任分界は同じではありません。
macvlan / ipvlan との違い
veth + bridge 構成と macvlan / ipvlan 構成は、どちらもコンテナにネットワークインターフェースを見せます。しかし、物理ネットワークからの見え方が異なります。
| 方式 | コンテナからの見え方 | 物理ネットワークからの見え方 | 主な設計意図 |
|---|---|---|---|
| veth + bridge | 専用 NIC があるように見える | ホスト配下の仮想ネットワーク | ホスト内でコンテナを集約し、必要に応じて外部へ出す |
| macvlan | 専用 NIC があるように見える | 複数 MAC アドレスを持つ端末群 | 既存 L2 ネットワークへ端末として直接収容する |
| ipvlan | 専用 NIC があるように見える | 共通 MAC に複数 IP がぶら下がる | MAC 数を抑えつつ IP 単位で接続点を分ける |
bridge 構成は、ホスト内に仮想的な L2 セグメントを作り、コンテナをそこへ収容する考え方です。macvlan / ipvlan は、親インターフェースを起点に、コンテナを物理ネットワークへより直接的に見せる考え方です。どちらが上位互換という話ではなく、何を分離し、どこを境界にするかが違います。
障害解析ではどこを見るべきか
veth と bridge の役割を分けて理解しておくと、障害解析の入口が明確になります。コンテナ内で IP アドレスがない場合、まず container 側の namespace と CNI / IPAM を見ます。ホスト側 veth が bridge に接続されていない場合は、CNI 実行や bridge 設定を見ます。コンテナ同士は通信できるが外部へ出られない場合は、ホスト側のルーティング、NAT、フィルタリング、物理 NIC 側を確認します。
| 症状 | 主に見る場所 |
|---|---|
| コンテナ内にインターフェースがない | network namespace、CNI 実行結果、veth 作成 |
| コンテナ内に IP アドレスがない | IPAM、CNI 設定、アドレスプール |
| 同一ホスト内のコンテナ同士が通信できない | veth、Linux bridge、bridge のポート状態 |
| 外部へ出られない | ホストのルーティング、NAT、フィルタリング、物理 NIC |
| 外部から入れない | ポート公開、Service、Node 側の経路、ファイアウォール |
コンテナネットワークの問題は、すぐに Kubernetes や Docker の設定だけに見えてしまいます。しかし下には Linux の network namespace、veth、bridge、ルーティング、フィルタリングがあり、どの層で止まっているかを分けて見る必要があります。
まとめ
veth と Linux bridge は、コンテナネットワークの基本を支える Linux の部品です。network namespace はネットワーク空間を分け、veth は分離された空間どうしを 1 対 1 で接続し、Linux bridge は複数の veth をホスト内の L2 ネットワークとして集約します。
Docker の bridge ネットワークや CNI bridge プラグインは、この組み合わせをコンテナのライフサイクルに合わせて自動化しています。したがって、veth や bridge を理解することは、Docker や Kubernetes の表面的な設定を覚えることとは別の意味を持ちます。どこで分離し、どこで接続し、どこから物理ネットワークへ出すのかを理解するための土台になります。
macvlan / ipvlan が物理ネットワークへの見せ方を変える技術だとすれば、veth + bridge はホスト内でコンテナをどう収容するかを決める基本構造です。この違いを押さえておくと、CNI の選定、Multus の利用、NetworkPolicy、ホスト側ファイアウォール、物理ネットワークとの責任分界を考えやすくなります。
参考資料
- network_namespaces(7) – Linux manual page
- veth(4) – Linux manual page
- Linux Kernel Documentation – Bridge
- CNI Plugins – bridge
- Docker Docs – Bridge network driver
- Kubernetes Documentation – Network Plugins
関連記事
macvlan / ipvlan はコンテナのための技術なのか – Linux ネットワーク仮想化から CNI まで整理する
BUFFALO BHR-4RV VPN ルーターを今どう見るか – PPTP 時代の自宅ネットワーク機器を読み替える
VXLAN と Geneve の違い – L2 延伸だけでは見えない設計と責任分界
DD-WRT の導入検討
IPv6/IPv4 デュアルスタックのインターネット接続を OSS で作る – NAT66 以前の試行錯誤
光 BB ユニットに感じる抵抗感 – ISP 提供ルーターと自宅ネットワーク設計の自由度
Palo Alto GlobalProtect のゼロデイ脆弱性 CVE-2024-3400
IPv6 における NAT66 再考 – ULA、GUA、Prefix 設計主権、IPv4 NAT の設計抽象