クラウドネイティブ クラスタにおけるネットワーク トラフィックの可観測性に関する考察

背景

クラウド ネイティブ テクノロジーが広く普及し、実装される中で、私が遭遇した多くのユーザー ニーズには、クラウド ネイティブ クラスターの可観測性に関する要件が含まれています。クラスターの可観測性を実現することは、クラスターのセキュリティ保護の前提条件です。可観測性要件の中でも、クラスター内のコンテナ間のネットワーク トラフィックの可観測性要件は、より重要な部分の 1 つです。コンテナ ネットワーク トラフィック収集の実装の難しさは、従来のホスト ネットワーク トラフィック収集の実装の難しさよりも高くなります。

では、コンテナ ネットワークの複雑さはどこにあるのでしょうか?コンテナ ネットワークに適応するにはどうすればよいでしょうか?ここでは、私の仕事で得た経験に基づいて、クラウド ネイティブ クラスターにおけるネットワーク トラフィックの可観測性についていくつかの考えを述べ、議論を活性化させたいと思います。

CNIプラグイン

現在、CloudGap (適応型マイクロ分離) 製品をクラウド ネイティブ シナリオに適応させるプロセスで、次の CNI プラグインに遭遇しました。

Flannel - デフォルトは Vxlan の分散ゲートウェイ モードです。ホストGWモードまたはUDPモード（すでに廃止されているモード）を選択できます。

Calico - デフォルトの BGP モード。IPIP トンネルを使用して、ノード間のコンテナ間でデータを転送します。もちろん、IPIPトンネルモード（FlannelのホストGWモードに類似）を使用することもできます。

Openshift-SDN——OpenvswitchテクノロジーをベースにしたSDNテクノロジーに基づくネットワークソリューションです。

OVN-Kubernetes - Openvswitch の OVN ソリューションをベースにしており、実際には Openshift-SDN と似たシステムですが、アーキテクチャと詳細においてよりクラウドネイティブな最適化が行われています。

現在の問題

上記の種類のプラグインは、ほとんどのクラウドネイティブ環境で一般的な CNI プラグインであり、それ自体がコンテナ間ネットワークで使用されるテクノロジのほとんどをカバーしています。これらのタイプの CNI プラグインに基づいてコンテナ ネットワークのトラフィック情報を収集するプロセスで、著者は、すべての収集機能を 1 つのモードで完了することは不可能であることに気付きました。たとえば、一部の CNI プラグインでは、ホストをネットワーク トランジット デバイスとして扱い、ホスト上でバイパス メソッドを使用してコンテナー ネットワーク トラフィックの変更を検出する必要があります。一部の CNI プラグインでは、ホスト上のコンテナ ネットワーク トラフィック情報を直接観察することができず、収集作業を完了するにはコンテナのネットワーク名前空間に入る必要があります。一部の CNI プラグインでは、2 つのコンテナー間の直接アクセス関係をキャプチャすることすらできず、CNI プラグイン自体によって実装された技術原則と連携して、さらなる分析を通じてアクセス関係の決定を完了する必要があります。

したがって、コンテナ ネットワーク トラフィックの可観測性ソリューションを実装する前に、関連する CNI プラグインをさらに分析して、異なる CNI プラグインに異なる互換性と適応の要件がある理由を理解する必要があります。

プラグイン分析

フランネルプラグインの原理

Flannel は、Kubernetes 用に CoreOS チームによって設計されたオーバーレイ ネットワーク CNI プラグインです。さまざまな動作モードで構成できます。現在のデフォルトの動作モードは、仮想レイヤー 2 ネットワークである Vxlan です。

コンポーネントの概要

図1

Flannel は DaemonSet として Kubernetes クラスターにデプロイされます。完全な Flannel アーキテクチャには、次のコンポーネントが含まれます。

etcd - これは Flannel が依存する構成センターです。各ノードの flanneld は、調整と同期を実現するためにこの etcd コンポーネントに依存します。一般的なデプロイメント ソリューションでは、この etcd は Kubernetes コントロール レイヤー プレーンの etcd コンポーネントを直接再利用するため、通常は個別にデプロイされません。

