- Calico Enterprise
- eBPF Data Plane
Overview
Calico was designed from the ground up with a pluggable data plane architecture. Along with the standard Linux and Windows data planes, Calico Enterprise includes an eBPF (extended Berkeley Packet Filter) data plane that provides multiple benefits to users.
Benefits
Future-proof
Calico provides investment protection by providing a single solution that supports eBPF, along with the standard Linux and Windows data planes. With this approach, Tigera is future-proofing your decision to choose Calico
Higher Throughput, Lower CPU
Scales to higher throughput, using fewer CPU resources per GBit when compared with the standard Linux data plane (based on iptables)
Preserves Source IP
Preserves the source IP address of incoming network connections by swapping out the Kubernetes kube-proxy with native service handling, and eliminating source network address translation (SNAT). For many applications, knowing the source IP address is essential
Capabilities
Higher Throughput vs. Standard Linux
Natively supports Kubernetes services (without kube-proxy) in a way that
- Reduces latency
- Preserves external client source IP addresses
- Supports direct server return (DSR) for reduced latency and CPU usage
- Uses less CPU than kube-proxy to keep the data plane in sync
Support for Host Protection
When combined with Calico’s automatic host endpoints feature, the eBPF data plane offers a robust way to secure Kubernetes pods and hosts together using a unified policy model. By deploying Calico for host protection as well as for pod security, your host protection policy becomes just as dynamic as your workload policy, and matches the identity of the workload (carried in its metadata labels).
How It Works
The application of network address translation (NAT) by kube-proxy to incoming network connections to Kubernetes services (e.g. via a service node port) is a frequently encountered friction point with Kubernetes networking. NAT has the unfortunate side effect of removing the original client source IP address from incoming traffic. When this occurs, Kubernetes network policies can’t restrict incoming traffic from specific external clients. By the time the traffic reaches the pod it no longer has the original client IP address. For some applications, knowing the source IP address is not only desirable, it’s required. For example, performing geo-location based on source address.
Calico’s eBPF data plane makes several changes to this model. The most significant difference is in swapping out the Kubernetes kube-proxy with native service handling. This eliminates the need for SNAT. Because only destination network address translation (DNAT) is applied, the source IP address is preserved on the request. The response from the pod has a reverse DNAT applied by the eBPF program, at which point the response can be returned directly to the client, a method known as direct server return (DSR).
Resources
Free eBook
Technical Blog
