メイン コンテンツにスキップ

 Subscribe

2022 年 12 月に、Microsoft Azure のクラウドネイティブ アプリケーション向けに次世代の拡張されたバークレイ パケット フィルター (eBPF) データプレーンを導入するために Isovalent とのパートナーシップを発表し、次世代の Azure Container Network Interface (CNI) データプレーンが eBPF と Cilium を搭載することが明らかになりました。

本日、Cilium を搭載した Azure CNI の一般提供についてお知らせします。Cilium を利用する Azure CNI は、2 つの強力なテクノロジを組み合わせた次世代のネットワーク プラットフォームです。Azure Virtual Network スタックと統合されたスケーラブルで柔軟なポッド ネットワーク制御のための Azure CNI と 、Kubernetes のネットワーク、セキュリティ、および可観測性に eBPF を利用するデータ プレーンを利用するオープンソース プロジェクトである Cilium。Cilium を利用した Azure CNI では、ゲスト仮想マシン内の Cilium のダイレクト ルーティング モードを利用し、Azure ネットワーク内の Azure ネイティブ ルーティングと組み合わせることで、Azure Kubernetes Service (AKS) クラスターにデプロイされたワークロードのネットワーク パフォーマンスが向上し、ネットワーク セキュリティを適用するための組み込みのサポートが可能になります。

このブログでは、Azure Kubernetes Service のこの強力なネットワーク オファリングを通じて実現されるパフォーマンスとスケーラビリティの結果についてさらに詳しく説明します。

パフォーマンスとスケールの結果

パフォーマンス テストは、重負荷条件下でシステムの動作を分析し、パフォーマンスを評価するために、オーバーレイ モードAKS クラスターで実行されます。これらのテストは、大規模な同時要求や高いワークロードなど、クラスターに高レベルのリソース使用率が適用されるシナリオをシミュレートします。目標は、応答時間、スループット、スケーラビリティ、リソース使用率などのさまざまなパフォーマンス メトリックを測定して、クラスターの動作を理解し、パフォーマンスのボトルネックを特定することです。

サービス ルーティングの待機時間

この実験では、AKS クラスターで Standard D4 v3 SKU ノードプール (16 GB mem、4 vCPU) を利用しました。Web サーバーのベンチマークとロード テストに一般的に使用される apachebench ツールは、サービス ルーティングの待機時間を測定するために使用されました。合計 50,000 件の要求が生成され、全体的な完了時間について測定されました。Cilium と kube-proxy を利用した Azure CNI のサービス ルーティング待機時間は、ポッドの数が 5000 に達するまで、最初は同様のパフォーマンスを示すことが確認されています。このしきい値を超えると、kube-proxy ベースのクラスターのサービス ルーティングの待ち時間は増加し始めますが、Cilium ベースのクラスターの待機時間レベルメイン維持されます。

特に、16,000 個のポッドにスケールアップする場合、Cilium クラスターを利用する Azure CNI は、kube プロキシ クラスターと比較してサービス ルーティングの待機時間が 30% 短縮され、大幅な改善を示しています。これらの結果は、eBPF ベースのサービス ルーティングが、kube-proxy で使用される IPTables ベースのサービス ルーティングと比較して大規模にパフォーマンスが向上することを再確認します。

サービス ルーティングの待機時間 (秒単位)

Service routing latency in seconds with single service and different number of pods in backend.
1 つのサービスとバックエンドのポッド数が異なるサービス ルーティングの待機時間 (秒単位)。

テスト パフォーマンスのスケーリング

スケール テストは、Standard D4 v3 SKU ノードプール (16 GB mem、4 vCPU) を利用して、Cilium Azure Kubernetes Service クラスターを搭載した Azure CNI で行われました。テストの目的は、大規模な条件下でクラスターのパフォーマンスを評価することでした。テストでは、中央処理装置 (CPU) とノードのメモリ使用量のキャプチャと、API サーバーと Cilium の負荷の監視に重点を置いていました。

テストには 3 つの異なるシナリオが含まれています。それぞれが、さまざまな条件下でクラスターのパフォーマンスのさまざまな側面を評価するように設計されています。