flanneld——各ホストノードで flanneld サービスが開始されます。デフォルトの動作モードは Vxlan 構成に基づいています。このモードと host-gw モードでは、flanneld は主にバイパス構成管理のタスクを実行します。 UDP モードでは、このソリューション自体に重大なパフォーマンスの問題があるために、flanneld はデータ転送のタスクも実行する必要があります。そのため、長い間放置されていました。

ネットワークモードの概要

一般的に、Flannel はレイヤー 2 ネットワーク ソリューションです。デフォルトの Vxlan 動作モードに関しては、Vxlan の分散ゲートウェイ アーキテクチャを適用して 2 層通信ネットワークを形成するものと見ることができます。このアーキテクチャでは、ホスト内の仮想ネットワーク カード flannel.1 は、Vxlan レイヤー 2 ゲートウェイおよびレイヤー 3 ゲートウェイとして機能するリーフ ノードと見なすことができ、ホスト自体のネットワーク カードは転送用のスパイン ノードと見なすことができます。

図2

このネットワーク環境では、3 層転送中に送信者の IP がゲートウェイ アドレスに置き換えられているため、国境を越えたコンテナ通信の受信側は送信者から IP アドレスを直接取得できません。バイパスの観点から見ると、コンテナ間のトラフィックはホストマシン上で直接観察することはできません。観察できる場合、それは通常、レイヤー 2 ネットワーク内にあるため、ノード自体の 2 つのコンテナー間の接続です。同時に、この環境で、SideCar モードを使用してコンテナ ネットワーク名前空間を観察すると、この仮想レイヤー 2 ネットワーク自体にレイヤー 3 転送ゲートウェイがあるため、2 つのコンテナ間の接続関係を直接収集できないことがわかります。

host-gw モードの場合、ホスト マシンは純粋に 3 層転送ゲートウェイで構成されます。 Vxlan などのトンネルは使用されていませんが、3 層転送が存在するため、ノード間のコンテナ通信のネットワーク関係を直接観察することはできません。

まとめると、Flannel ベースのネットワーク トラフィックを観察する場合、実際の接続関係を正確に整理するためには、Flannel アーキテクチャ自体を組み合わせ、ネットワーク接続関係を整理するプロセスでレイヤー 3 ゲートウェイの転送特性を考慮することが重要です。このようなネットワーク アーキテクチャでは、ネットワーク トラフィックの監視も困難になります。

Calicoプラグインの原理

Calico は、コンテナ、仮想マシン、ホスト間のネットワーク接続のためのオープンソースのネットワークおよびネットワーク セキュリティ ソリューションです。 Kubernetes、OpenShift、DockerEE、OpenStrack などの PaaS または IaaS プラットフォームで使用できます。

コンポーネントの概要

図3

Felix - 各ノードで実行される Calico のコア コンポーネント。主な機能には、インターフェース管理、ルーティングルール、ACLルール、ステータスレポートなどが含まれます。

ETCD - データの一貫性を確保し、クラスター内のノードのすべてのルーティング情報を保存するデータベース。データの信頼性とフォールト トレランスを確保するには、少なくとも 3 つの ETCD ノードを用意することをお勧めします。

オーケストレーター プラグイン - オーケストレーター プラグインは、Kubernetes や OpenStack などのネイティブ クラウド プラットフォームが Calico を簡単に管理できるようにし、それぞれの API を通じて Calico ネットワークを構成してシームレスな統合を実現します。 Kubernetes CNIネットワークプラグインなど

Bird - BGP クライアント。 Calico は各ノードに BGP クライアントを展開します。その機能は、Felix のルーティング情報をカーネルに読み込み、BGP プロトコルを通じてクラスターに配布することです。 Felix が Linux カーネル FIB にルートを挿入すると、BGP クライアントはそれらのルートを取得し、展開内の他のノードに配布します。これにより、展開時にトラフィックが効率的にルーティングされるようになります。

BGP ルーター リフレクタ - メッシュ ネットワークを形成するために BGP クライアントのみを使用する大規模ネットワークでは、スケールの制限が生じます。すべてのノードには「N の 2 乗」の接続が必要です。この規模の問題を解決するために、BGP ルータ リフレクタ方式を使用して、すべての BGP クライアントを特定の RR ノードとのみ相互接続し、ルートを同期させることで、接続数を大幅に削減できます。

