NetKit Device Yutaro Hayakawa

NetKit Device ● 今年10月にLinuxに入った新しい仮想デバイス ● Isovalentのエンジニア (Daniel Borkmann, Nikolay Aleksandrov) が中心になって開発 ● Kubernetes Networkのユースケースに特化した仮想デバイス ● “veth replacement”

今回のお話 ● NetKit Deviceが作られた経緯 ● 機能の概観 ● Demo

NetKit Deviceが作られた経緯 ● 基本的にはCiliumのために作っている ● 性能向上が主なモチベーション ○ KubernetesのPod-to-Podの通信をHost-to-Host並に速くしたい ○ 具体的な数字で言えば Pod to Podの通信で100Gbps出るようにしたい ● NetKit Deviceの目的はNetwork Namespace Switchの速度向上 ○ ⚠ 当然これだけでは 100Gbpsは出ない ○ これまでも色々やってきたパフォーマンス向上 100Gbpsをマイクロベンチで達成できるというのが実際 ○ 周辺技術も合わせてチェックするのがおすすめ ● 性能向上だけでなく Kubernetesネットワーキングの分野で役立つ機能が色々盛り込まれている

Kubernetes Networkingのおさらい 一般的なKubernetes Networkingの構成要素 ● Node, Pod ● veth ● kube-proxy ○ iptables/ipvs (netfilter) を使って実装さ れている. ServiceとBackendの数に比 例して処理時間が長くなることが知られ ている.

Cilium Networkingのおさらい Ciliumの場合 ● tc-bpf ● Podの出口 (Host側vethのtc-ingress)とNodeの 入り口 (物理デバイスの tc-ingress)でeBPFのプ ログラムが走る . カーネルスタックの機能は必 要に応じて使う . ● kube-proxy-replacement ○ eBPFベースでkube-proxyを置き換え. 基 本的にはO(1).

ベースラインパフォーマンス 100G NICのついたサーバ2つを直結してベンチマーク Pod-to-PodとHost-to-HostのTCP Single Flowのスループットを比較 Host-to-Hostから大体22Gbpsくらいのギャップがある (Wire Rateとのギャップは76Gbpsくらい) ここからどう速くしていくか？

BPF Host Routing (Ingress) Nodeの物理デバイスのtc-ingressからカーネルスタックとPod側vethのBacklog Queueをバイパス してPod側の受信完了までRun to Completionでパケットを処理させる (bpf_redirect_peer)

BPF Host Routing (Egress) Host側のvethからカーネルスタックをバイパスして物理 NICにパケットをリダイレクト (bpf_redirect_neigh) 外のネットワークに出ていく時は ARPの解決が必要なこともあるが, それもbpf_redirect_neigh側で 面倒を見てくれる

BPF Host Routingの効果 ベースラインのPod-to-Podと比較して17Gbpsほどのゲイン Host-to-Hostとのギャップは4Gbps ぶっちゃけもう十分じゃない？という気もするが, 100Gbpsには程遠い

とりあえずMTUを上げる MTUを8264Bに上げる (ジャンボフレームの規格上は9Kまでいけるがこの数がGROとの実 装との相性がよく, 性能が出やすいらしい) Host-to-Hostはもうほぼ100Gbps出ている 残り9Gbpsをどう稼ぐか？

Fast Network Namespace Switching with NetKit bpf_redirect_neighでカーネルをバイパスしつつさらに Host側NetKitのBack Log Queueもバイパスできる NetKitのeBPFプログラムの中でfib_lookupやredirectをするとHost側のNetwork NamespaceのFIBやNetdevにアクセス できる bpf_redirect_neigh()

Backlog Queue Flame Graphで見ると違いがわかりやすい

NetKitの効果 Host-to-Hostと変わらないパフォーマンスを出せるように 🎉 ⚠ meta == NetKit

別解: BIG-TCP BIG-TCP: 基本的にはGSOだが, 512KBまでパケットを固められる (普通のGSOは64Kが上限) BIG-TCPを使えばvethでも100Gbps出る NetKitに乗り換えるにはもう少し他のメリットも欲しいところ

BIG-TCPを使った場合のレイテンシの対比 Vethと比較してレイテンシはアドバンテージがある この20usのゲインが必要なワークロードにはNetKitが刺さるかもしれない

IPVLAN Device Fast Netns SwitchingはNetKitの専売特許ではない. IPVLANデバイスも似たような特性がある. ただし, IPVLANの場合, eBPFのプログラムはPodのNetnsの中のtc-egressにアタッチする必要がある 権限の設定によってはPodがeBPFのプログラムをデタッチすることもできる また, IPVLANは1つのmaster deviceから子デバイスを生やす構成なので, 複数の物理デバイスがある場合に不便

