GKE Dataplane V2

Stay organized with collections Save and categorize content based on your preferences.

This page gives an overview of what GKE Dataplane V2 does and how it works.

Overview of GKE Dataplane V2

GKE Dataplane V2 is a dataplane for GKE and Anthos clusters that is optimized for Kubernetes networking. GKE Dataplane V2 provides:

  • A consistent user experience for networking in GKE and all Anthos clusters environments. See Availability of GKE Dataplane V2 for information about the environments that support GKE Dataplane V2.
  • Real-time visibility of network activity.
  • Simpler architecture that makes it easier to manage and troubleshoot clusters.

GKE Dataplane V2 is based on eBPF and Linux nodes to flexibly and performantly process network packets in-kernel using Kubernetes-specific metadata.

GKE Dataplane V2 is enabled for all new Autopilot clusters in versions 1.22.7-gke.1500 and later, 1.23.4-gke.1500 and later, and all versions 1.24 and later.

Advantages of GKE Dataplane V2

Scalability

GKE Dataplane V2 has different scalability characteristics than legacy data plane.

For GKE versions where the GKE Dataplane V2 does not use kube-proxy and does not rely on iptables for service routing, GKE removes some iptables related bottlenecks, such as the number of Services.

GKE Dataplane V2 relies on eBPF maps that are currently limited to 64,000 endpoints across all services.

Security

Kubernetes Network policy is always on in clusters with GKE Dataplane V2. You don't have to install and manage third-party software add-ons such as Calico to enforce network policy.

Operations

When you create a cluster with GKE Dataplane V2, network policy logging is built in. Configure the logging CRD on your cluster to see when connections are allowed and denied by your Pods.

Consistency

GKE Dataplane V2 is available and provides the same features on GKE and on other Anthos clusters environments. See Availability of GKE Dataplane V2 for more details.

How GKE Dataplane V2 works

GKE Dataplane V2 is implemented with eBPF (extended Berkeley Packet Filter). As packets arrive at a GKE node, eBPF programs installed in the kernel decide how to route and process the packets. Unlike packet processing with iptables, eBPF programs can use Kubernetes-specific metadata in the packet. This lets GKE Dataplane V2 performantly process network packets in the kernel and report annotated actions back to user space for logging.

The following diagram shows the path of a packet through a node using GKE Dataplane V2 as described in the preceding paragraph:

image

The GKE Dataplane V2 controller on the node is called anetd. anetd is deployed as a DaemonSet to each node in the cluster and is responsible for interpreting Kubernetes objects and programming the desired network topologies in eBPF. anetd replaces the service routing and network policy enforcement that is otherwise performed by kube-proxy and Calico respectively in the kube-system namespace.

GKE Dataplane V2 and kube-proxy

GKE Dataplane V2 does not use kube-proxy except on Windows Server node pools on GKE versions 1.25 and earlier.

Technical specifications

GKE Dataplane V2 supports clusters with the following specifications:

Specification GKE Anthos clusters on VMware Anthos on bare metal
Number of nodes per cluster 5000* 500 500
Number of Pods per cluster 50,000 15,000 27,500
Number of LoadBalancer services per cluster 750 500 1,000

GKE Dataplane V2 maintains a service map to keep track of which services refer to which Pods as their backends. The number of Pod backends for each service summed across all services must all fit into the service map, which can contain up to 64,000 entries. If this limit is exceeded your cluster may not work as intended.

* Starting in Kubernetes versions 1.23, the 500 node per Dataplane v2 cluster limit has been raised to 5000, with the following additional conditions imposed on clusters:

  • Private clusters or public clusters that use Private Service Connect. To check if your cluster uses Private Service Connect, see Public clusters with Private Service Connect.
  • Regional clusters only
  • Clusters that use Cilium CRDs (CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy) cannot scale to 5000 nodes. The number of LoadBalancer services supported in Anthos clusters on VMware depends on the load balancer mode being used. 500 LoadBalancer services are supported on Anthos clusters on VMware when using bundled load balancing mode (Seesaw) and 250 are supported when using integrated load balancing mode with F5. See Scalability for more information.

Limitations

The following limitations apply in GKE, Anthos clusters on VMware, and all other environments:

  • GKE Dataplane V2 can only be enabled when creating a new cluster. Existing clusters cannot be upgraded to use GKE Dataplane V2.
  • If you enable GKE Dataplane V2 with NodeLocal DNSCache, you cannot configure Pods with dnsPolicy: ClusterFirstWithHostNet, or your Pods will experience DNS resolution errors. This limitation was lifted starting with 1.20.12-gke.500 (Stable).
  • Starting in GKE version 1.21.5-gke.1300, GKE Dataplane V2 does not support CiliumNetworkPolicy or CiliumClusterwideNetworkPolicy CRD APIs.

Network policy enforcement without GKE Dataplane V2

See Using network policy enforcement for instructions to enable network policy enforcement in clusters that don't use GKE Dataplane V2.

What's next