Friday, February 7, 2025

GKE Dataplane V2: Best Solution For Kubernetes Networking

GKE Dataplane V2 Overview

One dataplane designed specifically for Kubernetes networking is GKE Dataplane V2. It offers:

  • A reliable networking user experience.
  • View of network activities in real time.
  • Simpler architecture that facilitates cluster management and troubleshooting.

By default, all newly created Autopilot clusters have GKE Dataplane V2 enabled.

How GKE Dataplane V2 works

It is implemented using eBPF. The kernel’s eBPF routines determine how to route and handle packets once they reach a GKE node. Programs using eBPF can leverage Kubernetes-specific metadata in the packet, unlike those using iptables for packet processing. This enables it to report annotated activities back to user space for logging and handle network packets in the kernel more effectively.

Using it, the packet’s journey across a node is depicted in the following diagram:

Using GKE Dataplane V2
Image Credit To Google Cloud

It controller is deployed by GKE as a DaemonSet called anetd to every cluster node. Anetd programs network topologies in eBPF and reads Kubernetes objects. The kube-system namespace is where the anetd pods operate.

GKE Dataplane V2 NetworkPolicy

Cilium is used in the implementation of GKE Dataplane V2. Calico is used to implement GKE’s legacy dataplane.

Kubernetes NetworkPolicy is managed by both of these technologies. The Calico Container Network Interface (CNI) makes use of iptables in the Linux kernel, whereas Cilium utilizes eBPF.

Advantages

Scalability

The scalability features of GKE Dataplane V2 differ from those of previous data planes.

GKE eliminates several iptables-related bottlenecks, such the number of services, for GKE versions where it does not employ kube-proxy and does not depend on iptables for service routing.

The eBPF maps that GKE Dataplane V2 uses are restricted to 260,000 endpoints for all services.

Safety

Clusters using it always have Kubernetes NetworkPolicy enabled. Network policy enforcement does not need you to install and maintain third-party software add-ons like Calico.

Activities

With GKE Dataplane V2, network policy logging is included into the cluster creation process. To know when connections are permitted and prohibited by your pods, set up the logging CRD on your cluster.

Regularity

The networking experience offered by GKE Dataplane V2 is reliable.

Technical specifications

Clusters that meet the following requirements are supported by GKE Dataplane V2:

SpecificationGKEGoogle Distributed Cloud EdgeGoogle Distributed Cloud Hosted
Number of nodes per cluster7,500500500
Number of Pods per cluster200,00015,00027,500
Number of Pods behind one Service10,0001,0001,000
Number of Cluster IP Services10,0001,0001,000
Number of LoadBalancer Services per cluster7505001,000

To keep track of which Services use which Pods as their backends, GKE Dataplane V2 keeps a Service map. The Service map, which has a maximum of 260,000 entries, must contain the total number of Pod backends for all Services. Your cluster might not function as planned if this limit is exceeded.

Restrictions

The following are the limitations of it:

  • Only while establishing a new cluster may it be activated. It cannot be used to update existing clusters.
  • You cannot configure Pods with dnsPolicy: ClusterFirstWithHostNet in GKE versions prior to 1.20.12-gke.500 if you activate GKE Dataplane V2 with NodeLocal DNSCache. Otherwise, your Pods will encounter DNS resolution issues.
  • GKE Dataplane V2 no longer supports the CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy CRD APIs as of GKE version 1.21.5-gke.1300. Versions 1.28.6-gke.1095000 and 1.29.1-gke.1016000 of GKE are the first to allow CiliumClusterwideNetworkPolicy to be enabled on either new or existing clusters.
  • Internal passthrough load balancers that are manually constructed and linked to a NodePort service type are not supported.
  • Your Pod performance may be impacted if you have workloads with a significant Pod churn since it uses eBPF to optimize eBPF kernel packet processing. Achieving optimum eBPF is the main goal of it.
  • Multi-cluster services with multiple (TCP/UDP) ports on GKE Dataplane V2 are known to have a problem.
  • GKE Dataplane V2 implements Kubernetes Services using Cilia rather than Kube-proxy. Since the Kubernetes community develops and maintains kube-proxy, new functionalities for services are more likely to be added there before being added to cilium for GKE Dataplane V2. The KEP-1669: Proxy Terminating Endpoints feature is an illustration of a Services feature that was initially included in kube-proxy.
  • To prevent connection problems, you must add the PUPI range of the Pods in nonMasqueradeCIDRs to the ip-masq-agent ConfigMap for NodePort Services running version 1.25 or earlier utilising default SNAT and PUPI ranges.
  • It agent Pods (anetd) have the potential to use up to two or three vCPUs per instance in some circumstances. This happens when the node has a large number of TCP connections that are being opened and terminated quickly. We advise using connection pooling for the pertinent workloads and keep-alives for HTTP calls in order to lessen this issue.
  • The service is not supported by GKE Dataplane V2 clusters with control plane versions 1.27 or below.field spec.internalTrafficPolicy. Cluster is a service’s efficient internal traffic policy; backends on any node are taken into consideration for service resolution.
  • eBPF is used by GKE Dataplane V2 to control network traffic in your cluster. Installing a third-party program that also makes use of eBPF may cause issues for it.

For instance, your Pods may not be able to connect to Services if you are using Retina with GKE Dataplane V2. This occurs as a result of Retina’s eBPF programs interfering with GKE Dataplane V2’s traffic routing. You may be experiencing this problem if you notice error messages saying that traffic is being lost because it is attempting to contact the Service’s IP address directly. This is because communication must pass via Dataplane V2’s routing algorithms and pods are not permitted to directly reach the Service’s IP address.

Kube-proxy with GKE Dataplane V2 together

Kube-proxy is not used by GKE Dataplane V2, with the exception of Windows Server node pools running GKE versions 1.25 and earlier.

Enforcement of network policies without it

To enable network policy enforcement in clusters that do not employ GKE Dataplane V2, use network policy enforcement instructions.

Thota nithya
Thota nithya
Thota Nithya has been writing Cloud Computing articles for govindhtech from APR 2023. She was a science graduate. She was an enthusiast of cloud computing.
RELATED ARTICLES

Recent Posts

Popular Post

Govindhtech.com Would you like to receive notifications on latest updates? No Yes