NetKit Primary & Peer NetKit Deviceのペアにはvethにはない非対称な関係がある (PrimaryとPeer) PrimaryとPeerが違うNetnsにいてもPrimary側を経由してPeer側にeBPFのプログラムをアタッチできる Peer側のデバイスはPrimary側からアタッチされたeBPFプログラムをデタッチすることはできない eBPFプログラムをアタッチするためだけにPodに強い権限を持たせる必要がない Primary Peer BPF_LINK_CREATE expected_attach_type = BPF_NETKIT_PEER Pod Netns Host

NetKit Primary & Peer

その他の機能 ● L2 / L3 Mode ○ L2モードは普通のEthernetデバイスと同じ ○ L3モードはIPIPデバイスやVRFのようなモード (ARPが飛ばない, Ethernetヘッダがつかない) ○ NetKitのデフォルトはL3モード ● Multi-Attach (bpf_mprog) ○ 一箇所のフックに複数のeBPFプログラムをアタッチでき, さらにプログラムの前後関係を明示的に指定できる (e.g. Program Aより前, Program Bより後) ○ NetKitは最初からこれをサポートしている ○ ちなみにTCX (TC Express, XDPより後, 普通のTCより前) という新しいフックを使えば普通のNetwork Deviceでも同 じようにMulti Attachできる ● Default Forwarding Policy ○ eBPFプログラムがアタッチされていない時の挙動を制御 ○ Drop (全部落とす) か Forward (全部通す)

各種ツール, ライブラリのサポート状況 ● iproute2のコマンドはまだUpstreamされていない, Danielのforkには一応使えるものがある ○ https://github.com/borkmann/iproute2/tree/pr/netkit ○ `ip link add nk0 type netkit mode l3 peer name nk1` ● libbpfにはすでにサポートあり, cilium/ebpfはまだ ○ NetKitはNetKit用の新しいeBPFのフックを作ったので, 新しいAttachのやり方が必要 (eBPF プログラム自体はtcと互換性がある)

Demo Client Primary Peer veth veth nk nk 10.0.0.0/24 10.0.1.0/24 .2 .1 .1 .2 ClientからPeerにping. 以下のシナリオでpwruを使って関数トレースをとってみる. Scenario 1: nkのpolicyをforwardにして普通にPing. この場合vethとnetkitに違いはない. Scenario 2: PeerのnkとPrimaryのvethにeBPFをattachしてBPF Host Routing相当のことをやる. 1に比 べると関数トレース上ショートカットできているのが観測できるはず . bpf_redirect_peer bpf_redirect_neigh

Scenario1 Scenario2

Client Namespace => Client veth xmit => Primary veth recv

bpf_redirect_peer

この時点ですでに PeerのNamespace にいる PrimaryのNamespace内 でIP Forwarding

Primary Namespace => Primary NetKit xmit => Peer NetKit recv ここでパケットがbacklog queueに入る

Peerの受信処理 ICMP Reply開始

Peerの送信処理

Peerの送信処理 Cont.

bpf_redirect_neigh

PeerのKernel Stackを Bypass, 直接Neighサブ システムに飛ぶ PeerのKernel StackでIP Forwarding skb_orphan ここでSocketの Referenceが落ちる. TCPの場合はここでセグ メントがホストから出て 行った扱いになる.　これ がかなりTCPのスルー プットに悪いらしい. ここでパケットがbacklog queueに入る

??? skb_orphan SocketのReferenceがここ まで保持されている . 実際の 物理NICの場合だとNICのメ モリに実際にパケットを積ん だ段階でSocketの Referenceを落とす? (調べていない)

??? Clientの受信処理

Future Work: Single Device Mode ● ペアではなくて単一のデバイスとして動かすモード ● (多分) Custom Tunnel DeviceなんかをeBPFで作れるよということ ● “eBPF Programmable Device” らしい機能ではあるがユースケースは今の所出てきていない

参考文献 ● bpfconf (May 2 - May 4, 2022) ● LPC 2022 (Sep 12 - Sep 14, 2022) ● FOSDEM 2023 (Feb 4 - Feb 5, 2023) ● bpfconf 2023 (May 8 - May 10, 2023) ● Patch Set (Oct 24, 2023) ● LWN (Nov 6, 2023) ● KubeCon NA 2023 (Nov 8, 2023) ● LPC 2023 (Nov 24, 2023) おすすめ 全体感を把握したい => KubeCon NA 2023 パフォーマンスのことを知りたい => FOSDEM 2023 実装を詳しく知りたい => LPC 2023