図解でわかるKubernetesのネットワーキング【第2回】

Kubernetesネットワークから私が学んだこと

今回は、Kubernetesのネットワーキングについてのシリーズの第2弾です。まだパート1を読んでいない方は、まずそちらをご覧になることをお勧めします。

前回までのシリーズでは、Kubernetesのネットワーキングモデルについて説明しました。パケットが同一ノード上のポッドやノード間をどのように流れるかを観察しました。また、linuxのネットワークブリッジとルートテーブルがこのプロセスで果たす役割についても説明しました。

今回は、これらのアイデアを発展させ、オーバーレイネットワークがどのように機能するかを見てみましょう。また、刻々と変化するポッドが、Kubernetesで動作するアプリから抽象化され、舞台裏でどのように処理されるかを見てきたいと思います。

Overlay networks

オーバーレイネットワークはデフォルトでは必要ありませんが、特定の状況では役に立ちます。例えば、十分なIPスペースがない場合や、ネットワークが余分なルートを処理できない場合などです。また、オーバーレイが提供する管理機能が必要な場合もあります。よくあるケースとしては、クラウド事業者のルートテーブルが扱えるルート数に制限がある場合です。例えば、AWSのルートテーブルでは、ネットワークのパフォーマンスに影響を与えることなく最大50のルートに対応しています。そのため、50台以上のKubernetesノードがある場合、AWSのルートテーブルでは足りません。このような場合、オーバーレイネットワークが役立ちます。

これは基本的に、ノード間でネイティブネットワークを横断するパケットをカプセル化するということです。オーバーレイネットワークを使用すると、すべてのパケットのカプセル化-カプセル化解除による遅延や複雑なオーバーヘッドが発生する可能性があるため、使用しない方がよいでしょう。また、オーバーレイネットワークは必要ない場合も多いので、むやみやたらに使用せず、必要な理由がある場合にのみ使用するようにしましょう。

オーバーレイネットワークでのトラフィックの流れを理解するために、CoreOS社のオープンソースプロジェクトであるflannelを例に考えてみましょう。

ここでは、先ほどと同じ設定ですが、ルートネットにflannel0という新しい仮想イーサネットデバイスが追加されていることがわかります。これはVXLAN（Virtual Extensible LAN）を実装したものですが、Linuxにとっては単なるネットワークインターフェースの一つに過ぎません。

pod1から（別のノードにある）pod4に向かうパケットの流れは、次のようになります。