Meituコンテナの最適化の実践からKubernetesネットワークスキームの設計について話す

Meituコンテナの最適化の実践からKubernetesネットワークスキームの設計について話す

はじめに：この記事では、オンラインで発生する実際の問題を含め、Meituオンラインコンテナ化の実際の経験を紹介することにより、Kubernetes環境でのネットワークソリューションの設計について説明します。K8Sを変革している建築家から学び、学ぶ価値があります。

MeituのシニアシステムR＆DエンジニアであるLi Lianrongは、数千万人をサポートする長期接続サービスを確立し、Meituのコンテナ化サービスをゼロから確立し、Meituのコンテナ化ネットワークソリューションの完成を主導しました。彼はネットワークとストレージに関する深い知識を持っています。

現在、Kubernetesクラスターは、基本的なネットワークソリューションとしてCalicoを使用することを選択しています。

Calicoネットワークソリューションの選択の課題

Calicoは、ルーティング（BGP）に基づくSDNのセットであり、ルーティングと転送を介してコンテナーのクロスホスト通信を実装します。Calicoは、各ノードを「ルーター」として仮想化し、それに独立した仮想ネットワークセグメントを割り当てます。ルーターは、現在のノード上のコンテナーにルーティングサービスを提供します。

Calicoプロジェクトの詳細については、https：//www.projectcalico.org/を参照してください。以下では、特定のネットワークを例として取り上げ、設計と問題点を紹介します。

上の図を例にとると、ノード192.168.1.2によって割り当てられた仮想ネットワークセグメントが10.233.1.0/24であり、コンテナ10.233.1.2が実行されている場合、ルーティング情報は次のようになります。

10.233.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 cali814214d5913

物理マシンが宛先アドレス10.233.1.2のIPパケットを受信すると、ネットワークポートcali814214d5913に転送されます。cali814214d5913はveth-pairを介して作成されたネットワークカードであり、マシンのIPアドレス10.233.1.2のコンテナと通信します。 、IPアドレスが10.233.1.2のコンテナは、対応するIPパケットを受信できます。

ノード192.168.1.3のコンテナ10.233.2.2がIPパケットを10.233.1.2に送信する場合、10.233.1.2が配置されている物理ノードのIPを認識し、次のルーティングルールを追加する必要があります。

10.233.1.0 / 16 192.168.1.2 eth0

Calicoは、BGPを使用してノード間のルーティングルールを学習します。ノード192.168.1.2はノード192.168.1.3とBGPネイバーを確立し、ノード192.168.1.3はBGPを介して上記のルーティングルールを学習できます。コンテナ10.233.2.2がIPパケットを10.233.1.2に送信すると、上記のルーティングルールに従ってノード192.168.1.2に転送され、ノード192.168.12から10.233.1.2に転送されて、コンテナのクロスホスト通信が実現されます。

ただし、2つのコンテナが配置されているノードが10.233.3.2などの異なるサブネットにある場合、それらが配置されているノード192.168.2.2とノード192.168.1.2は異なるサブネットにあります。現時点では、次のルートを192.168.2.2に追加することはできません。

10.233.1.0 / 16 192.168.1.2 eth0

これは、物理マシン192.168.2.2と物理マシン192.168.1.2の間のリンク層が通信できないためです。この問題を解決するために、CalicoはIPIPを選択しました。IPIPは、仮想ネットワークのIPデータパケットを物理ネットワークのIPデータパケットにカプセル化して送信します。IPIPを有効にすると、対応する仮想ネットワークカードがノードに表示されます。通常はtunl0で、ノード192.168.2.2は次のルーティングルールを追加できます。

10.233.1.0 / 16 192.168.1.2 tunl0

前のルートとの違いは、ネットワークポートがtunl0に変更されていることです。10.233.3.2がIPパケットを10.233.1.2に送信すると、そのノードはIPパケットをネットワークポートtunl0に転送し、tunl0に転送されたIPパケットはIPIPドライバーによって引き継がれます。IPIPドライバーは、各IPデータパケットを物理ネットワーク上のIPデータパケットにカプセル化します（宛先アドレスはネクストホップアドレス、つまり192.168.1.2であり、ペイロードは仮想マシンによって送信された元のIPデータパケットです）。