Calicoctl - Calico コマンドライン管理ツール

ネットワークモードの概要

Calico は BGP プロトコルを使用してコンテナ ネットワークを構築します。簡単に言えば、クラスター間のノードを境界ルーターとして使用して、ネットワーク全体の相互運用性を実現します。 BGP プロトコルでは、各ノード上のすべてのコンテナが AS (自律システム) として扱われ、異なるノードは BGP サービスによるルーティングと転送によって接続されます。実際、Calico プロジェクトが提供する BGP ネットワーク ソリューションは、Flannel の Host-GW モードとほぼ同じです。違いは、Calico はルーティング テーブルに基づいてコンテナ パケット転送を実装するのに対し、Flannel は flanneld プロセスを使用してルーティング情報を維持することです。ここでの違いは、flanneld がルーティング転送プロセスに介入し、コンテナ間の実際の通信が途中で NAT サーバ変換があるように見えることです (この場合、バイパス モードでは 2 つのコンテナ間のトラフィック接続関係を直接取得できないため、何らかの推論が必要になります)。 Calico はカーネル独自の BGP ルーティング転送に基づいており、基本的にはコンテナ間で元のデータ パケットを配信します。そのため、ホストノード上では、コンテナ全体のトラフィック関係をバイパス方式で収集することができます。

3 層ネットワーク上で実行されるコンテナ間ネットワークに適応するために、Calico は IPIP トンネル モードのサポートも追加しました。このモードでは、BGP プロトコルによって転送されたコンテナ ネットワーク データ パケットは、カーネルの IPIP モジュールによってカプセル化され、ホスト ネットワークに送信されます。しかし本質的には、コンテナ間での元の通信データ パケットの送信のままです。 Flannel とは異なり、境界を越えるときにデータ パケット自体の送信者の IP アドレスを置き換えるためにノード IP を使用しません。

さまざまなクラスター ネットワーク スケールに柔軟に適応するために、Calico はフル メッシュ モード (ノード間メッシュ) とルート リフレクション モード (ルーター リフレクション、略して RR) を提供します。中でも、完全相互接続モードは、構造がシンプルで実装が容易なため、小規模のクラスターノードに適しています。ただし、欠点は、BGP 接続の合計数が「N の 2 乗」になることです (N はノード数)。ノード数が増加すると、接続数の増加によりすぐに大きなネットワーク損失が発生します。ルート リフレクション モードでは、1 つ以上の BGP スピーカーを RouterReflection として指定し、接続の合計数を削減します。ただし、このアーキテクチャは実装がより複雑であり、BGP スピーカーとして機能するノードに対する要件が高くなります。大規模クラスターのネットワーク計画に適しています。

Openshift-SDNプラグインの原理

Openshift-SDN は、Red Hat がリリースしたコンテナ クラスター ネットワーク ソリューションであり、Openshift をデプロイするときに使用されるデフォルトのネットワーク ソリューションです。現在の環境で使用されている CNI プラグインを表示するには、 oc get Network.config.openshift.io cluster -o yaml コマンドを使用できます。

コンポーネントの概要

図4

Openshift-SDN には、コントロール プレーンとデータ プレーンが含まれます。

CTRL - コントロールプレーンは、ネットワークセグメントを各ノードに自動的に割り当て、CRDに記録するデプロイメントのセットです。

ノード - データ プレーンは、CRD の変更に応じてノード ネットワーク データ プレーンを構築するために使用される DaemonSet のセットです。ルーティング、ネットワークカード、フローテーブル、IPTABLESルールを含む

具体的なコンポーネントとしては、主にコントローラー、エージェント、CNI といった複数の部分から構成されます。主な責任は次のとおりです。

1. コントローラー

Openshift-SDN の CRD に対応する、クラスターレベルのコンテナー CIDR の構成を担当します: clusterNetwork

新しく追加されたノードに、Openshift-SDNのCRDに対応するサブセグメントを割り当てます: hostSubnet

k8s クラスター内の名前空間、ネットワーク ポリシー、およびその他のオブジェクトの変更を監視し、Openshift-SDN の CRD (netnamespaces、egressnetworkpolicies (特にアウトバウンド ネットワーク ポリシー)) を同期的に更新します。

2. エージェント

