Kubernetesクラスタにおける高性能ネットワークポリシー
7月にKubernetes 1.3がリリースされて以来、ユーザーはクラスタ内でネットワークポリシーを定義し、実装することができます.これらのポリシーは、流入および流出を許可するデータ型を指定するファイアウォールルールです.必要に応じて、Kubernetesは、明確に許可されていないすべてのトラフィックを阻止することができる.本稿では、K 8 sのネットワークポリシーについて説明し、ネットワークのパフォーマンスをテストします.
ネットワークポリシー
K 8 sのネットワークポリシーは、共通ラベルで識別されるpodグループに適用される.次に、ラベルを使用して従来のセグメントネットワークをシミュレートできます.これらのネットワークは、通常、多層アプリケーションでレイヤを分離するために使用されます.たとえば、特定のセグメントラベルでフロントエンドpodとバックエンドpodを識別できます.ポリシーは、これらのセグメント間のトラフィックを制御し、外部ソースからのトラフィックを制御します.
ぶんかつりゅうりょう
これはアプリケーション開発者にとって何を意味しますか?最後に,Kubernetesは深い防御を提供するために必要な能力を得た.トラフィックはセグメント化でき、アプリケーションの異なる部分は独立して保護できます.たとえば、サーバの後にあるReplication Controlによって識別されるすべてのペインが特定のラベルによって識別されている特定のネットワークポリシーによって、各サービスを簡単に保護できます.したがって、これらのpodにポリシーを適用するには、同じラベルを使用します.
長い間,深さ防御は最良の実践として提案されてきた.AWSとOpenStackでは、セキュリティグループをVMに適用することで、アプリケーションの異なる部分やレイヤ間のこのような分離を容易に実現できます.
しかしながら、ネットワークポリシーの前に、このような容器の分離は不可能である.VXLANオーバーライドは簡単なネットワーク分離を提供することができるが、アプリケーション開発者はトラフィックアクセスpodをより細かく制御する必要がある.この簡単な例から、Kubernetesネットワークポリシーは、ソース、プロトコル、およびポートに基づいてトラフィックを管理できることがわかります.
すべてのネットワークバックエンドがポリシーをサポートしているわけではありません
ネットワーク戦略はワクワクする機能であり、Kubernetesコミュニティは長い間働いています.しかし、ポリシーを適用できるネットワークバックエンドが必要です.たとえば、単純なルーティングネットワークや一般的なflannelネットワークプログラム自体は、ネットワークポリシーを適用できません.
今日Kubernetesには、Romana、Calico、Canalというポリシー機能を持つネットワークコンポーネントがいくつかしかありません.Weaveと近い将来サポートを指示します.Red HatのOpenShiftには、ネットワークポリシー機能も含まれています.
これらのテストのバックエンドとしてRomanaを選択したのは、podが完全なL 3構成でローカルルーティング可能なIPアドレスを使用するように構成されているためである.したがって、ネットワークポリシーは、Linuxカーネル内のホストがiptablesルールを使用して直接適用することができる.この結果は,高性能で管理しやすいネットワークである.
ネットワークポリシーのパフォーマンスの影響をテスト
ネットワークポリシーを適用した後、これらのポリシーに基づいてネットワークパケットをチェックして、このタイプのビジネスが許可されていることを検証する必要があります.しかし、パケットごとにネットワークポリシーを適用するパフォーマンスの損失はいくらですか?アプリケーションのパフォーマンスに影響を与えることなく、すべてのポリシー機能を使用できますか?いくつかのテストを実行して見つけることにしました.
これらのテストを深く研究する前に、「パフォーマンス」は特にネットワークのパフォーマンスを測定するのに困難であることに注目してください.スループット(すなわちGpbsで測定されたデータ伝送速度)と遅延(要求完了時間)は、ネットワーク性能の一般的なメトリックである.記事:K 8 sネットワーク遅延と比較k 8 sのネットワークスキームは、スループットと遅延に及ぼすオーバーライドネットワークの実行のパフォーマンスに及ぼす影響を調べた.これらのテストから学んだのは、Kubernetesネットワークが通常かなり速く、サーバが1 Gリンクを飽和させたり、上書きしたりしていないことです.10 Gネットワークがある場合だけ、パッケージのコストを考える必要があります.
これは、一般的なネットワークパフォーマンスベンチマークテストの間、ホストCPUが実行するアプリケーションロジックがなく、必要なネットワーク処理に使用できるためです.**この目的のために,リンクやCPUを飽和させない動作範囲で我々のテストを実行した.これは、ネットワークポリシー規則がホストに与える影響を分離処理する効果があります.**これらの試験について,一連の応答サイズ範囲内でHTTP要求を完了するのに要する平均時間によって測定される遅延を決定した.
テスト手順:
ハードウェア
2台のサーバーはIntelCore i 5-5250 U CPU(2コア、1コアあたり2スレッド)、運行速度1.60 GHz、16 GBRAM、512 GB SSDを採用している. NIC:Intelイーサネット接続I 218-V(rev 03) Ubuntu14.04.5 Kubernetes 1.3(v 1.4.0-beta.5の検証サンプル) Romana v0.9.3.1 クライアントおよびサーバ負荷テストソフトウェア.
テストでは、クライアントpodがサーバpodに2000個のHTTPリクエストを送信します.HTTP要求はクライアントpodによってサーバとネットワークの両方が飽和していない速度で送信される.また、HTTPのKeep-aliveなどの永続接続を無効にすることによって、各リクエストが新しいTCPセッションを開始することを保証します.各テストを異なる応答サイズで実行し,平均要求持続時間(このサイズの要求を完了するのにどれくらいの時間がかかるか)を測定した.最後に,異なるポリシー構成で各グループの測定を繰り返す.
Romanaは、Kubernetesネットワークポリシーの作成を検出すると、それをRomana独自のポリシーフォーマットに変換し、すべてのホストに適用します.現在、Kubernetesネットワークポリシーはエントリトラフィックにのみ適用されています.これは、伝達された流量が影響を受けないことを意味する.
まず,ベースラインを構築するためのポリシーのないテストを行った.次に、テストを再実行し、テストセグメントのポリシー数を増やします.ポリシーは、一般的なプロトコルとポートのトラフィックを許可するフォーマットです.パケットがすべてのポリシーを巡回する必要があることを確認するために、パケットに一致しないポリシーを作成しました.最後に、パケットを受け入れるポリシーになります.
次の表に、異なるリクエスト・サイズとポリシー数の結果をミリ秒単位で示します.
ここでは,200個のポリシーを適用した後でも,処理ネットワークポリシーには0.2 msを超えることなく非常に小さな遅延が導入されることを示した.すべての実際の目的のために、ネットワークポリシーが適用される場合、有意義な遅延は導入されない.また,応答サイズを0.5 kから1.0 kに増加させることはほとんど効果的ではないことに注目すべきである.これは、非常に小さな応答に対して、新しい接続を作成する固定オーバーヘッドが、全体的な応答時間(すなわち、同じ数のパケットを転送する)を支配するためである.
注意:0.5 kと1 k線は上の図の中の〜.8 msが重なる
ベンチマーク性能のパーセントとしても、影響は小さい.次の表に、最小応答サイズの場合、最悪の場合の遅延は7%以下、最大200ポリシーに維持されます.大きな応答サイズでは、遅延は約1%に低下した.
これらの結果においてさらに興味深いことに、ポリシーの数が増加するにつれて、より大きなリクエストは、比較的小さい(すなわち、パーセント)パフォーマンスの劣化を経験することに気づいた.
これは、Romanaがiptablesルールをインストールすると、接続が確立されたパケットに属していることを最初に評価するためです.接続された最初のパケットの完全なポリシーリストのみを巡回する必要があります.その後、接続は「確立」され、接続のステータスはクイックルックアップテーブルに格納されます.したがって、大きなリクエストの場合、接続されているほとんどのパケットは、すべてのルールを完全に巡回するのではなく、「確立済み」テーブルで迅速に検索されます.このiptables最適化結果の性能は,ネットワークポリシーの数と大きく独立している.
このような「フローテーブル」は、iptablesが同じ技術を使用するのにかなり有効であるように、ネットワークデバイスで一般的な最適化である.
また、実際には、かなり複雑なアプリケーションが各セグメントにいくつかのルールを構成できることにも注目してください.同様に、Websocketsや永続接続などのパブリックネットワーク最適化技術は、接続がより長く維持されるため、確立された接続最適化から利益を得ることができるため、特に小さなリクエストサイズの場合、ネットワークポリシーのパフォーマンスをさらに向上させることができる.
これらのテストはRomanaをバックエンドポリシープロバイダとして使用して実行され、他のネットワークポリシー実装では異なる結果が得られる可能性があります.しかし、これらのテストでは、ほとんどのアプリケーションの導入状況で、パフォーマンスに悪影響を及ぼすことなく、Romanaをネットワークバックエンドアプリケーションネットワークポリシーとして使用できることが明らかになりました.
自分でやってみたいなら、Romanaを使うことをお勧めします.GitHubコードウェアハウスでは、AWS、Vagrant VM、または他のサーバと組み合わせて使用される使いやすいインストーラを見つけることができます.
まとめ
以上の機能紹介と試験分析により、k 8 sは、応用間の流量をより小さな粒子度で制御することができる.ネットワークのパフォーマンス損失は許容範囲内です.
好雨雲が現在の生産環境に役立つのはk 8 s 1.2である.xバージョンでは、バージョンを使用するときにk 8 sはまだネットワークポリシー制御の機能を持っていないので、ネットワークプラグインに基づいてアクセス制御を実現しています.
私たちはk 8 s 1.3を行っています.xバージョンの本番環境のパフォーマンスと互換性テストは、その後、すべてのエンタープライズ・バージョンをアップグレードし、コミュニティ・バージョンはエンタープライズ・バージョンのアップグレード後の月25日にアップグレードされます.
その後、calicoとk 8 sを結合する方法について、ネットワーク相互接続とネットワークの隔離制御を完了し、性能の損失をテスト分析し、今後の文章ではテストの状況を皆さんと共有し、議論します.
本論文では,オープンソース中国−Kubernetesクラスタにおける高性能ネットワーク戦略を移行する
ネットワークポリシー
K 8 sのネットワークポリシーは、共通ラベルで識別されるpodグループに適用される.次に、ラベルを使用して従来のセグメントネットワークをシミュレートできます.これらのネットワークは、通常、多層アプリケーションでレイヤを分離するために使用されます.たとえば、特定のセグメントラベルでフロントエンドpodとバックエンドpodを識別できます.ポリシーは、これらのセグメント間のトラフィックを制御し、外部ソースからのトラフィックを制御します.
ぶんかつりゅうりょう
これはアプリケーション開発者にとって何を意味しますか?最後に,Kubernetesは深い防御を提供するために必要な能力を得た.トラフィックはセグメント化でき、アプリケーションの異なる部分は独立して保護できます.たとえば、サーバの後にあるReplication Controlによって識別されるすべてのペインが特定のラベルによって識別されている特定のネットワークポリシーによって、各サービスを簡単に保護できます.したがって、これらのpodにポリシーを適用するには、同じラベルを使用します.
長い間,深さ防御は最良の実践として提案されてきた.AWSとOpenStackでは、セキュリティグループをVMに適用することで、アプリケーションの異なる部分やレイヤ間のこのような分離を容易に実現できます.
しかしながら、ネットワークポリシーの前に、このような容器の分離は不可能である.VXLANオーバーライドは簡単なネットワーク分離を提供することができるが、アプリケーション開発者はトラフィックアクセスpodをより細かく制御する必要がある.この簡単な例から、Kubernetesネットワークポリシーは、ソース、プロトコル、およびポートに基づいてトラフィックを管理できることがわかります.
apiVersion: extensions/v1beta1 kind: NetworkPolicy metadata:
name: pol1
spec:
podSelector:
matchLabels:
role: backend
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: tcp
port: 80
すべてのネットワークバックエンドがポリシーをサポートしているわけではありません
ネットワーク戦略はワクワクする機能であり、Kubernetesコミュニティは長い間働いています.しかし、ポリシーを適用できるネットワークバックエンドが必要です.たとえば、単純なルーティングネットワークや一般的なflannelネットワークプログラム自体は、ネットワークポリシーを適用できません.
今日Kubernetesには、Romana、Calico、Canalというポリシー機能を持つネットワークコンポーネントがいくつかしかありません.Weaveと近い将来サポートを指示します.Red HatのOpenShiftには、ネットワークポリシー機能も含まれています.
これらのテストのバックエンドとしてRomanaを選択したのは、podが完全なL 3構成でローカルルーティング可能なIPアドレスを使用するように構成されているためである.したがって、ネットワークポリシーは、Linuxカーネル内のホストがiptablesルールを使用して直接適用することができる.この結果は,高性能で管理しやすいネットワークである.
ネットワークポリシーのパフォーマンスの影響をテスト
ネットワークポリシーを適用した後、これらのポリシーに基づいてネットワークパケットをチェックして、このタイプのビジネスが許可されていることを検証する必要があります.しかし、パケットごとにネットワークポリシーを適用するパフォーマンスの損失はいくらですか?アプリケーションのパフォーマンスに影響を与えることなく、すべてのポリシー機能を使用できますか?いくつかのテストを実行して見つけることにしました.
これらのテストを深く研究する前に、「パフォーマンス」は特にネットワークのパフォーマンスを測定するのに困難であることに注目してください.スループット(すなわちGpbsで測定されたデータ伝送速度)と遅延(要求完了時間)は、ネットワーク性能の一般的なメトリックである.記事:K 8 sネットワーク遅延と比較k 8 sのネットワークスキームは、スループットと遅延に及ぼすオーバーライドネットワークの実行のパフォーマンスに及ぼす影響を調べた.これらのテストから学んだのは、Kubernetesネットワークが通常かなり速く、サーバが1 Gリンクを飽和させたり、上書きしたりしていないことです.10 Gネットワークがある場合だけ、パッケージのコストを考える必要があります.
これは、一般的なネットワークパフォーマンスベンチマークテストの間、ホストCPUが実行するアプリケーションロジックがなく、必要なネットワーク処理に使用できるためです.**この目的のために,リンクやCPUを飽和させない動作範囲で我々のテストを実行した.これは、ネットワークポリシー規則がホストに与える影響を分離処理する効果があります.**これらの試験について,一連の応答サイズ範囲内でHTTP要求を完了するのに要する平均時間によって測定される遅延を決定した.
テスト手順:
ハードウェア
2台のサーバーはIntelCore i 5-5250 U CPU(2コア、1コアあたり2スレッド)、運行速度1.60 GHz、16 GBRAM、512 GB SSDを採用している.
テストでは、クライアントpodがサーバpodに2000個のHTTPリクエストを送信します.HTTP要求はクライアントpodによってサーバとネットワークの両方が飽和していない速度で送信される.また、HTTPのKeep-aliveなどの永続接続を無効にすることによって、各リクエストが新しいTCPセッションを開始することを保証します.各テストを異なる応答サイズで実行し,平均要求持続時間(このサイズの要求を完了するのにどれくらいの時間がかかるか)を測定した.最後に,異なるポリシー構成で各グループの測定を繰り返す.
Romanaは、Kubernetesネットワークポリシーの作成を検出すると、それをRomana独自のポリシーフォーマットに変換し、すべてのホストに適用します.現在、Kubernetesネットワークポリシーはエントリトラフィックにのみ適用されています.これは、伝達された流量が影響を受けないことを意味する.
まず,ベースラインを構築するためのポリシーのないテストを行った.次に、テストを再実行し、テストセグメントのポリシー数を増やします.ポリシーは、一般的なプロトコルとポートのトラフィックを許可するフォーマットです.パケットがすべてのポリシーを巡回する必要があることを確認するために、パケットに一致しないポリシーを作成しました.最後に、パケットを受け入れるポリシーになります.
次の表に、異なるリクエスト・サイズとポリシー数の結果をミリ秒単位で示します.
ここでは,200個のポリシーを適用した後でも,処理ネットワークポリシーには0.2 msを超えることなく非常に小さな遅延が導入されることを示した.すべての実際の目的のために、ネットワークポリシーが適用される場合、有意義な遅延は導入されない.また,応答サイズを0.5 kから1.0 kに増加させることはほとんど効果的ではないことに注目すべきである.これは、非常に小さな応答に対して、新しい接続を作成する固定オーバーヘッドが、全体的な応答時間(すなわち、同じ数のパケットを転送する)を支配するためである.
注意:0.5 kと1 k線は上の図の中の〜.8 msが重なる
ベンチマーク性能のパーセントとしても、影響は小さい.次の表に、最小応答サイズの場合、最悪の場合の遅延は7%以下、最大200ポリシーに維持されます.大きな応答サイズでは、遅延は約1%に低下した.
これらの結果においてさらに興味深いことに、ポリシーの数が増加するにつれて、より大きなリクエストは、比較的小さい(すなわち、パーセント)パフォーマンスの劣化を経験することに気づいた.
これは、Romanaがiptablesルールをインストールすると、接続が確立されたパケットに属していることを最初に評価するためです.接続された最初のパケットの完全なポリシーリストのみを巡回する必要があります.その後、接続は「確立」され、接続のステータスはクイックルックアップテーブルに格納されます.したがって、大きなリクエストの場合、接続されているほとんどのパケットは、すべてのルールを完全に巡回するのではなく、「確立済み」テーブルで迅速に検索されます.このiptables最適化結果の性能は,ネットワークポリシーの数と大きく独立している.
このような「フローテーブル」は、iptablesが同じ技術を使用するのにかなり有効であるように、ネットワークデバイスで一般的な最適化である.
また、実際には、かなり複雑なアプリケーションが各セグメントにいくつかのルールを構成できることにも注目してください.同様に、Websocketsや永続接続などのパブリックネットワーク最適化技術は、接続がより長く維持されるため、確立された接続最適化から利益を得ることができるため、特に小さなリクエストサイズの場合、ネットワークポリシーのパフォーマンスをさらに向上させることができる.
これらのテストはRomanaをバックエンドポリシープロバイダとして使用して実行され、他のネットワークポリシー実装では異なる結果が得られる可能性があります.しかし、これらのテストでは、ほとんどのアプリケーションの導入状況で、パフォーマンスに悪影響を及ぼすことなく、Romanaをネットワークバックエンドアプリケーションネットワークポリシーとして使用できることが明らかになりました.
自分でやってみたいなら、Romanaを使うことをお勧めします.GitHubコードウェアハウスでは、AWS、Vagrant VM、または他のサーバと組み合わせて使用される使いやすいインストーラを見つけることができます.
まとめ
以上の機能紹介と試験分析により、k 8 sは、応用間の流量をより小さな粒子度で制御することができる.ネットワークのパフォーマンス損失は許容範囲内です.
好雨雲が現在の生産環境に役立つのはk 8 s 1.2である.xバージョンでは、バージョンを使用するときにk 8 sはまだネットワークポリシー制御の機能を持っていないので、ネットワークプラグインに基づいてアクセス制御を実現しています.
私たちはk 8 s 1.3を行っています.xバージョンの本番環境のパフォーマンスと互換性テストは、その後、すべてのエンタープライズ・バージョンをアップグレードし、コミュニティ・バージョンはエンタープライズ・バージョンのアップグレード後の月25日にアップグレードされます.
その後、calicoとk 8 sを結合する方法について、ネットワーク相互接続とネットワークの隔離制御を完了し、性能の損失をテスト分析し、今後の文章ではテストの状況を皆さんと共有し、議論します.
本論文では,オープンソース中国−Kubernetesクラスタにおける高性能ネットワーク戦略を移行する