IPデータパケットの宛先アドレスはノード192.168.1.2であるため、物理ゲートウェイを介して転送できます。ノード192.168.1.2で実行されているIPIPサービスは、物理ネットワークIPデータパケットを受信して​​そのペイロードを取り出し、ノード192.168.1.2のルーティングルールに従って対応するコンテナに転送し、コンテナのサブネット間通信を実現します。

Calicoネットワークソリューションの問題

Calicoの動作原理から、Calicoには次の問題があることがわかります。

• IPIPを使用する場合は、IPプロトコルをネストする必要があり、追加のパッケージ化およびアンパック化アクションにより、パフォーマンスのオーバーヘッドが発生します。
• IPIPを使用する場合、ネストされたIPプロトコルヘッダーにより、実際の有効MTU長が短くなり、実際の帯域幅使用率にも影響します。
• クラスタ外のノードはクラスタ内のルーティング情報を学習できないため、クラスタ内のコンテナに直接アクセスすることはできません。

Calicoの動作原理によれば、Calicoはコンテナのクロスサブネット通信を解決するためにIPIPを選択しましたが、一連のパフォーマンスの問題が発生したのはIPIPの導入によるものですが、なぜCalicoはIPIPプロトコルを選択したのでしょうか。

この問題を理解するために、まず、従来の物理ネットワークがどのようにクロスサブネット通信を解決するかを見てみましょう。上の図を例にとると、物理マシン192.168.2.3が物理マシン192.168.1.2にアクセスするための手順は次のとおりです。

• 物理マシン192.168.2.3は、ターゲットIPがそれ自体とは異なるサブネットにあることを検出するため、デフォルトのルーティングルールを介してゲートウェイ192.168.2.1に送信します。
• 物理ゲートウェイ192.168.2.1は、ゲートウェイ192.168.2.1がルーティングプロトコルを介してIPパケットを物理192.168.1.2に転送できることを認識できるため、対応するIPパケットはゲートウェイ192.168.1.1に転送されます。
• 次に、物理ゲートウェイ192.168.1.1は、IPパケットを物理マシン192.168.1.2に転送します。

Calicoネットワークをもう一度見てみましょう。IPIPがない場合、コンテナ10.233.4.2がコンテナ10.233.1.2にアクセスする手順は次のとおりです。

• ホスト192.168.2.3は、ターゲットIPがそれ自体とは異なるサブネットにあることを検出するため、ターゲットアドレス10.233.1.2のIPパケットをゲートウェイ192.168.2.1に転送します。
• ゲートウェイ192.168.2.1には一致するルーティングルールがないため、IPパケットをドロップし、到達不能な宛先を返します。

IPIPが導入された場合、コンテナー10.233.4.2がコンテナー10.233.1.2にアクセスするための手順は次のとおりです。

• ホスト192.168.2.3は、ルーティングルール「10.233.1.0/16192.168.1.2tunl0」と一致します。
• ホストマシン192.168.2.3は、コンテナから送信されたIPパケットをtunl0ポートを介して物理マシン192.168.1.2に転送します。
• IPIPドライバーは、コンテナーから送信されたIPパケット（宛先アドレス10.233.1.2）を、物理ネットワークIPパケット（宛先アドレス192.168.1.2）のペイロードとして送信します。
• ホスト192.168.2.3は、物理ネットワークの送信モードに従って、物理ネットワークIPパケットをホスト192.168.1.2に送信します。
• IPパケットを受信した後、ホスト192.168.1.2のIPIPドライバーは、ペイロードを解凍して、IPパケットとしてコンテナー10.233.1.2に転送します。

したがって、物理ゲートウェイが仮想ネットワークのルーティングサービスを提供できないという前提の下で、CalicoはIPIPを使用してコンテナのサブネット間通信を解決することを選択しました。

