KubeCon + CloudNativeCon Europe 2020 2日目のセッションである eBPF and Kubernetes: Little Helper Minions for Scaling Microservices についてです。

スライド

以下のような内容でした。

eBPF についての初学者向けな説明
eBPF の歴史
eBPF の Kubernetes CNI 実装である Cilium について

※ 時系列を雑に日本語で起こしましたが知らないことばかりで都度調べながらの作業でした。結局ほとんどスライドのままな気がしますが、それでも他の記事以上に誤りが多い気がするので間違っている箇所があったら優しく指摘してください・・笑

Challenges from OS kernel side

前半は eBPF を Linux に入れるまでの話？正直良くわからなかった・・

eBPF for networking in a nutshell

eBPF を一言でいうと: カーネル上でプログラムを安全に動作させる仕組み

userspace で動作する agent が eBPF 用のコードを生成する
userspace の LLVM がそれをオブジェクトファイルにコンパイル
bpf syscall より kernelspace 内の BPF verifier , JIT compiler を経て native code になる
native code は kernelspace 内の任意の箇所 (例えば, NIC や TCP/IP Protocol Stack) で動作する
agent は kernelspace の BPF maps を経由して native code とやり取りできる

f:id:skitazawa1121:20200820011956p:plain

eBPF のいいところ

cannot crash the kernel

as fast as kernel module

stable API guarantees

Packet flow for kube-proxy

従来の kube-proxy においてパケットがどのように Pod や外部に出ていくのかについて、kernel 処理レベルで説明されていました。

f:id:skitazawa1121:20200820012259p:plain

これが eBPF の実装である CNI の Cilium を利用することで以下のようになりオーバヘッドが減るそうです。

Service から自ホスト上の Pod へ転送

f:id:skitazawa1121:20200820012339p:plain

Service から別ホスト上の Pod へ転送

f:id:skitazawa1121:20200820012353p:plain

eBPF の歴史

セッション後半は eBPF がどのような歴史をたどってきたか、今後どうなっていくかについての話でした

2013年

old "SDN" landscape: Open vSwitch , traffic control (初耳でした) , netfilter (iptables, ipvs, nftables)
BPF は tcpdump や seccomp 等、datapath と別の領域で使われていた
old "SDN" と eBPF の違いを、SDN を"program" the datapath , eBPF を create the datapath instead と表現されていました。
Initial big patch bomb to propose 'extended BPF'
- inspired by BPF な nftables が出てきたが、この時点ではまだ Linux kernel に merge されなかった

2014年

最初の eBPF パッチがmergeされた
- インタプリタの刷新
- このあとすぐに verifier core や JIT が追加された

2015年

eBPF moved into two directions in parallel: networking & tracing
- tracing: eBPF backend が LLVM にマージされ、eBPF を kprobes に接続する機能が出た
- networking: tc が eBPF で完全にプログラム可能になった
bcc project の Initial announcement

2016年

eXpress DataPath (XDP) の登場
- nfp : cls_bpf と XDP hook により eBPF で処理をする最初の driver
Cilium project first announced
- メインターゲットを Docker として以下を目指した
  - label-based policy, NAT64, tunnel mesh container connectivity 全てが eBPF を経由する
  - datapath 全体と転送ロジックを eBPF で行う (Docker や ovs の bridge device を必要としない)

2016, 2017年

Netflix で eBPF のトレーシングツールを「Linux BPF superpowers」と紹介した
Facebook で XDP + eBPF な L4 LB である Katran *1 が出た
Cloudflace でXDP + BPF で DDos ミティゲーションを実現した

2017, 2018年

Linux Kernel における BPF が成熟してきた

We apply patches to bpf & bpf-next kernel trees on git.kernel.org

Separate bpf kernel mailing list bpf@vger.kernel.org (archive at: lore.kernel.org/bpf/)

Our pull requests go to Linus Torvalds via David S. Miller (networking maintainer)

kTLS & eBPF : kernel space で TLS 処理を行う
bpftool & libbpf : アプリケーションの user space API (syscall + glibc のサブルーチン) のトレーシングツール

2018年

Cilium 1.0: K8s CNI integration
BTF (BPF Type Format) の策定
Linux Plumbers という BPF のカンファレンス
AF_XDP*2 が kernel に merge された
- // AF_PACKET の SOCK_RAW より高速に raw packet を userspace に送るやつという理解
bpfilter: iptables ルールを翻訳し、 BPF を利用して XDP や Hardware offload で動作

2018, 2019年

DTrace 2.0 として bpftrace が announced
BPF本 *3 が出た
Cilium 1.6: iptables ベースの kube-proxy を置き換えた
BPF の live-patching 対応

f:id:skitazawa1121:20200820012406p:plain

(かわいい)

2019, 2020 年

Google が BPF な LSM (Linux Security Module) を社内利用
BPF verifier が Spectre の危険性のあるものを検証するようになった
SR-IOV 経由で XDP を利用する Cloud Provider
- AWS: ena driver
- Azure hv_netvsc driver
Cilium 1.8 : XDP ベースのロードバランシングと NetworkPolicy

Bringing eBPF revolution to K8s

kube-proxy を eBPF (Cilium) に置き換えるとどうなるかについての説明でした。

f:id:skitazawa1121:20200820012425p:plain

Socket *4 と XDP/tc の二箇所で Cilium の BPF 実装が動作する
- Socket
  - East-West Traffic をハンドル
  - packet の生成前に BPF が syscall を hook するので、packet-level の NAT が必要ない
  - Node を中継しない (kube-proxy は必要だった)
  - NodePort service はローカルアドレスに公開、 host の 127.0.0.1/::1 で公開 *5
  - 他のアプリケーションによる Service Port の再利用をブロックする
- XDP / tc
  - North-South Traffic をハンドル
  - DNAT と DSR/SNAT *6
  - XDP がより low-overhead で良い