起動ごとにクラスター ネットワークを取得し、ローカル フロー テーブルと比較します。不一致がある場合は、ローカル クラスター ネットワーク フロー テーブル、ノード ルーティング、および IPTABLES ルールを再構成します。

クラスター内のOpenshift-SDN CRD: hostSubnetの変更を観察し、他のノードに到達するようにフローテーブルを構成する

クラスター内の Openshift-SDN の CRD (netnamespaces、egressnetworkpolicies) の変更を観察し、テナント分離とアウトバウンド制限に対応するフロー テーブルを構成します。

ノード上でCNIバイナリファイルを生成し、IP割り当て機能を提供する

このノードの各コンテナに対して、対応するフローテーブルを設定します。

3. 中央情報局

コンテナネットワークの設定と解放のためにkubeletから呼び出される役割を担う

エージェントからIPを申請し、解放します

コンテナ内のIPとルーティングを設定します

ネットワークモードの概要

簡単に言えば、Openshift-SDN はコンテナ間に大規模なレイヤー 2 ネットワークを構築します (仮想レイヤー 2 ではレイヤー 3 転送はありません)。すべてのコンテナの IP アドレスは仮想 L2 に属します。 ARP 要求を通じて互いの物理アドレスを確認し、通常のネットワーク パケット送信を実行できます。 ARP パケットでも一般的な IP パケットでも、ovs フローによって処理され、必要に応じてカプセル化されます。

実際のリンクとしては、Openshift-SDN を使用する場合、主に次のような状況があります。

• 同じノード上のコンテナ間アクセス: パケットはクライアントコンテナのVethからホストのovsブリッジへ行き、ピアコンテナのVethに直接到達します。
• ノード間のコンテナ間アクセス: パケットはクライアント コンテナの Veth からホスト マシンの ovs ブリッジに送信され、vxlan0 ポートを介してカプセル化された後、ホスト マシンのプロトコル スタックを通過し、ホスト マシンの物理ネットワーク カードから送信され、ピア コンテナが配置されているホスト マシンの物理ネットワーク カードに送信されます。これはVxlanとして識別され、ピアマシンのovsブリッジに入り、ピアコンテナのVethに行きます。
• コンテナがノードにアクセスします。パケットはクライアント コンテナの Veth からホスト マシンの ovs ブリッジに送信されます。ノードの物理ネットワーク カード IP はコンテナのネットワークと同じプレーン上にないため、内部フロー テーブル Table100 を直接通過し、tun0 ポートから送信されます。ホスト マシンのプロトコル スタックを通過し、ルーティングおよび転送され、最終的にホスト マシンのネットワークを経由してノードの物理ネットワーク カードに到達します。
• ノードはこのノードのコンテナにアクセスします。ホストのルーティングに従って、パケットは tun0 から送信され、ホストの ovs ブリッジに入り、ピア コンテナの Veth に配信されます。
• コンテナがサービスにアクセスします。パケットはクライアント コンテナの Veth からホストの ovs ブリッジに送信され、tun0 から送信されます。ホスト プロトコル スタックを通過し、IPTABLES ルールに従って DNAT および MASQUERADE の対象となります。その後、他のノードのコンテナにアクセスするノードになります。
• サービスのバックエンドはコンテナにパケットを返します。前のステップでコンテナがサービスにアクセスしたときに MASQUERADE が実行されたため、サービスのバックエンドは特定のノードが自分自身にアクセスしたと判断し、クライアント コンテナが配置されているノードにパケットを返します。 Node はパケットを受信すると、Conntrack テーブルと比較し、前回の接続の応答パケットであることを確認するため、パケットの送信元アドレスと宛先アドレスを修正し (前回実行した DNAT と MASQUERADE に対応)、ServiceIP がクライアント コンテナにアクセスするためのパケットになります。ノード上のルーティングに従って、tun0を経由してovsブリッジに入り、コンテナのVethに直接送信します。

ここで、Openshift-SDN 設計が純粋な仮想レイヤー 2 ネットワークを実装していることがわかります。これは、Flannel が Vxlan を使用してコンテナ間ネットワークを実装することとは多少異なります。 Openshift-SDN によって実装される純粋な仮想レイヤー 2 ネットワークは、完全なレイヤー 2 ネットワークです。カスタム ルーティング テーブルを維持する必要があり、コンテナー間の完全な接続関係をキャプチャできない flanneld とは異なり、Openshift-SDN のコンテナー間の通信は、元のデータ パケットの完全なフローです。