ネットワーク ポリシーのない 100k ポッドでテストをスケーリングする

スケール テストは、1,000 個のノードと合計 100,000 個のポッドで構成されるクラスターで実行されました。テストは、ネットワーク ポリシーと Kubernetes サービスをデプロイせずに行われました。

スケール テスト中にポッドの数が 20K から 100K に増加すると、Cilium エージェントの CPU 使用率は一貫して低くメイン 100 ミリコアを超えず、メモリは約 500 MiB です。

Average CPU utilization in Millicore by cilium agent pods for creating different number of pods without network policies and services.
100k ポッドを作成するための Cilium 平均 CPU 使用率。
Average Memory utilization in Mebibytes by cilium agent pods for creating different number of pods without network policies and services.
100,000 個のポッドを作成するための Cilium の平均メモリ使用量。

2k ネットワーク ポリシーを使用して 100,000 ポッドでテストをスケーリングする

スケール テストは、1K ノードと合計 100K ポッドで構成されるクラスターで実行されました。テストには 2K ネットワーク ポリシーのデプロイが含まれていましたが、Kubernetes サービスは含まれていませんでした。

Cilium エージェントの CPU 使用率はメイン 150 ミリコア以下で、メモリは約 1 GiB です。これにより、Cilium メインネットワーク ポリシーの数が 2 倍になったにもかかわらず、オーバーヘッドが低いことが示されました。

Average CPU utilization in Millicore by cilium agent pods for creating different number of pods with 2k network policies and without services.
100,000 個のポッド、2,000 個のネットワーク ポリシーを作成するための Cilium 平均 CPU 使用率。
Average CPU utilization in Millicore by cilium agent pods for creating different number of pods with 2k network policies and without services.
100,000 個のポッド、2,000 個のネットワーク ポリシーを作成するための Cilium の平均メモリ使用量。

60,000 個のポッド バックエンドと 2,000 個のネットワーク ポリシーを使用した 1k サービスによるスケール テスト

このテストは、1K ノードと 60K ポッドで実行され、それぞれに 60 個のポッドが関連付けられている 2K ネットワーク ポリシーと 1K サービスが伴います。

Cilium エージェントの CPU 使用率はメイン約 200 ミリコアで、メモリは約 1 GiB でメイン。これは、多数のサービスがデプロイされた場合でも Cilium が引き続きメイン低いオーバーヘッドを維持していることを示しています。eBPF 経由のサービス ルーティングは、アプリケーションの待機時間を大幅に短縮し、インフラストラクチャ 層でのオーバーヘッドが非常に少ないことがわかります。

Average CPU utilization in Millicore by cilium agent pods after for 1k services different number of backend pods and with 2k network policies.
60,000 個のポッド バックエンド、2,000 個のネットワーク ポリシーを使用して 1k のサービスを作成するための Cilium 平均 CPU 使用率。
Average Memory utilization in Mebibytes by cilium agent pods for creating 1k services with different number of backend pods and with 2k network policies.
60,000 個のポッド バックエンド、2,000 個のネットワーク ポリシーを使用して 1k サービスを作成するための Cilium の平均メモリ使用量。

Cilium を利用した Azure CNI の概要

上記の結果からわかるように、Cilium の eBPF データプレーンを使用する Azure CNI は最もパフォーマンスが高く、ノード、ポッド、サービス、およびネットワーク ポリシーを使用してはるかに優れたスケーリングを行い、オーバーヘッドを低く抑えます。この製品オファリングは、Azure Kubernetes Service (AKS) で一般公開され、CNI のオーバーレイ モードと VNET モードの両方で動作します。Cilium を利用した Azure CNI をお試しになり、AKS 環境でメリットを体験できるようお待ちしています。

今すぐ開始するには、Cilium を利用した Azure CNI で入手できる ドキュメントを参照してください。

  • Explore

     

    Let us know what you think of Azure and what you would like to see in the future.

     

    Provide feedback

  • Build your cloud computing and Azure skills with free courses by Microsoft Learn.

     

    Explore Azure learning


Join the conversation