Kubernetes: ネットワークとポリシーの制御

この記事では、Kubernetesコンテナネットワークのネットワークポリシーの概念と活用方法をすべて紹介します。

著者：アリババのシニアテクニカルエキスパート、Ye Lei（Daonong）氏

1）Kubernetesの基本的なネットワークモデル

この記事では、Kubernetesのネットワークモデルに関する基本的な基礎知識を紹介します。Kubernetesはネットワークの実装ソリューションを制限していないため、既存の理想的なリファレンスケースはありません。Kubernetesはコンテナネットワークの制限を決定するために、コンテナネットワークモデルを定義しています。一般的に、これは3つの要件と4つの目標にまとめられます。

適格なコンテナネットワークソリューションには、この3つの要件を満たす必要があります。4つの目標は、ネットワークトポロジーの設計やネットワーク機能の実装において、接続性のある主要な指標を満たすことです。

3つの要件

3つの要件とは、以下の通りです。

• 1) 任意の2つのPodは，データの受信やアドレスの変換に明示的にNAT（Network Address Translation）を使用することなく，相互に通信することができます。
• 2)ノードとPodは、明示的なアドレス変換を行わずに、相互に通信できます。
• 3) Podに表示されるIPアドレスは、他のPodのIPアドレスと同じであり、中間的な遷移はありません。 なお、Kubernetesがコンテナネットワークに対して任意のモデルや要件を設定している理由については後述します。

4つの目標

Kubernetesシステムのコンテナ内のアプリケーションに外部システムを接続する方法を規定しています。

• 外部システムがサービスとどのように通信するのでしょうか。言い換えれば、インターネットや外部のユーザーがどのようにサービスを利用するのでしょうか。ここでいうサービスとは、Kubernetesのサービスを指します。
• これらのサービスは、バックエンドのPodとどのように通信するのでしょうか。
• Podはどのようにしてお互いを呼び出すのでしょうか？
• Pod内のコンテナはどのようにして相互に通信するのでしょうか？

最終的な目標は、接続された外部システムがコンテナ用のサービスを提供できるようにすることです。

基本的な制約事項

コンテナネットワークの開発は、ホストネットワークに依存するため複雑です。この観点から、コンテナネットワークは、アンダーレイとオーバーレイの2つに分けられます。

• アンダーレイ・ネットワークは、ホスト・ネットワークと同じレイヤーに位置します。アンダーレイネットワークでは、ホストネットワークと同じCIDRブロックや基本的な入出力デバイスを持っているかどうか、コンテナのIPアドレスがホストネットワークと同じセンターから配布または割り当てられているかどうかが見えます。
• これに対し、オーバレイネットワークは、ホストネットワーク上のIPM管理コンポーネントにIPアドレスを申請する必要はありません。一般的に、ホストネットワークのIPアドレスと競合しないIPアドレスは、オーバーレイネットワークに割り当てられます。

なぜコミュニティは、単純で恣意的なモデルであるperPodperIPを提唱しているのかを理解することが重要です。私の考えでは、このモデルが、パフォーマンスの追跡や特定のサービスの監視に多くのメリットをもたらすからです。常に同じIPアドレスを使用することは、場合によっては有益です。

2) ネットワーク名前空間

定義

ここでは、ネットワークが実装しているカーネル基盤をネットワークネームスペースで説明します。runC コンテナ技術は、ハードウェアに依存せずに、そのカーネルをベースに実行されます。カーネル代表のプロセスはタスクです。アイソレーションを必要としない場合は、特別な空間アイソレーションデータ構造（nsproxy-namespace proxy）を持たないホスト空間（名前空間）を使用します。

ただし、独立したネットワークプロキシやマウントプロキシを使用する場合は、プライベートデータを追加する必要があります。そのデータ構造を前掲の図に示します。

ネットワーク名前空間は、独立したネットワーク空間のように見え、独自のネットワークインターフェースコントローラ（NIC）やネットワークデバイスを持っています。NICは、仮想または物理で、独自のIPアドレス、IPテーブル、ルーティングテーブル、プロトコルスタックの状態を持っています。プロトコルスタックとは、TCP/IPプロトコルスタックのことで、独自のステータス、iptables、IPVSを持っています。