何らかの方法で、物理ゲートウェイがCalico仮想ネットワークのルーティングルールを学習できれば、物理ゲートウェイは仮想ネットワークのルーティングサービスを提供でき、CalicoはIPIPを導入せずに、コンテナーのサブネット間通信を実現できますが、 、なぜCalicoはこの方法を選択しなかったのですか？

これは、Calicoの主なアプリケーションシナリオがパブリッククラウドであり、次の特徴があるためです。

• ほとんどのパブリッククラウドベンダーは、ホストが同じサブネットセグメントで動作できる、安定した大規模な2層環境を提供できるため、サブネット間の通信の問題は発生しません。
• すべてのパブリッククラウドベンダーがBGPルーティング学習インターフェイスを提供できるわけではありません。クラウドベンダーがBGPインターフェイスを提供しない場合、Calicoは仮想ネットワークルーティングルールをパブリッククラウドに同期できません。

したがって、この前提の下で、CalicoのIPIPの選択は非常に合理的です。

プライベートクラウドシナリオの場合：

• すべてのプライベートクラウド環境が第2層をサポートしているわけではなく、Calicoクロスサブネット通信の需要は非常に強いです。
• すべてのハードウェア（ゲートウェイを含む）は制御可能な範囲内にあります。物理ゲートウェイがBGPプロトコルをサポートしている限り、Calicoはルーティングルールを物理ゲートウェイに同期できます。

したがって、プライベートクラウドのシナリオでは、Calicoに仮想ネットワークルーティングルールを物理ゲートウェイに同期させることで、サブネット間の通信を解決することをお勧めします。

パフォーマンス改善プログラム

実際、Calicoのドキュメントには、ルーティングルールを物理ゲートウェイに同期する方法が記載されています。詳細については、次のリンクを参照してください。

https://docs.projectcalico.org/v2.6/usage/external-connectivity

この記事では、この設計について言及し、仮想ネットワークのルーティングルールを物理ゲートウェイに同期します。仮想ネットワークと物理ネットワークの間にBGPネイバーを確立するには、次の2つの方法があります。

• 解決策1：各ノードは物理ゲートウェイを使用してBGPネイバーを確立します
• 解決策2：集中化されたコンポーネントは、物理ゲートウェイを使用してBGPネイバーを確立します

次の2つのシナリオが分析されます。

オプション1

次の図に示すように、ソリューション1では、各SDNノードが物理ゲートウェイでBGPネイバーを確立する必要があります。各SDNノードはローカルコンテナのゲートウェイとして機能するため、物理マシンで実行されているCalicoサービスが物理ゲートウェイとBGPを確立し、独自のルーティングルールを物理ゲートウェイに同期できる場合、物理ゲートウェイは仮想ネットワークのルーティングルールを学習できます。 。

ノードで実行されているSDNサービスは、コーディングまたはスクリプトを介してBGPネイバーを自動的に確立するロジックを実現できますが、これには物理ゲートウェイのサポートも必要です。物理ゲートウェイがBGPネイバーの自動確立をサポートしていない場合、SDN側でのみ実装しても意味がありません。

従来のBGPルーターは、BGPネイバーを1つずつ構成する必要があります。これは、コンテナー化されたクラスターには受け入れられません。コンテナ化されたクラスタの規模は一般に比較的大きいため、ノードは、拡張、縮小、マシン障害など、クラスタの使用中に調整されることがよくあります。ノードを調整するたびに、運用と保守によって手動でBGPネイバーの構成を完了する必要がある場合、運用と保守のコストが莫大であり、誤操作によってクラスターの安定性に影響を与えやすいため、ゲートウェイはBGPネイバーの自動確立をサポートする必要があります。

BGPネイバーの自動確立を実現するには、ダイナミックネイバー機能をサポートするルーターが必要です。従来のルーターは、BGPネイバーを構成するときに、明確なIPアドレスを指定する必要があります。ダイナミックネイバーをサポートするルーターは、IPネットワークセグメントを指定でき、ルーターは、指定されたネットワークセグメント内のBGPデバイスによって開始されたネイバーを確立する要求を自動的に受け入れることができます。