ただし、トンネル ネットワーク プロトコルを使用しているため、バイパス方式ではトンネル内のネットワーク トポロジをホスト マシン上で直接表示することはできません。そのため、クラスター ネットワークの可観測性機能を効果的に実装するには、コンテナーに同期された内部ネットワーク名前空間でデータを収集する必要があります。

OVN-Kubernetesプラグインの仕組み

OVN は、レイヤー 2 およびレイヤー 3 ネットワークを仮想化できる OVS に基づいて実装されたネットワーク ソリューションです。本質的には、技術原則は Openshift-SDN と一致しています。ただし、これは OVS によって提供されるネイティブの仮想化ネットワーク ソリューションであり、従来の SDN アーキテクチャ (Neutron DVR など) のパフォーマンス問題を解決することを目的としています。 Openshift 自体については、Openshift-SDN での NetworkPolicy の不完全なサポートの問題も解決します。

コンポーネントの概要

図5

• ノースバウンドデータベース - 論理スイッチ、ルーター、ACL、ポートなどの情報を格納します。現在はovsdb-serverに基づいていますが、将来的にはetcd v3をサポートする可能性があります。
• ovn-northd —— 集中型コントローラ。各 ovn-controller に北向きのデータベース データを配布する役割を担います。
• ovn-controller - 各マシンで実行されるローカル SDN コントローラー
• サウスバウンド データベース - ovsdb-server に基づいており (将来的には etcd v3 をサポートする可能性があります)、VM IP アドレスやトンネル カプセル化形式などの物理ネットワーク データの 3 種類のデータが含まれます。パケット転送方法などの論理ネットワークデータ。物理ネットワークと論理ネットワーク間の結合関係

Kubernetes のデプロイメント形式を見ると、主に次のコンポーネントに分かれています。

• ovnkube-db デプロイメント (2 つのコンテナ、nb-ovsdb と sb-ovsdb を含む) - 名前が示すように、2 つの ovn データベースをデプロイします。
• ovnkube-master デプロイメント (ovn-northd、nbctl-daemon、ovnkube-master コンテナーを含む) - マスター ノードを初期化し、クラスター内のオブジェクトの変更を監視し、それに応じて ovn ネットワークを構成するために使用されます。 cniバイナリhttpサーバーを実行し、対応するcmdAddとcmdDelを実行します。
• ノード用のovnkubeデーモンセット（ovs-daemons、ovn-controller、ovnkube-node） - 各ノード上のデーモン、ノードを初期化します
• ovn-k8s-overlay - POD が作成/破棄されたときに kubelet によって呼び出される CNI プラグイン バイナリ

ネットワークモードの概要

OVN-Kubernetes は主にオーバーレイ モードを使用し、OVN は論理オーバーレイ ネットワークを介してすべてのノードのコンテナーを接続します。

図6

本質的には、OVN-Kubernetes と Openshift-SDN の動作原理は同じであり、どちらも OVS に基づいて構築されたコンテナ用の大規模なレイヤー 2 ネットワークです。 OVN-Kubernetes の重要な改善点は、クラウドネイティブ シナリオへの適応にあります。 Kubernetes との互換性と、すべてのコンテナとサービス ネットワークを OVN システムに基づく実装に置き換えることに重点が置かれています。

• OVN-Kubernetes は、トンネル ネットワークの通信プロトコルとして Geneve プロトコルを使用します。これは、ノード間のネットワークを作成するために VXlan を使用する Openshift-SDN とは異なります。したがって、使用時に注意すべき制限がいくつかあります。
• OVN-Kubernetes は、ローカルの Kubernetes サービスに対する外部トラフィック ポリシーまたは内部トラフィック ポリシーの設定をサポートしていません。デフォルト値はクラスターです。この制限は、LoadBalancer、NodePort、または外部 IP を持つサービスを追加するときに影響する可能性があります。
• sessionAffinityConfig.clientIP.timeoutSeconds サービスは OVN-Kuberntes 環境では効果がありませんが、Openshift-SDN では役立ちます。これは 2 つのプラグイン間の非互換性です。
• デュアルスタック クラスターの場合、IPv4 トラフィックと IPv6 トラフィックの両方がデフォルト ゲートウェイと同じネットワーク インターフェイスを使用する必要があります。この要件が満たされない場合、ovnkube-node DaemonSet 内の POD はこのホスト上で CrashLoopBackOff 状態になります。したがって、ホストはデュアルスタック ネットワーク構成をサポートするように構成する必要があります。