つまり、完全に独立したネットワークであり、ホストネットワークからは隔離されています。プロトコルスタックのコードは共通ですが、データ構造は異なります。

Podとネットワークのネームスペースの関係

前述の図は、Podとネットワークネームスペースの関係を示しています。各Podは、Podネットコンテナ間で共有される独立したネットワーク空間を持っています。Podネットコンテナ間の通信を可能にするために、Kubernetesのループバックインターフェースを使用することが推奨されます。すべてのコンテナは、PodIPアドレスを使用して外部サービスを提供します。ホスト上のルートネットワークネームスペースは、PIDが1の特殊なネットワーク空間とみなされます。

3) 主流のネットワークソリューションの概要

コンテナネットワークの代表的な実装ソリューション

ここでは、コンテナネットワークの代表的な実装ソリューションを簡単に紹介します。コンテナネットワークはKubernetesにおいて様々な方法で実装されています。コンテナネットワークは、基盤となるIaaSネットワークとの調整や、パフォーマンスとIPアドレス割り当ての柔軟性とのトレードオフなど、複雑な要素を含んでいます。そのため、様々なソリューションが用いられることがあります。

このセクションでは、Flannel、Calico、Canal、WeaveNetなど、いくつかの一般的なソリューションについて説明します。これらのソリューションのほとんどは、Calicoに似たポリシーベースのルーティング方式を採用しています。

• Flannelは、様々なネットワークバックエンドを提供する包括的なソリューションです。バックエンドが異なれば、トポロジーも異なる。このソリューションは様々なシナリオをサポートします。
• Calicoは、ポリシーベースルーティングを採用しており、ノード間でBGPを使用してルートを同期させている。豊富な機能とネットワークポイントへの対応力が特徴です。Calicoでは、L2ネットワークを介さず、MACアドレスを使って基盤となるネットワークに直接接続する必要があります。
• コミュニティメンバーの中には、FlannelとCalicoの長所を組み合わせて、Ciliumというグラフト化された革新的なプロジェクトを行っている人もいます。
• データの暗号化には、ダイナミックなソリューションでより優れた暗号化を実現するWeaveNetを使用します。

Flannel Solution

最も一般的に使用されているのがFlannelソリューションです。前述の図は、典型的なコンテナネットワークソリューションを示しています。まず、コンテナからホストにパッケージを送るためのブリッジが追加されています。そのバックエンドは独立しています。したがって、パッケージがホストからどのように送信されるか、どのカプセル化方法を使用するか、カプセル化が必要かどうかをカスタマイズすることができます。

以下では、3つの主要なバックエンドについて説明します。

• 1つ目は、ユーザーモード用のUDP（ユーザー・データグラム・プロトコル）で、これは最も初期の実装でもあります。
• 2つ目は、カーネルモードのVxLANです。どちらのバックエンドもオーバーレイ・ネットワークのソリューションです。VxLANはパフォーマンスに優れていますが、VxLANの機能をサポートするカーネルが必要です。
• クラスタの規模が小さく、同じL2ネットワーク上に存在する場合は、host-gwを使用します。このモードでは、バックエンドはブロードキャストルーティングルールによって起動され、より高いパフォーマンスを発揮します。

4）ネットワークポリシーの活用

ネットワークポリシーの考え方

ここでは、ネットワーク・ポリシーの考え方について説明します。

前述のように、Kubernetesの基本的なネットワークモデルでは、すべてのPodが相互に接続されている必要がありますが、これにはいくつかの問題があります。Kubernetesクラスターでは、いくつかのトレースがお互いを直接呼び出すことができません。例えば、部門Aが部門Bのサービスにアクセスするのをブロックしたい場合、ポリシーの使用は必須です。

基本的には、さまざまなセレクタ（ラベルや名前空間）を使って、Podのセットや通信の両端を探します。そして、それらが相互に接続できるかどうかを、ホワイトリストと考えられるストリーム機能の記述に基づいて判断します。

