Kubernetes ネットワーク モデルの簡単な分析

さまざまなコンテナ ネットワーク モデルの実装原理については既に基本的な理解がありますが、コンテナ テクノロジーを真に推進するのは Kubernetes コンテナ オーケストレーション プラットフォームです。 Kubernetes は多数のコンテナインスタンスを統合してクラスターを形成します。これらのコンテナ インスタンスは、異機種の基盤ネットワーク環境で実行される場合があります。これらのコンテナ間の相互運用性をどのように確保するかは、実際の運用環境における主要な考慮事項の 1 つです。

Kubernetesネットワークの基本要件

Kubernetes はコンテナ テクノロジーの抽象化をさらに進めました。最も重要な点はポッドの概念です。 Pod は Kubernetes リソース スケジューリングの基本単位です。ポッドは単純にコンテナの拡張と考えることができます。ネットワークの観点から、ポッドは次の条件を満たす必要があります。

• 各ポッドには固有の IP アドレスがあり、すべてのポッドは直接接続できるフラットなネットワーク空間内にあります。
• 同じポッド内のすべてのコンテナは同じnetnsネットワーク名前空間を共有します。

これらの基本要件に基づいて、次のことを知ることができます。

• 同じポッド内のすべてのコンテナは同じポートを共有し、localhost + port を通じて直接アクセスできます。
• 各ポッドには個別の IP があるため、コンテナ ポートとホスト ポートのマッピングやポートの競合を考慮する必要はありません。

実際、Kubernetes は、適格なクラスター ネットワークの基本要件をさらに定義しています。

• 実際には、アドレス変換に NAT を明示的に使用しなくても、任意の 2 つのポッドが直接通信できます。
• 任意のクラスター ノードは明示的なアドレス変換なしで任意のポッドと直接通信でき、その逆も同様です。
• どのポッドも自分自身が認識する IP アドレスは、他のポッドが認識する IP アドレスと同じであり、その間でアドレス変換を実行することはできません。

つまり、上記の 3 つの要件をすべて満たすネットワーク モデルは、Kubernetes に適用できます。実際、Kubernetes の初期の頃にはネットワーク標準はなく、上記の基本的な要件のみが提案されていました。これらの要件を満たすネットワークのみを Kubernetes のデプロイに使用できます。この基礎となるネットワークの仮定に基づいて、Kubernetes は、pod-deployment-service という古典的な 3 層サービス アクセス メカニズムを設計しました。 Kubernetes が新しい CNI (Container Network Interface) ネットワーク標準を採用し始めたのは、1.1 のリリースになってからでした。

インド国立情報学研究所

実際、先ほどコンテナ ネットワークを紹介したときに、CNI ネットワーク仕様について言及しました。 CNM (コンテナ ネットワーク モデル) と比較すると、CNI は開発者に対する制約が少なく、よりオープンであり、Docker に依存しません。実際、CNI 仕様は非常にシンプルです。https://github.com/containernetworking/cni/blob/master/SPEC.md をご覧ください。

CNI ネットワーク プラグインを実装するには、構成ファイルと実行可能ファイルのみが必要です。

1. 設定ファイルには、プラグインのバージョン、名前、説明、その他の基本情報が記述されています。
2. 実行可能ファイルは、上位レベルのコンテナ管理プラットフォームによって呼び出されます。 CNI 実行可能ファイルには、コンテナをネットワークに追加するための ADD 操作と、コンテナをネットワークから削除するための DEL 操作 (およびバージョンを表示するためのオプションの VERSION 操作) を実装する必要があります。

CNI ネットワーク プラグインを使用した Kubernetes の基本的なワークフローは次のとおりです。

1. Kubeletはまず、対応するnetnsネットワーク名前空間を生成するための一時停止コンテナを作成します。
2. 設定に従って特定のCNIプラグインを呼び出します。これは、チェーン呼び出し用のCNIプラグインチェーンとして設定できます。
3. CNI プラグインが呼び出されると、環境変数とコマンドラインパラメータに基づいて、ネットワーク名前空間 netns やコンテナのネットワークデバイスなどの必要な情報を取得し、ADD 操作を実行します。
4. CNI プラグインは一時停止コンテナに正しいネットワークを構成し、ポッド内の他のすべてのコンテナは一時停止コンテナのネットワークを使用します。

