Bottlerocket、Calico、eBPF で EKS ネットワークをターボチャージする

この投稿は、Tigera, Inc. の共同創設者兼 CTO である Alex Pollitt によって共同執筆されました。

先日、Amazon は Amazon Elastic Kubernetes Service (Amazon EKS) 上での Bottlerocket のサポートを発表しました。Bottlerocket は、セキュリティ、運用、および管理性を重視した、コンテナを大規模に実行するために Amazon が構築したオープンソースの Linux ディストリビューションです。Bottlerocket の詳細については、このアナウンスブログをご覧下さい。

Amazon EKS には、Amazon VPC CNI Plugin によって、Pod が VPC ルーティング可能な IP アドレスを持つことを可能にする優れたネットワーク機能が組み込まれています。この基本的なネットワーク機能に加えて、Network Policy のサポートが必要な場合、EKS は Calico をサポートしています。Amazon EKS のドキュメントで説明されているように、Calico は単一の kubectl コマンドで任意の EKS クラスターに追加できます。

では、Bottlerocket の EKS サポートによって何が変わるのでしょうか？フットプリントとリソース要件の削減に加えて、Bottlerocket は迅速なリリースサイクルも提供します。これは Bottlerocket が Linux カーネルで eBPF 機能をサポートする最初の EKS 最適化オペレーティングシステムの 1 つであることを意味します。Calico をこの基盤の上に構築することで、Network Policy のサポートを追加するだけでなく、EKS の基本的なネットワーク機能を強化することができます。このブログでは、ネットワークパフォーマンスの高速化、kube-proxy を実行する必要性の排除、クラスター外から Kubernetes Services にアクセスする際のクライアントのソース IP アドレスの保持などのメリットについて、詳しく、そしてなぜこれがエキサイティングなのかを見ていきます。

ネットワークパフォーマンスの高速化

Calico が eBPF をどのように利用しているかを詳細に説明する前に、このブログの文脈では、Calico は VPC CNI 上の追加のネットワーク機能レイヤーとして捉えられており、従来の Network Policy エンジンを超える機能を提供していることに注意してください。具体的には、EKS で Calico Network Policy エンジンをインストールするための標準的な手順では、eBPF モード GA よりも前のバージョンの Calico を使用しています。このブログでは、ガイド “Creating an EKS cluster for eBPF mode” で説明されているように、eBPF 対応の適切なバージョンの Calico をインストールするために、プレリリースマニフェストを使用します。

Calico が eBPF を使用して EKS のネットワークパフォーマンスをどのように高速化できるかを示すために、Calico チームは k8s-bench-suite に基づいて一連のネットワークパフォーマンスベンチマークを実行しました。このテストでは、AWS が提供する Bottlerocket AMI を使用したノードを使用して、最新の Calico eBPF 対応リリースと普通の EKS クラスターを比較しました。

テスト構成

ベンチマークでは、基盤となる AWS クラウドネットワークがボトルネックとなるリスクがないことを確実にするために、すべてのテストは、最大 100Gbps のネットワーク帯域幅に達することができる c5n.metal ノードを使用して実行されました。各ベンチマークでは、10Gbps のトラフィックを駆動するのに必要な CPU 使用率を測定し、基礎となるネットワークの限界を十分に下回っています。

パフォーマンスベンチマークでは、一般的なクラスター内の 2 つのノード間で最も一般的なトラフィックフローである、pod-to-pod のトラフィックと pod-to-service-to-pod のトラフィックについて、TCP と UDP の両方のフローに焦点を当てました。

テスト結果

以下のグラフは、ベンチマークで消費された CPU 使用率の合計を vCPU 単位で示しています。これは、クライアントとサーバーの両方の CPU 使用率の合計です。この結果は、Calico を追加することで、Calico を使用しないクラスターと比較して、CPU 使用率が最大 25% 削減されることを示しています。

これは、制御されたベンチマーク環境に限らず、同じ量の CPU 利用率であれば、Calico eBPF はより高いネットワークスループットを達成しうるということを意味します。スループットと CPU はどちらも有限のリソースであるため、この側面はリソース管理にとって重要です。ネットワーク機能のための CPU 使用率が低いということは、アプリケーションのワークロードを実行するためにより多くの CPU を使用できることを意味します。これによって、ネットワークを集中的に使用するワークロードを実行している場合、大幅なコスト削減につながる可能性があります。

