第3回 Kubernetesのネットワーク~クラスタ環境でコンテナネットワークを構築する方法~

Twitter
Facebook
Hatena
第3回 Kubernetesのネットワーク~クラスタ環境でコンテナネットワークを構築する方法~

Dockerコンテナネットワーク

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

Dockerにおけるコンテナネットワーク

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のクラスタ環境ではいかにしてネットワークを構築するかを見ていきましょう。

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」について解説します。

【Kubernetes製品群「VMware Tanzu」の実力を探る】コラム一覧

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

 
 

 

 

この記事の執筆者

山本 祥正
山本 祥正Yoshimasa Yamamoto

執行役員
ソリューション事業本部 副本部長

クラウド 仮想化 Vmware Tanzu