一時停止コンテナが何であるか、ポッド内のどこにあるかがわからない場合は、前のメモを参照してください: https://morven.life/notes/from-container-to-pod/

ポッドネットワークモデル

Kubernetes ネットワーク モデルの実装原理を理解するには、単一のポッドから始める必要があります。実際、単一ポッドのネットワーク モデルに慣れると、Kubernetes ネットワーク モデルは基本的にコンテナ ネットワーク モデルと同じ原則に従っていることがわかります。

前述の Docker コンテナからポッドへのメモから、ポッドが起動すると、まず一時停止コンテナが作成されて対応する netns ネットワーク名前空間が生成され、その後、他のコンテナが一時停止コンテナによって作成されたネットワーク名前空間を共有することがわかります。単一コンテナのネットワークモデルについては、以前にも紹介しました。主に、docker0 ブリッジ デバイスと veth デバイスを介して、異なるコンテナ ネットワーク名前空間を接続します。これから、次の図に示すように、単一のポッド ネットワーク モデルの作成プロセスを取得できます。

同じポッド内の他のコンテナは、一時停止コンテナによって作成されたネットワーク名前空間を共有していることがわかります。つまり、すべてのコンテナは、同じマシン上で実行されている異なるプロセスであるかのように、同じネットワークデバイス、ルーティングテーブル設定、サービスポートなどの情報を共有しているため、これらのコンテナは localhost を介して対応するポートと直接通信できます。クラスター外のリクエストの場合、docker0 ブリッジ デバイスがゲートウェイとして機能し、アドレス変換には iptables が使用されます。これは実際にはコンテナのブリッジ ネットワーク モデルの拡張であることがわかります。

主流のKubernetesネットワークソリューション

前のセクションでは、単一ポッドのネットワーク モデルはコンテナ ネットワーク モデルの拡張であることを学びました。しかし、ポッドはどのようにして互いに通信するのでしょうか?これは実際にはコンテナ間の通信と非常によく似ており、同じホスト上のポッド間の通信とホスト間のポッド間の通信の 2 つのタイプに分けられます。

コンテナ ネットワーク モデルと同様に、同じホスト上のポッドは、docker0 ブリッジ デバイスを介してレイヤー 2 (データ リンク層) ネットワーク上の MAC アドレスを介して直接通信できます。

ホスト間ポッド通信には、主に 2 つの考え方があります。

• 基盤となるネットワーク デバイスの構成を変更し、コンテナー ネットワークの IP アドレス管理を追加し、ルーター ゲートウェイを変更するなどします。この方法は主に SDN (ソフトウェア定義ネットワーク) と組み合わせられます。
• 基盤となるネットワーク デバイス構成をまったく変更せずに、元のアンダーレイ プレーン ネットワークを再利用して、コンテナーのホスト間通信を解決します。主に 2 つの方法があります: トンネル伝送 (オーバーレイ): コンテナーのデータ パケットを元のホスト ネットワークの 3 層または 4 層のデータ パケットにカプセル化し、ホスト ネットワークの IP または TCP/UDP を使用してターゲット ホストに送信します。ターゲット ホストはパケットを解凍し、ターゲット コンテナーに転送します。一般的なオーバーレイ トンネル伝送ソリューションには、Vxlan、ipip などがあります。現在、オーバーレイ トンネル伝送技術を使用する主流のコンテナ ネットワークには、Flannel などがあります。

ホスト ルートの変更: コンテナ ネットワークをホスト ルーティング テーブルに追加し、ホスト ネットワーク デバイスをコンテナ ゲートウェイとして使用し、ルーティング ルールを通じて指定されたホストに転送し、コンテナの 3 層相互接続を実現します。現在、ルーティング技術を通じてコン​​テナ間のホスト間通信を実現するネットワークとしては、Flannel host-gw や Calico などがあります。

