eBPF introduction
kubecon 2020 eBPF 相关 session
- Beyond the Buzzword BPF’s Unexpected Role in Kubernetes
- Designing a gRPC Interface for Kernel Tracing with eBPF
- eBPF and Kubernetes Little Helper Minions for Scaling Microservices —— Cilium
- Hubble - eBPF Based Observability for Kubernetes
- Tutorial Using BPF in Cloud Native environments -- Agenda
- what is eBPF?
- what can eBPF do?
Linux 内核中一个高度灵活与高效的类虚拟机组件， 它以一种安全的方式在许多 hook 点执行受限的 bytecode。
the virtual machine with a total of 11 64-bit registers, a program counter and a 512 byte fixed-size stack.
-
r0: stores return values, both for function calls and the current program exit code
-
r1-r5: used as function call arguments, upon program start r1 contains the "context" argument pointer
-
r6-r9: these get preserved between kernel function calls
-
r10: read-only pointer to the per-eBPF program 512 byte stack --
-
BPF map：高效的 key/value 仓库
-
辅助函数（helper function）：可以更方便地利用内核功能或与内核交互
-
尾调用（tail call）：高效地调用其他 BPF 程序
-
支持 BPF offload（例如 offload 到网卡）的基础设施
-
... --
BPF: Tracing and More, p5
--
eBPF - Rethinking the Linux Kernel, p11
--
Trivia -
eBPF 是近年来linux的重大特性，一开始linus拒绝合入，后来将commit拆分后才合入。
-
eBPF 能合入linux主线主要归功于在kernel内部建立一系列向后兼容的抽象，正如kernel和userspace之间的接口一样。
-
eBPF 近年来已经成为了kernel中最活跃的子系统。 -- extended readings
- networking
- tracing
- more...
iptables的问题:
- 只能全量更新
- O(n)复杂度的rules应用
- 基于IP和端口，无法感知L7的协议
- CPU消耗高、延迟大 -- even worse in K8S
- kube-proxy - the component which implements Services and load balancing by DNAT iptables rules
- the most of CNI plugins are using iptables for Network Policies
--
eBPF and Kubernetes Little Helper Minions for Scaling Microservices, p28
--
eBPF and Kubernetes Little Helper Minions for Scaling Microservices, p30
--
eBPF and Kubernetes Little Helper Minions for Scaling Microservices, p32
-- how eBPF solve this?
- eBPF hash map (per cpu)
- kTLS
- bypass netfilter
- offload to hardware(XDP) -- extended readings
- 深入理解 Cilium 的 eBPF 收发包路径
东西向流量在Socket层的BPF处理
- 将 Service 的
IP:Port映射到具体的后端的PodIP:Port，并做负载均衡。 - 当应用发起
connect、sendmsg、recvmsg等请求（系统调用）时，拦截这些请求，并根据请求的IP:Port映射到后端 pod，直接发送过去。反向进行相反的变换。 - 不需要包级别（packet leve）的地址转换（NAT）。在系统调用时，还没有创建包，因此性能更高。
- 省去了 kube-proxy 路径中的很多中间节点（intermediate node hops） -- 南北向流量在XDP或者tc层的BPF处理
- 与 socket 层的差不多，将 Service 的
IP:Port映射到后端的PodIP:Port。 - 进行DNAT转换，可以在XDP做也可以在tc做，XDP做性能更高 --
- 将东西向流量放在离 socket 层尽量近的地方做。
- 将南北向流量放在离驱动（XDP 和 tc）层尽量近的地方做。
extended readings
用户可以写一个python程序和一个c程序
- python程序，用户态运行，收集数据输出。
- c程序会编译后加载到kernel中，收集event或者写入map。
--
bcc tools
--
off-cpu analysis
extended readings
- Linux Extended BPF (eBPF) Tracing Tools
- Learn eBPF Tracing: Tutorial and Examples
- on/off cpu flamegraphs
- bcc tutorial
- bpftrace tutorial
--