Dockerコンテナネットワーク

Kubernetesコンテナネットワークに焦点を当てる前に、Dockerコンテナネットワークの構成を整理しましょう。
※ここでは、もっともスタンダードなBridge形式について説明します。

Dockerネットワークを構成する、4つの重要な技術

Dockerのネットワーク構成を知るうえで、欠かせない4つの技術が存在します。

仮想ブリッジ

Dockerコンテナ同士をつなぐための仮想的なブリッジです。物理L2スイッチと同じ振る舞いをします。Dockerの場合、「docker0」という名前で登場します。

veth

vethはVirtual Ethernet Deviceの略、つまり仮想ネットワークインターフェース（仮想NIC）のことです。vethは必ずペア（veth、veth peer）で作成され、ペア間で通信が可能です。

Network Namespace（netns、ネットワーク名前空間）

Linuxは、カーネルが扱うリソースを独立した単位でまとめて、OSから隔離させる機能を擁しています。（つまり、コンテナをOSから隔離させるために必要な技術です）この機能をNetwork Namespace（netns）と呼びます。分離されたリソースは、同一のnetnsに属するプロセス以外からは直接見えません。

iptables

Linuxのパケットフィルターです。ファイアウォール、NAT（SNAT、DNAT、Masquerade）等の機能が提供されます。

同一ホスト上でのコンテナ間通信は、上記の技術から実現される

2つのvethペアそれぞれにおいて、片方のvethを作成したnetnsに組み込み、もう片方を仮想ブリッジ側のインターフェースとすることで、2vethペアでnetns同士（ひいてはコンテナ同士）をつなぐことができます。ちなみに、コンテナ内からは、vethは「eth0」という名前の仮想NICとして見えます。

ホスト外部との通信にはNATが必要

コンテナがホスト外部と通信する場合には、iptablesによる「NAT（グローバルIPアドレスとプライベートIPアドレスを変換する仕組み）」が利用されています。

Kubernetesコンテナネットワーク

Dockerコンテナネットワークを踏まえたうえで、Kubernetesのクラスタ環境ではいかにしてネットワークを構築するかを見ていきましょう。

オーバーレイネットワークが採用されたPod間通信

Kubernetes環境下の場合、基本的にクラスタ環境が構築されます。そのため、Kubernetesが扱う最小単位であるPod（1つ、あるいは複数のコンテナで構成される単位）間の通信に課題が残ります。

各PodにはIPアドレスが割り振られますが、Pod同士の通信が可能なのは同一Node内のみであって、そのままのIPアドレスでNodeをまたいだ通信を行うのは困難です。Dockerでは、コンテナとホスト外部の通信にはNATが利用されます。しかし、たとえばAP用ホストとDB用ホストを分ける場合など、毎回NATテーブルを操作するのは、管理の面から見て現実的ではありません。

そこで採用されるのが、VXLAN技術による「オーバーレイネットワーク」です。オーバーレイネットワークとは、一言でいえば、あるネットワークの上に構築された別のネットワークを指します。Pod間通信においては、以下のような流れでオーバーレイネットワークを介して、各Podが連携されていきます。

　①Podからパケットが送信される
　②送信されたパケットは、Node内のブリッジを経由してLinuxカーネルでカプセル化。オーバーレイネットワークを経由して、宛先Nodeに向かう
　③宛先Node内にてカプセル化が解除され、受信側のPodにパケットが届く

このように、Node間でオーバーレイネットワークを構成することで、クラスタ環境におけるPod間通信を実現させています。

CNIに対応することで、より効率よくコンテナネットワークを構築する

CNIとは

CNI（Container Network Interface）とは、コンテナネットワークをより簡単に構築するためのAPIインターフェースです。

Kubernetesネットワークモデルを実装するための、さまざまなアプローチ

Kubernetesのネットワークを実装するには、いくつかの要件があります。

・ノード上のポッドは、NATなしですべてのノード上のすべてのポッドと通信できます。
・ノード上のエージェント（システムデーモン、kubeletなど）は、そのノード上のすべてのポッドと通信できます。
・ノードのホストネットワーク内のポッドは、NATなしですべてのノード上のすべてのポッドと通信できます

※引用：Kubernetes／クラスターネットワーキング「Kubernetesネットワークモデル」

Kubernetesネットワークモデル実装を成功させるのが、前述のオーバーレイネットワークを始めとしたさまざまな技術ですが、実装するためのプロダクトは、実は多数あります。（※）代表的なものでいえば、オーバーレイネットワークを採用するFlannelや、そのほかCalicoなどが挙げられます。ただし、これらのプロダクトはKubernetesネットワークを構築するために誕生したものではありません。もともと存在していたもので、Kubernetes側で必要に応じて各プロダクトを許容することで、要件を満たしたネットワークを構築することができます。

※参考：Kubernetes／クラスターネットワーキング「Kubernetesネットワーキングモデルを実装する方法」

CNIによって、各プロダクトによるコンテナネットワーク実装が実現される

しかし、数多く存在するプロダクトすべてに一つ一つ対応していくのは、非効率です。そこで、共通のインターフェースやプラグインを準備することで、コンテナネットワーク実装の簡素化を実現させています。そのインターフェースこそ「CNI」であり、Kubernetesに標準実装されているものです。

CNIを介してさまざまなKubernetesベンダーソリューションが誕生していますが、VMwareにおいても例外ではありません。次回は、VMwareのKubernetes関連製品群である「VMware Tanzu」について解説します。

富士ソフト　VMware 仮想化ソリューションのご紹介

　
　

 

 

この記事の執筆者