クラスターを展開する前に、ルーターの動的ネイバーを構成します。クラスターノードを調整する場合、ノードで実行されているSDNサービスは、BGPネイバーをアクティブに確立し、ノードのルーティング情報を物理ゲートウェイに同期します。たとえば、物理マシン192.168.1.2で実行されているSDNサービスは、物理ゲートウェイ192.168.1.1とのBGPネイバー（eBGP）を自動的に確立し、次のルーティングルールを物理ゲートウェイに同期します。

10.233.1.0/24 192.168.1.2 eth0

物理ゲートウェイ192.168.1.1が上記のルールを学習すると、BGPまたはその他のルーティング同期プロトコルを介して物理ゲートウェイ192.168.2.1に同期されます。これにより、物理ネットワーク全体が上記のルールを学習できます。クラスターコンテナが10.233.1.0/24ネットワークセグメントにデータを送信する場合、ホストマシンを介してデータパケットを物理ゲートウェイに直接送信し、物理ゲートウェイは学習した仮想ネットワークルーティング情報に従ってデータパケットをターゲットホストに転送できます。最後にターゲットホストによって対応するコンテナに転送されます。

オプションII

ソリューション2では、この記事ではBGPスピーカーと呼ばれる集中型コンポーネントを導入する必要があります。そのネットワーク構造は次のとおりです。

BGPスピーカーはSDNクラスターで実行されます。SDNクラスターでルーティング情報を収集し、BGPを介して物理ゲートウェイに同期します。このモジュールはSDNクラスター内のすべてのルーティング情報を収集できるため、各SDNノードが物理ゲートウェイと個別にBGPネイバーを確立する必要がなくなり、物理ゲートウェイの動的ネイバー機能に依存しなくなります。

下の図に示すように、BGPスピーカーは主にオブザーバーとパブリッシャーの2つの部分に分かれています。

• オブザーバー：SDNクラスターのルーティング情報を収集する責任があります。
• パブリッシャー：オブザーバーによって収集されたルーティング情報を物理ゲートウェイに同期します。
  

CalicoはSDNクラスター関連情報（構成情報、各ノードの仮想ネットワークセグメントなど）をetcdに保存し、etcdは監視をサポートしているため、監視者は監視を通じてCalicoクラスターノード情報をリアルタイムで取得できます。オブザーバーは、主に各SDNノードで分割された仮想ネットワークセグメント情報に注目し、取得した仮想ネットワークセグメント情報に基づいて対応するルーティングルールを生成します。たとえば、ノード192.168.1.2で分割された仮想ネットワークセグメントは10.233.1.0/24であり、オブザーバーは以下を生成します。ルーティングルール：

10.233.1.0/24 192.168.1.2 eth0

パブリッシャーはBGPプロトコルを実装し、物理ゲートウェイとのBGPネイバー（eBGP）を確立します。主な仕事は、オブザーバーによって収集されたルーティング情報を物理ゲートウェイに同期することです。パブリッシャーはさまざまなノードのルーティング情報を物理ゲートウェイに同期する必要があるため、パブリッシャーは実際には物理ゲートウェイのBGPルートリフレクターです。

gobgpは、オープンソースのBGPプロトコルライブラリを提供し、完全なBGPプロトコルをサポートし、パブリッシャーの基本ライブラリとして使用できます。さらに、BGPは双方向です。パブリッシャーは、保持しているルーティング情報を物理ルーターに同期できるだけでなく、物理ルーターもルーティング情報をパブリッシャーに同期できます。SDNは物理ネットワークのルーティング情報を知る必要がないため、パブリッシャーはこれらをフィルターで除外できます。ルーティング情報。

BGPスピーカーは一元的に展開されるため、BGP Spakerの高可用性は、SDNクラスターの安定性に直接影響します。BGPスピーカーはSDNクラスターのetcdストレージから直接クラスター情報を取得します。データ（生成されたルーティング情報を含む）を保存する必要はありません。したがって、BGPスピーカーはステートレスです。したがって、複数セットのBGPスピーカーのみをSDNクラスターにデプロイする必要があります。高可用性を実現できます。

