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

背景

クラウドネイティブテクノロジーが広く普及し、実装される中で、私が遭遇した多くのユーザーニーズには、クラウドネイティブクラスターの可観測性に関する要件が含まれています。クラスターの可観測性を実現することは、クラスターのセキュリティ保護の前提条件です。可観測性要件の中でも、クラスター内のコンテナ間のネットワークトラフィックの可観測性要件は、より重要な部分の 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 カーネル自体の観測機能は開発され続けています。将来的にはさらに優れたソリューションが登場し、異なるネットワークアーキテクチャのコンテナネットワーク間のトラフィック監視を実現する、より一般的なソリューションが登場する可能性もあります。

<<: クラウドアーキテクチャ DevOps を適用するには?

>>: KubeSphere DevOps システム機能の実践