主流の解決策をいくつか紹介します。

• フランネルは現在最も一般的に使用されているソリューションです。さまざまなネットワーク バックエンドを提供し、複数のデータ パスをサポートし、オーバーレイ/アンダーレイなどのさまざまなシナリオに適しています。オーバーレイ データ パケットのカプセル化には、ユーザー モード UDP、カーネル モード Vxlan (比較的優れたパフォーマンス) を使用できます。また、クラスターが小さく、同じレイヤー 2 ドメイン内にある場合でも、host-gw を使用してホスト ルーティング テーブルを変更できます。
• Weave の動作モードは Flannel の動作モードと非常に似ています。当初は UDP (スリーブ モードと呼ばれる) ネットワーク モードのみを提供していましたが、後にファストパス モード (VxLAN ベース) が追加されました。ただし、Weave は Flannel にネットワーク アドレスを格納するために使用される追加のコンポーネントを排除し、独自の高可用性データ ストレージ機能を統合します。
• Calico は主に、ホスト ルートを変更し、BGP プロトコルを使用してノード間のルートを同期する方法を採用しています。ただし、実際のネットワークでは必ずしも BGP ルーティングがサポートされているわけではないため、Calico はカーネル内で IPIP モードもサポートし、オーバーレイを使用してデータを送信します。

次の表は、いくつかの主流の Kubernetes ネットワーク ソリューションを比較したものです。

 |あ |オーバーレイネットワーク |ホストルートテーブル |ネットワークポリシー サポート |分散型 IP 割り当て | | – | — | — | — | — | |フランネル | UDP/VXLAN |ホスト-GW |なしなし|織り | UDP/VXLAN |該当なし |はい

ポリシー制御（ネットワークポリシー）

ネットワーク ポリシーは、アプリケーションを分離してセキュリティを強化するために Kubernetes によって提供されるポリシー ベースのネットワーク制御です。 Kubernetes で一般的に使用されるラベル セレクターを使用して、従来のセグメント化されたネットワークをシミュレートし、それらの間の東西トラフィックと、ポリシーを通じて外部と通信するための南北トラフィックを制御します。

• 注意: 使用するネットワーク プラグインがポリシー制御 (ネットワーク ポリシー) をサポートしていることを確認してください。たとえば、Flannel はネットワーク ポリシーを実装していません。

次の例では、一般的なネットワーク ポリシー インスタンスを構成します。

 APIバージョン: networking.k8s.io/v1
種類: ネットワークポリシー
メタデータ:
名前: テストネットワークポリシー
  名前空間:デフォルト 
仕様:
  ポッドセレクター:
    一致ラベル:
      役割: db
  ポリシータイプ:
  - 入口 - 出口 入口:
  -から：
    -ipブロック:
        cidr: 172.17.0.0/16
を除外する：
        - 172.17.1.0/24
    - 名前空間セレクター:
        一致ラベル:
          プロジェクト: myproject
    - ポッドセレクタ:
        一致ラベル:
          役割: フロントエンド
    ポート:
    - プロトコル: TCP
      ポート: 6379
  出口:
  -に：
    -ipブロック:
        cidr: 10.0.0.0/24
    ポート:
    - プロトコル: TCP
      ポート: 5978

ラベルセレクター namespaceSelector と posSelector を使用して、ポッド間のトラフィックを制御します。トラフィックの動作は主に次の 3 つのオブジェクトによって決まります。

• 制御オブジェクト: spec.podSelector によるフィルタリング
• トラフィックの方向: イングレスはポッドへのトラフィックを制御し、エグレスではポッドからのトラフィックを制御します。
• トラフィック特性: ピア IP プロトコル ポート

ネットワーク ポリシーを使用すると、受信フローと送信フローを正確に制御できます。さまざまなセレクター (ラベルまたは名前空間) を使用して、条件を満たすポッドのグループを見つけたり、通信の両端を見つけたりして、トラフィックの特性に基づいて接続できるかどうかを判断します。これはホワイトリストのメカニズムとして理解できます。