Kubernetes のネットワーク構成について、以前から導入を検討していた eBPF をベースとした構成を構築してみました。ついでにエンタープライズライクな要素もいくつか組み合わせています。
eBPF とは
eBPF (extended Berkeley Packet Filter) は、Linux カーネルに組み込まれた仮想マシンであり、小さなプログラムをカーネルの様々なポイントにアタッチして実行することができます。eBPF は、パケットフィルタリング、ネットワークトラフィックのモニタリング、セキュリティの強化、システムパフォーマンスのトレースなど、幅広い用途に使用されます。
- プログラムの実行: eBPF プログラムは、カーネル内で特定のイベントが発生した際に実行されます。これにより、リアルタイムでシステムの挙動を監視・操作できます。
- 高効率: eBPF プログラムは、カーネル内で直接実行されるため、高い効率性と低いオーバーヘッドを実現します。
- 柔軟性: ネットワーキングからセキュリティ、システム監視まで、様々なシナリオで適用可能です。
Calico における eBPF
- スループットの向上と CPU 使用率の低減: eBPFデータプレーンは、従来の Linux ネットワーキングデータプレーンと比較して、より高いスループットを提供し、CPU 使用率を削減します。
- ネイティブな Kubernetes サービスサポート: eBPF データプレーンは、kube-proxy を必要とせず、Kubernetes サービスをネイティブにサポートします。これにより、パケットの遅延が減少し、外部クライアントのソース IP が保持され、DSR (Direct Server Return) が可能になります。
- 効率的なデータプレーンの更新: eBPF データプレーンは、サービスの更新時に効率的なデータプレーン更新を実現し、CPU 使用率を低く抑えます。
今回導入した機能
DualStack (IPv4/IPv6)
自宅システムは完全な DualStack としており、今回の構成もそれが適用されます。
コントロールプレーン（マスターノード）の冗長化
これまで、自宅の Kubernetes ではシングルマスターの構成としていましたが、エンタープライズ環境にも応用できるように HAProxy を使用した HA 構成としました。
CNI
Calico
タイトルの通り、CNI は Calico を使用します。
- ネットワークデータプレーンに eBPF を使用します。元々、Kubernetes のクライアント IP の保持について不満があったのですが、eBPF によりそれが解消されます。また、性能向上も期待できます。DSR は、それほど強いメリットが見出せず、一方でパケットフローが煩雑になり運用のデメリットが大きそうなので使用していません。
- BGP を使用したネットワーク構成としています。各ノードは外部ルーター（ルートリフレクター）と iBGP でピアを確立し、Pod-IP, Cluster-IP, External-IP をアドバタイズします。マスターノードはサービス用の Pod を配置しないため、Cluster-IP, External-IP をアドバタイズしないように制御しています。ルートリフレクターでの iBGP 構成となるため、ノード間の通信は直接ルーティングされます。また、ECMP により、外部アクセスはロードバランスされます。
Multus
Multus はメタ CNI です。Multus を導入することで、Pod にネットワークインターフェイスを追加することができます。今回は、PV となる NFS との接続用に、Multus を導入しました。macvlan を使用しています。これにより、パフォーマンスの向上を期待しています。
CSI
今回は、外部ストレージとして NFS を使用するため、NFS CSI Driver を導入しました。CSI を導入することで、PVC の作成時に NFS 上の動的なディレクトリの作成と PV の作成を自動化することができます。
まとめ
マネージド Kubernetes の場合、既に便利に使えるように様々なコンポーネントが用意されいる一方、オンプレ Kubernetes の場合、低レイヤーの設計が非常に重要になります。しかし、様々な環境において柔軟にアーキテクチャを設計できる面白さもあると思います。
今回、eBPF を使用することで、現状ではこれ以上ない Kubernetes のネットワーク設計ができたと思っています。eBPF 対応の CNI としては Cilium が有名ですが、標準的な Calico でも問題なく eBPF が使えることが確認できました。しかし、kube-proxy (iptables, ipvs) ではなくなるため、トラブルシューティングは難しくなると思いますし、もしかすると eBPF に関するトラブルシューティングは現実的に不可能ではないか、とも思っています。このため、十分な検証と、可能な限り IaC で自動化することで、補完できるようにすると良いと思っています。
