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

Historically, Kubernetes networking and network policy enforcement relied on iptables (via kube-proxy) and third-party CNI (Container Network Interface) plugins like Calico. While functional, iptables rules scale linearly; as the number of pods and services in a cluster grows, the iptables chains become massively complex, leading to severe latency and CPU overhead.

Google Cloud solves this with GKE Dataplane V2. Powered by Cilium and eBPF (Extended Berkeley Packet Filter), Dataplane V2 removes the need for kube-proxy entirely. Instead of routing packets through the host network stack and iptables, eBPF programs are attached directly to the Linux kernel sockets, allowing for highly performant, scalable, and observable network policy enforcement.

Why Choose GKE Dataplane V2?

Enabling Dataplane V2 provides several architectural advantages for your GKE clusters:

• No Kube-Proxy: Bypasses the legacy iptables infrastructure, reducing CPU usage and eliminating rule-compilation bottlenecks.
• Enhanced Network Policies: Enforces Kubernetes NetworkPolicies directly in the kernel datapath using eBPF, providing instant enforcement without polling delays.
• Built-in Observability: Provides native Network Policy Logging, allowing you to see exactly which pod IPs and ports were allowed or denied by your policies directly in Cloud Logging.
• FQDN Network Policies: Dataplane V2 allows you to write egress network policies based on Fully Qualified Domain Names (e.g., api.github.com) rather than static IP addresses, which is impossible with standard Kubernetes policies.

Step 1: Creating a Cluster with Dataplane V2 Enabled

Dataplane V2 is the default for new Autopilot clusters. However, if you are creating a Standard GKE cluster, you must explicitly enable it during cluster creation. It cannot be enabled or disabled on an existing cluster.

Using the gcloud CLI, create a new cluster with the --enable-dataplane-v2 flag:

gcloud container clusters create ebp-cluster \
    --region us-central1 \
    --enable-dataplane-v2 \
    --num-nodes 3

Verify that Dataplane V2 is enabled on your cluster:

gcloud container clusters describe ebp-cluster \
    --region us-central1 \
    --format="value(networkConfig.datapathProvider)"

The output should return ADVANCED_DATAPATH.

Step 2: Verifying the eBPF Infrastructure

Once the cluster is running, you can inspect the underlying infrastructure to confirm that kube-proxy is absent and the Cilium/eBPF daemonset is handling networking.

First, verify that kube-proxy does not exist in the kube-system namespace:

kubectl get pods -n kube-system | grep kube-proxy

(This should return no results).

Next, locate the Dataplane V2 daemonset, which runs as anetd (Advanced Network Daemon):

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

You will see an anetd-xxxxx pod running on every node in your cluster. This pod is responsible for compiling and attaching the eBPF programs to the kernel.

Step 3: Enforcing Network Policies with eBPF

With Dataplane V2, standard Kubernetes NetworkPolicies are instantly translated into eBPF maps. Let’s create a default-deny ingress policy to test this.

Create a file named default-deny.yaml:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Apply the policy:

kubectl apply -f default-deny.yaml

Immediately upon application, the anetd daemon updates the eBPF maps. Any incoming traffic to pods in the default namespace that is not explicitly allowed will be dropped in the kernel before it even reaches the pod’s virtual ethernet interface.

Step 4: Enabling Network Policy Logging

One of the most powerful features of Dataplane V2 is Network Policy Logging. In traditional iptables setups, determining why a packet was dropped by a NetworkPolicy is incredibly difficult. With eBPF, we can log the exact policy evaluation.

To enable logging, you must edit the cilium-config ConfigMap in the kube-system namespace.

kubectl edit configmap cilium-config -n kube-system

Add the following key-value pair under the data section:

data:
  enable-policy-logging: "true"

Restart the anetd daemonset to apply the changes:

kubectl rollout restart daemonset anetd -n kube-system

Step 5: Querying Logs in Cloud Logging

Once logging is enabled, dropped or allowed packets are logged directly to Google Cloud Logging. You can query these logs to troubleshoot your eBPF Network Policies.

In the Google Cloud Console, navigate to Logging > Logs Explorer and run the following query:

resource.type="k8s_node"
logName="projects/YOUR_PROJECT_ID/logs/network-policy"
jsonPayload.disposition="deny"

The resulting logs will show you the exact Source IP, Destination Pod, Port, and the name of the NetworkPolicy that caused the packet to be dropped, providing total visibility into your cluster’s security posture.

Conclusion

Deploying GKE Dataplane V2 represents a fundamental shift in how Kubernetes networking operates. By abandoning legacy iptables in favour of in-kernel eBPF programs, administrators gain unmatched performance, scalability, and the critical observability required to secure modern, large-scale microservice architectures.