Cilium High Performance Cloud Native Network

最近、Alibaba Cloud チームは SIG Cloud-Provider-Alibaba カンファレンスで Alibaba Cloud Container Service の新しい高性能コンテナネットワークソリューションを発表し、ブログで紹介しました。このソリューションが Cilium と eBPF をベースに実装されていることはご存知でしたか。これに先立ち、Google の GKE と Anthos も Cilium+eBPF をベースにした新しいコンテナネットワークデータプレーン V2 ソリューションの実装を発表しています。ただし、Alibaba Cloud のソリューションは異なります。Alibaba Cloud は Terway IPVLAN と Cilium の eBPF の組み合わせを採用しています。以下の記事では、Terway CNI（Alibaba Cloud の CNI プラグイン）の詳細な実装とブログのテストデータについて分析します。

他のクラウドベンダーと同様、Alibaba Cloud も ENI（Elastic Network Interface）製品を提供し、IaaS レイヤーの SDN（Software Defined Network）機能を活用できます。K8S の Pod に対して、クラウドネイティブな仮想化ネットワークを実現でき、コンテナネットワークに別の仮想化レイヤーを追加する必要がないため、パフォーマンス損失とネットワークの複雑性を軽減できます。

クラウドベンダーの IaaS レイヤーネットワークは既に仮想化と SDN の機能を備えています。そのため、Pod が基盤となる仮想化ネットワークの機能を直接使用すれば、パフォーマンス損失を大幅に削減できます。

Alibaba Cloud の場合、コンテナネットワークモデルは以下の図のようになります。

このモデルを実装するため、CNI レイヤーは Alibaba Cloud の API と直接連携し、Pod に必要な基盤 ENI ネットワークリソースを申請します。Alibaba Cloud はこのようなモデルを実装するために Terway CNI プラグインを開発しました。Alibaba Cloud の公式ブログには、内部実装と直面した課題に関する詳細な紹介があります。ここでは、IPVLAN と eBPF を使用して Kubernetes の Service と NetworkPolicy のパフォーマンスとスケーラビリティをどのように向上させているかに焦点を当てます。

IPVLAN を使用したより優れたネットワークスケーラビリティとパフォーマンス

単一の ENI を Pod に専有させることも、複数の Pod で共有することもできます。ENI が複数の Pod で共有される場合、Pod トラフィックが対応する ENI にルーティングされるように、パケットに対して一部のルーティング判断を行う必要があります。共有 ENI 方式を使用すると、1 つの ENI で 10〜20 個の IP を仮想化でき、ノード上の Pod のデプロイ密度を大幅に向上できます。ただし、ブリッジやポリシールーティングを導入する必要があるため、追加のパフォーマンスオーバーヘッドが発生するという欠点があります。具体的なオーバーヘッドは、後述のパフォーマンス比較で確認できます。

共有 ENI のパフォーマンスを向上させるため、IPVLAN は優れた選択肢です。IPVLAN は ENI を複数のサブインターフェースに軽量化し、複数の Pod を単一の ENI に接続できます。Terway CNI は IPVLAN を使用して共有 ENI のオーバーヘッドを削減し、IPVLAN ネットワークモードで効率的な NetworkPolicy と Service 実装を提供するために Cilium と組み合わせています。そして Cilium 公式にプルリクエストを提出しました。

以下は異なるモードのパフォーマンス比較で、クラウドネイティブ ENI ネットワークのパフォーマンス優位性とオーバーレイベースの Flannel も含まれています。

いずれか 1 つのモデルを選択する必要はありません。必要に応じて専有 ENI をスケジューリングして高性能を実現し、他の Pod には共有 ENI モードを使用できます。

**eBPF を使用した Kubernetes Service と NetworkPolicy のスケーラビリティ問題の解決**

長年、Kubernetes の標準的な kube-proxy 実装は iptables モードを採用してきました。iptables の順序マッチングにより、このソリューションのスケーラビリティは非常に限られています。

サービス数が一定のしきい値まで増加すると、遅延が大幅に増加することがわかります。さらに深刻なのは、iptables ルールチェーン内のサービステーブルエントリのマッチング順序が異なるため、サービスが最初にアクセスするパケットの遅延がランダムに変化することです。

これらの理由から、Alibaba Cloud は eBPF をベースに Kubernetes のスケーラビリティを最適化しました。

その効果は如何でしょうか。以下は Alibaba Cloud チームがテストしたパフォーマンス比較です。eBPF ベースのソリューションのネットワークパフォーマンスとスケーラビリティは、kube-proxy の iptables モードと IPVS モードよりも優れています。

eBPF によりリンクが簡略化され、パフォーマンスが大幅に向上しました。iptables モードと比較してパフォーマンスが 32% 向上し、IPVS モードと比較して 62% 向上しました。

Kubernetes Server と同様に、Kubernetes の NetworkPolicy も eBPF をベースに最適化できます。

ボックス内の「BPF エージェント」は Terway CNI とは独立して実行される Cilium エージェントで、Kubernetes Service と NetworkPolicy 実装を提供するために使用されます。

ノード上で Cilium を BPF エージェントとして使用し、コンテナ NIC の BPF ルールを設定し、Terway 関連の適応を貢献しました。

残念ながら、Alibaba Cloud はこの記事で最終的な最適化比較を提供しませんでした。Cilium チームは以前に IPVLAN モードと veth モードでの Cilium の比較ブログを作成しており、大まかな参考としてご利用いただけます。

まとめ

Alibaba Cloud が Cilium コミュニティに参加し貢献することを非常に嬉しく思い、歓迎します。詳細については、以下をご参照ください。
• Cilium の概要
• Cilium GitHub
• Alibaba Cloud が本番環境で高性能クラウドネイティブ Pod ネットワークをどのように構築しているか
• eBPF とは