How to Deploy Google Kubernetes Engine (GKE) Dataplane V2 for eBPF Network Policies

In standard Kubernetes deployments, network routing and security policies are historically handled by kube-proxy using iptables. When a cluster has thousands of Pods and hundreds of Network Policies, the iptables ruleset explodes into a massive, sequential list. Because the Linux kernel evaluates iptables sequentially, routing latency increases exponentially, and CPU overhead spirals out of control. Furthermore, iptables was designed for static firewalls, not the highly ephemeral, rapidly churning environment of Kubernetes Pod IPs.

Google completely overhauled the network stack for Google Kubernetes Engine (GKE) with the introduction of Dataplane V2.

GKE Dataplane V2 abandons kube-proxy and iptables entirely. Instead, it utilizes eBPF (Extended Berkeley Packet Filter), powered by the open-source Cilium project. eBPF allows Google to inject highly optimized, compiled C-code directly into the Linux kernel to handle packet routing, load balancing, and network policy enforcement at the hardware-accelerated socket level. The result is massive throughput, near-zero latency, and unparalleled security observability.

This guide explains how to deploy GKE Dataplane V2 and leverage its eBPF architecture for advanced network isolation.

Understanding the eBPF Advantage

In the legacy iptables model, when Pod A tries to talk to Pod B, the packet must traverse the Linux networking stack, hit the netfilter hooks, and be matched against hundreds of rules.

With GKE Dataplane V2 (eBPF):

1. The network policies are translated into an eBPF map (a highly efficient hash table in the kernel).
2. When Pod A generates a packet, the eBPF program intercepts it directly at the socket layer (before it even hits the TCP/IP stack).
3. The eBPF map is evaluated in O(1) time (instantaneously, regardless of how many policies exist).
4. The packet is either dropped immediately or forwarded directly to Pod B, bypassing the host networking stack entirely.

Step 1: Deploying a Cluster with Dataplane V2

Dataplane V2 must be enabled at the time the cluster is created. You cannot upgrade an existing GKE cluster from legacy kube-proxy to Dataplane V2 without recreating the node pools.

Using the gcloud CLI, deploy a new standard cluster and explicitly append the --enable-dataplane-v2 flag:

gcloud container clusters create gke-ebpf-cluster \
    --zone us-central1-a \
    --enable-dataplane-v2 \
    --num-nodes 3

(Note: If you deploy a GKE Autopilot cluster, Dataplane V2 is enabled automatically by default, as Google manages the underlying network infrastructure).

Step 2: Verifying the Dataplane V2 Architecture

Once the cluster is deployed, connect to it using kubectl.

gcloud container clusters get-credentials gke-ebpf-cluster --zone us-central1-a

In a legacy cluster, you would see kube-proxy daemonsets running in the kube-system namespace. In Dataplane V2, kube-proxy does not exist.

kubectl get pods -n kube-system | grep proxy
# The output will be completely empty.

Instead, the networking is handled by the anetd (Advanced Network Daemon) daemonset, which is Google’s implementation of the Cilium eBPF agent.

kubectl get pods -n kube-system -l k8s-app=cilium

You will see the anetd pods running on every node, silently injecting the eBPF routing logic into the kernel.

Step 3: Enforcing eBPF Network Policies

Because Dataplane V2 natively understands Kubernetes Network Policies, you don’t need to install Calico or any third-party CNI plugins.

Create a strict default-deny network policy to isolate a sensitive namespace (e.g., finance-db).

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: finance-db
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
EOF

When you apply this YAML, the Kubernetes API passes it to the anetd agent. The agent instantly compiles this rule into an eBPF program and injects it into the Linux kernel on the nodes. Any unauthorized packet attempting to enter or leave the finance-db namespace is dropped at the absolute lowest level of the operating system.

Step 4: Leveraging eBPF Observability

One of the massive advantages of eBPF is that it has total visibility into the kernel socket layer. Dataplane V2 exposes this telemetry natively to Google Cloud Logging.

You can enable Network Policy Logging to see exactly which packets are being blocked by your eBPF rules, without incurring the massive performance penalty associated with traditional iptables logging.

gcloud container clusters update gke-ebpf-cluster \
    --zone us-central1-a \
    --enable-network-policy-logging

You can now navigate to the Google Cloud Log Explorer and query for logName="projects/YOUR_PROJECT/logs/policy-action" to see real-time, hardware-accelerated telemetry of every dropped packet, including the source Pod, destination Pod, and the exact Network Policy that triggered the block.

Conclusion

The transition from iptables to eBPF is the most significant architectural shift in Linux networking in a decade. By deploying Google Kubernetes Engine with Dataplane V2, platform engineering teams can achieve infinite network scaling, eliminate the kube-proxy bottleneck, and enforce strict Zero Trust container isolation using the unparalleled speed and security of kernel-level eBPF programming.