kube-proxy の置き換え

Calico の eBPF データプレーンにはネイティブの Service 処理が含まれているため、kube-proxy を実行する必要はありません。Calico のネイティブ Service 処理は、ネットワーク機能とコントロールプレーンのパフォーマンスの両方の面で kube-proxy を上回り、ソース IP の保持などの機能をサポートしています。

パフォーマンスの違いは、特にネットワークレイテンシーに敏感なワークロードや、大量のサービスを実行している場合に顕著に現れます。Calico チームのこのブログで、これらのパフォーマンスの優位性についての詳細を確認し、kube-proxy のパフォーマンスと Calico のネイティブ Service 処理を比較したさまざまなベンチマークチャートを見つけることができます。

ソース IP の保持

Calico のネイティブ Service 処理のもう 1 つの大きな利点は、クライアントのソース IP アドレスを保持することです。

Kubernetes のネットワーク機能で頻繁に遭遇する課題点の 1 つは、Kubernetes Service への受信 (インバウンド) ネットワーク接続 (Service の NodePort 経由など) での kube-proxy によるネットワークアドレス変換 (NAT) の使用です。ほとんどの場合、これは受信トラフィックから元のクライアントのソース IP アドレスを削除し、ノードの IP アドレスに置き換えるという副作用があります。

これは、トラフィックが Pod に到達する頃には元のクライアントの IP アドレスを持たなくなっているため、Kubernetes の Network Policy では受信トラフィックを特定の外部クライアントからのみに制限することができないことを意味します。また、ログが本当のクライアントを示していないため、アプリケーションのトラブルシューティングを困難にすることもあります。また、一部のアプリケーションではソース IP アドレスを知ることが望ましい、あるいは必須であるようなケースもあります。例えば、クライアントアドレスに基づいて地理的位置の決定を行うようなアプリケーションが考えられます。

Calico のネイティブ Service 処理は、クライアントのソース IP アドレスを保持することができます。

EKS クラスターでこの機能を利用するには、通常、LoadBalancer タイプの Kubernetes Service を作成し、AWS Network Load Balancer (NLB) を使用するように指定します。NLB のロードバランサーは、クライアントのソース IP を保持したまま、対応する Service の NodePort に受信接続を転送できます。次に、Calico のネイティブ Service 処理が、NodePort のバックエンドの Pod への負荷分散を、やはりクライアントのソース IP を保持したまま行います。これによって、エンドツーエンドでクライアントのソース IP アドレスをバックエンドの Pod に至るまで保持することができます。

これは、ログやトラブルシューティングをより理解しやすくしてくれます。また、必要に応じてアクセスを特定の外部クライアントからのみに制限する Pod の Network Policy を書くことができるようになったことを意味します。

結論

Bottlerocket はエキサイティングな OS です。最新の eBPF 機能をサポートしており、Calico の eBPF データプレーンを実行するために必要なすべてを備えています。

Calico を標準の Amazon VPC CNI ネットワーク機能を備えた Bottlerocket ベースの EKS クラスターに追加することで、ネットワークパフォーマンスを大幅に向上できるだけでなく、kube-proxy を実行する必要がなくなり、外部クライアントのソース IP アドレスを Service のバックエンドの Pod に至るまで保持することができます。ネットワークを多用するワークロードでは、パフォーマンスの向上により、大規模に実行する際のコストを大幅に削減することができます。クライアントのソース IP アドレスを保存することで、ログやアプリケーションのトラブルシューティングが容易になり、必要に応じて Kubernetes の Network Policy でアクセスを特定の外部クライアントからのみ制限することができます。

重要なことは、Calico の eBPF 機能は、EKS の標準な Amazon VPC CNI ネットワーク機能を置き換えるのではなく、その上で動作することです。そのため、EKS のネットワーク機能でサポートされているすべての機能は引き続き機能し、期待どおりに動作します。

これを自分で試すには、ガイド “Createing an EKS cluster for eBPF mode” のステップバイステップの手順に従ってください。Bottlerocket ベースの EKS クラスターを作成し、その上に Calico を簡単に追加して、すべてのこのブログで説明されている利点を得る方法を示してくれます。

本記事は、Turbocharging EKS networking with Bottlerocket, Calico, and eBPF を翻訳したものです。翻訳はプロフェッショナルサービスの杉田が担当しました。

Amazon Web Services ブログ