ネットワークポリシーを使用する前に、前出の図に示すように、APIサーバーの拡張機能、v1beta1、およびネットワークポリシーを有効にします。さらに重要なことは、特定のネットワーク・プラグインがネットワーク・ポリシーの実装をサポートしていることです。ネットワークポリシーは、Kubernetesが提供する単なるオブジェクトであり、実装のためのコンポーネントは組み込まれていません。実装は、選択したコンテナネットワークソリューションに依存します。例えば、Flannelソリューションは、実際にはネットワークポリシーを実装していないため、役に立ちません。

設定例

ネットワークポリシーを設計するには、次のようなパラメータを決定します。

• 1つ目は制御オブジェクトで、この例ではspecの部分がそうです。specでは、podSelectorまたはnamespace selectorを使用して、制御するPodのセットを選択します。
• ストリームの方向も決定する必要があり、インバウンド、アウトバウンド、またはその両方が考えられます。
• 最も重要なことは、指定されたストリーム方向と制御オブジェクトに基づいて、許可されるストリームまたは拒否されるストリームを記述することです。例えば、ストリーム機能では、いくつかのセレクタを使用してピアエンドを決定し（これは実際にオブジェクトを選択することになります）、IPBlockメカニズムを使用して許可されるIPアドレスを決定し、プロトコルとポートを決定します。ストリーム機能を組み合わせて、特定の受け入れ可能なストリームを選択する5つにまとめます。

概要

本記事の内容を簡単にまとめます。

• IPアドレスは、Podコンテナネットワークの中核となるものです。各Podが外部システムと通信するための基盤となります。一方で、内部システムと外部システムで同一である必要があり、Kubernetesのモデル機能に準拠している必要があります。

• ネットワークソリューションでは、トポロジーがコンテナネットワークのパフォーマンスを左右するキーとなります。パッケージの送信元と送信先の端がどのように相互接続されているか、パッケージがコンテナからホストにどのように送信されるか、送信後にパッケージをカプセル化する必要があるか、カプセル化を解除する必要があるか、パッケージがポリシーベースのルーティングで送信されるか、パッケージがピアエンドに到達したときにどのように解析されるかを理解することが重要です。

• コンテナネットワークを選択し、設計し、外部ネットワークに関する情報や、普遍的に適応可能なソリューションの必要性がないと仮定します。このような場合、MACアドレスが直接接続をサポートしているかどうか、または外部ルータのルーティングテーブルを制御できるかどうかがわからなかった場合、Flannelソリューションを選択し、VxLANをバックエンドソリューションとして使用します。ネットワークがデュアルレイヤーで直接接続されていることが確実な場合は、CalicoまたはFlannel-Hostgwをバックエンドのソリューションとして使用します。

• ネットワークポリシーは、O&Mや使用時にインバウンドとアウトバウンドのストリームを正確にコントロールする強力なツールです。希望する制御対象やストリームに応じて実装方法を選択してください。

5) 考察

ここでいくつかの質問をしてみましょう。

1) インターフェイスは、Container Network Interface (CNI)に従って標準化されています。しかし、なぜコンテナネットワークには標準的な実装がなく、Kubernetes内に構築されているのでしょうか？
2) ネットワークポリシーに標準的なコントローラや実装がなく、コンテナネットワークのオーナーが提供するのはなぜでしょうか？
3) RDMAなど、TCP/IPソリューションとは異なるソリューションを考えると、コンテナネットワークをネットワークデバイスゼロで実装することは可能でしょうか？
4) O&M時に多くのネットワーク問題が発生し、トラブルシューティングが困難です。この場合、コンテナとホスト間、ホスト間、カプセル化とカプセル化解除の間のネットワーク状態を確認するためのオープンソースのツールを開発する必要があるのでしょうか？私たちが知る限り、このツールはまだありません。

ここまでで、Kubernetesのコンテナネットワークにおけるネットワークポリシーの考え方や活用方法について一通り説明しました。

本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。

アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