eBPF Data Plane

Leverage multiple performance benefits from the new 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

Learn More

Technical Blog

Learn More

Calico Enterprise Documentation

Learn More