GKE Dataplane V2, powered by Cilium, fundamentally changes how network packets flow within your Google Kubernetes Engine clusters, shifting from the traditional kube-proxy model to eBPF-based packet manipulation directly in the kernel.
Let’s see it in action. Imagine you have a simple deployment of two nginx pods:
# deployment-a.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-a
spec:
replicas: 1
selector:
matchLabels:
app: app-a
template:
metadata:
labels:
app: app-a
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
---
# deployment-b.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-b
spec:
replicas: 1
selector:
matchLabels:
app: app-b
template:
metadata:
labels:
app: app-b
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
And a Kubernetes Service that exposes app-a:
# service-a.yaml
apiVersion: v1
kind: Service
metadata:
name: service-a
spec:
selector:
app: app-a
ports:
- protocol: TCP
port: 80
targetPort: 80
type: ClusterIP
With Dataplane V2 enabled, when a pod running app-b tries to connect to service-a on port 80, the packet doesn’t hit kube-proxy in userspace. Instead, an eBPF program attached to the network interface of the app-b pod intercepts the outgoing packet. This eBPF program, managed by Cilium, knows about the service-a ClusterIP and its backing pods. It directly rewrites the destination IP and port of the packet to match one of the healthy app-a pods, sending it on its way without ever leaving the kernel. The response packet from the app-a pod is also processed by eBPF, ensuring it returns to the correct app-b pod via source NAT.
The core problem Dataplane V2 solves is the performance bottleneck and complexity introduced by kube-proxy. Traditionally, kube-proxy watches for Service and Endpoint changes and programs iptables rules on each node. When a pod needs to reach a Service, its traffic is intercepted by iptables, which then performs Destination Network Address Translation (DNAT) to send the packet to one of the Service’s backing pods. This involves multiple context switches between kernel and userspace for each packet, leading to higher CPU usage and latency, especially at scale. Dataplane V2, by leveraging eBPF, bypasses iptables and kube-proxy entirely for Service routing, performing these operations directly within the kernel at a much higher efficiency. It also enables advanced features like Network Policy enforcement at line speed.
To enable GKE Dataplane V2, you create a GKE cluster with specific configuration flags. The key is the --enable-dataplane-v2 flag during cluster creation or node pool creation.
Here’s how you might create a new GKE cluster with Dataplane V2 enabled:
gcloud container clusters create my-gke-cluster \
--zone=us-central1-a \
--enable-dataplane-v2 \
--enable-ip-alias \
--network=default \
--subnetwork=default \
--cluster-version=1.27.7-gke.100
The --enable-ip-alias flag is a prerequisite for Dataplane V2 as it enables VPC-native networking, which is essential for eBPF to function correctly with pod IP addresses.
If you have an existing cluster and want to enable Dataplace V2 on a specific node pool, you can do so during node pool creation:
gcloud container node-pools create dataplane-v2-pool \
--cluster=my-gke-cluster \
--zone=us-central1-a \
--enable-dataplane-v2 \
--enable-ip-alias \
--num-nodes=1 \
--node-version=1.27.7-gke.100
Once enabled, you can verify that Cilium is running as the CNI by checking for Cilium pods in the kube-system namespace:
kubectl get pods -n kube-system -l k8s-app=cilium
You should see pods like cilium-node-init-... and cilium-agent-....
The primary benefit is significant performance improvement for Service routing and network policy enforcement. By moving the networking logic into eBPF programs within the kernel, Dataplane V2 eliminates the kube-proxy userspace bottleneck, reducing CPU overhead and network latency. This is particularly noticeable in clusters with a large number of Services and high network traffic.
The one thing that’s often misunderstood is how Network Policies are enforced. With Dataplane V2, Cilium doesn’t just drop or allow packets based on iptables rules. Instead, it uses eBPF to inspect network traffic at various points in the kernel. For Network Policy, Cilium builds a detailed, identity-based policy model. When a packet traverses the network stack, the eBPF program associated with the sender’s network interface checks the identity of the sender and the intended recipient against the defined Network Policies. If the policy permits the communication, the packet is allowed to proceed; otherwise, it’s dropped directly in the kernel, often before it even reaches its destination IP. This identity-based enforcement allows for much more granular and efficient policy management than traditional IP-based firewalling.
With Dataplane V2 enabled, you’ll likely start exploring advanced Cilium features like its Hubble observability tool for network traffic visualization.