Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

NetKit Device

Yutaro Hayakawa
December 10, 2023
950

NetKit Device

NetKitデバイスに関して軽い調査をしたまとめ

Yutaro Hayakawa

December 10, 2023
Tweet

Transcript

  1. NetKit Device • 今年10月にLinuxに入った新しい仮想デバイス • Isovalentのエンジニア (Daniel Borkmann, Nikolay Aleksandrov)

    が中心になって開発 • Kubernetes Networkのユースケースに特化した仮想デバイス • “veth replacement”
  2. NetKit Deviceが作られた経緯 • 基本的にはCiliumのために作っている • 性能向上が主なモチベーション ◦ KubernetesのPod-to-Podの通信をHost-to-Host並に速くしたい ◦ 具体的な数字で言えば

    Pod to Podの通信で100Gbps出るようにしたい • NetKit Deviceの目的はNetwork Namespace Switchの速度向上 ◦ ⚠ 当然これだけでは 100Gbpsは出ない ◦ これまでも色々やってきたパフォーマンス向上 100Gbpsをマイクロベンチで達成できるというのが実際 ◦ 周辺技術も合わせてチェックするのがおすすめ • 性能向上だけでなく Kubernetesネットワーキングの分野で役立つ機能が色々盛り込まれている
  3. Kubernetes Networkingのおさらい 一般的なKubernetes Networkingの構成要素 • Node, Pod • veth •

    kube-proxy ◦ iptables/ipvs (netfilter) を使って実装さ れている. ServiceとBackendの数に比 例して処理時間が長くなることが知られ ている.
  4. Cilium Networkingのおさらい Ciliumの場合 • tc-bpf • Podの出口 (Host側vethのtc-ingress)とNodeの 入り口 (物理デバイスの

    tc-ingress)でeBPFのプ ログラムが走る . カーネルスタックの機能は必 要に応じて使う . • kube-proxy-replacement ◦ eBPFベースでkube-proxyを置き換え. 基 本的にはO(1).
  5. 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()
  6. その他の機能 • 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 (全部通す)
  7. 各種ツール, ライブラリのサポート状況 • 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と互換性がある)
  8. 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
  9. Primary Namespace => Primary NetKit xmit => Peer NetKit recv

    ここでパケットがbacklog queueに入る
  10. PeerのKernel Stackを Bypass, 直接Neighサブ システムに飛ぶ PeerのKernel StackでIP Forwarding skb_orphan ここでSocketの

    Referenceが落ちる. TCPの場合はここでセグ メントがホストから出て 行った扱いになる. これ がかなりTCPのスルー プットに悪いらしい. ここでパケットがbacklog queueに入る
  11. Future Work: Single Device Mode • ペアではなくて単一のデバイスとして動かすモード • (多分) Custom

    Tunnel DeviceなんかをeBPFで作れるよということ • “eBPF Programmable Device” らしい機能ではあるがユースケースは今の所出てきていない
  12. 参考文献 • 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