一般的に、OVN-Kubernetes と Openshift-SDN のソリューションは、トラフィックの監視に関しては似ています。監視するには、コンテナのネットワーク名前空間に直接同期する必要があります。ここで注目すべきは、SDN アーキテクチャでは、従来の仮想 LAN アーキテクチャと比較して、仮想ネットワーク層自体の複雑さがさらに簡素化され、コンテナ ネットワーク トラフィックの観測可能性に対する 3 層転送の障害が解消され、トラフィックの観測可能性の設計アイデアが簡素化されるということです。

要約する

現在、クラウドネイティブのシナリオでは、ソフトウェア業界以外の大規模な企業ユーザーは、豊富な機能と完全な技術サポートを備えた商用製品である Openshift を選択して、独自のクラウドネイティブ データセンターを構築する傾向があります。このような環境では、コンテナ ネットワーク トラフィック監視ツールが機能的な適応を実現するには、OVS 技術アーキテクチャと深く統合し、独自の基礎となる実装原則を通じてデータ分析を実行して、ネットワーク トポロジを取得する必要があります。あるいは、ホスト レベルでのネットワーク アーキテクチャの複雑さを無視し、コンテナーのレイヤー 2 ネットワークに直接アクセスしてデータを収集することもできます。

ソフトウェア業界の企業ユーザーの中には、独自のクラウドネイティブ環境を開発している企業も数多く存在します。このタイプの環境では、ほとんどのオープンソース ソフトウェア コンポーネントが独自のインフラストラクチャを構築するために使用されます。このような環境では、ほとんどの企業は Calico を使用して独自のコンテナ間ネットワークを実装します。 Calico が提供する BGP + IPIP ソリューションは、OVS などの複雑な仮想化ネットワーク ソリューションと比較して、コンテナ間ネットワークに対する Kubernetes 自体の基本的な接続要件も満たしています。十分な場合、これらのユーザーはよりシンプルなアーキテクチャを採用して独自の環境を実装するため、Calico などのソリューションも広く使用されています。 Calico のようなネットワーク ソリューションは、ホスト自体が提供するネットワーク機能を活用することに重点を置いているため、コンテナー間の通信トラフィックは多くの場合、ホスト上で直接キャプチャできます。ホスト ネットワーク トラフィック収集ツールを少し変更して、コンテナー間のネットワーク トポロジ関係の収集をサポートすることができます。

理論的には、コンテナ ネットワーク データを収集するための SideCar のようなモードは、ほとんどのネットワーク プラグインのコンテナ間のネットワーク トポロジ収集に適応できます。ただし、コンテナ ネットワークでレイヤー 3 転送ソリューションを実装するプラグインなど、例外もいくつかあります (Vxlan のレイヤー 2 およびレイヤー 3 転送を構成することでレイヤー 2 ネットワークを実装する Flannel や、IPIP トンネル モードのない Calico や、ホストをレイヤー 3 転送ゲートウェイとして直接使用することでレイヤー 2 ネットワークを実装することに本質的に似ている Flannel の host-gw モードなど)。このようなコンテナ ネットワークは、バイパス モードでも SideCar モードでも、2 つのコンテナ間の接続関係を直接収集することはできません。したがって、これに基づいて、ネットワーク アーキテクチャの特性を適切に適応させることにより、対応するネットワーク トラフィックの関係を二次的に分析することが、これらのアーキテクチャで観測可能性が正しく機能するための重要な考え方となります。

もちろん、Linux カーネル自体の観測機能は開発され続けています。将来的にはさらに優れたソリューションが登場し、異なるネットワーク アーキテクチャのコンテナ ネットワーク間のトラフィック監視を実現する、より一般的なソリューションが登場する可能性もあります。