複数のBGPスピーカーのセットは相互に認識せず、独立して動作します。BGPスピーカーを展開する場合、物理ネットワークのトポロジに応じて、BGPスピーカーをさまざまなラックまたはコンピュータールームに展開して、ラックまたはコンピュータールームに障害が発生した場合でもSDNクラスターが正常に機能するようにすることもできます。

セキュリティリスク

上記の2つのスキームはどちらも、物理ネットワークと仮想ネットワーク間の相互通信を実現できます。ただし、どちらのスキームでも、仮想ネットワークは、BGPプロトコルを介してルーティングルールを物理ゲートウェイに自動的に同期します。仮想ネットワークが誤ったルーティングルールを生成した場合、または生成されたルーティングルールが物理ネットワークの競合は、クラスターが配置されている物理ネットワークの動作ステータスに影響します。複数のSDNクラスターのセットが同じ物理ネットワークに展開され、これらの複数のSDNセットのネットワークセグメントが競合すると、仮想ネットワークのルーティングルールも乱れ、影響を受けます。 SDNの安定性。

したがって、SDN間、およびSDNと物理ネットワーク間で競合が発生しないようにするために、いくつかの対策を講じる必要があります。

SDNが物理ネットワークと競合しないことを確認します

現在の物理ゲートウェイのほとんどはルートフィルタリングをサポートしています。つまり、ゲートウェイがBGPを介して新しいルーティングルールを学習すると、特定のルールに従ってフィルタリングできます。要件を満たすルーティングルールのみが独自のルーティングテーブルに同期されます。コンテナ化されたクラスタを展開するときは、最初にSDNネットワークアドレスを計画し、SDNネットワークアドレスが物理ネットワークと競合しないようにする必要があります。

物理ゲートウェイを構成するときに、SDNが所属するネットワークセグメント外のルーティングルールを変更できないようにフィルタリングルールを設定し（たとえば、SDNを制限して、10.233.0.0 / 16ネットワークセグメントの宛先アドレスでルーティングルールのみを更新する）、パスすることができます。このようにして、SDNが物理ネットワークの安定性に影響を与えないようにすることができます。

SDN間に競合がないことを確認します

物理ネットワークと仮想ネットワークが相互接続された後、同じ物理ネットワークに配置された複数のSDNクラスターのルーティング情報が物理ゲートウェイに同期されます。異なるSDNのネットワークアドレスが重複すると、競合が発生し、SDNネットワークが安定して動作できなくなります。したがって、SDNクラスターを展開するときは、異なるSDNクラスターに異なるネットワークアドレスを割り当てる必要もあります（これらのアドレスは物理ネットワークと競合しません）。ゲートウェイを構成するときは、各SDNを制限して、独自のネットワークアドレスのルーティングルールのみを同期します。

総括する

Calicoのパフォーマンスの問題の根本的な原因は、物理ネットワークと仮想ネットワークが相互運用できないことです。この記事では、物理ネットワークと仮想ネットワーク間の相互通信を実現するための2つのソリューションを設計しました。これにより、CalicoによるIPIPとNATの導入によって引き起こされるパフォーマンスの問題が解決され、ただし、セキュリティリスクは、物理ネットワークとSDNネットワークの安定した運用を確保するための追加の保護手段によって排除できます。

この記事の著者であるLiLianrongは、再版のためのソース、技術的独創性、およびアーキテクチャの実践記事を示してください。公式アカウントメニュー「お問い合わせ」から記事を送信することを歓迎します。

推奨読書

• 大規模なコンテナ化されたプラットフォームでのロギングにおけるMeituの実践（1）モデル選択の考え方
• Meituインターネットテクノロジーサロ​​ンは深センに強く上陸しました：Meituのバックエンド技術アーキテクチャに関する15億人のユーザーの経験を共有します
• ディディトラベルの実践から大中規模のプラットフォームを構築する方法について話しましょう
• HTTPS環境でのDNS最適化について話す：Meituアプリのリクエストには時間がかかり、ほぼ半分のケース

利用性の高いアーキテクチャ

インターネットの構築方法を変える