I'm confused with the documentation on GKE. In the Compare network models doc, it says GKE has a fully integrated networking model which suggests to me it has its own CNI implementation. However, in the Network policies section, it says something about Calico. Yet, when I tried to check the config directory on one of the worker nodes of my GKE cluster - `/etc/cni/net.d`, I noticed a config file named `10-containerd-net.conflist` which would suggest a containerd CNI plugin?
Also in the Dataplane V2 doc, it says it is implemented using Cilium. Do I understand correctly that for clusters with Dataplane V2, GKE uses Cilium CNI, or is it just referring to the Cilium solution as a whole?
Is it possible to configure the CNI used in a GKE cluster in any scenario (with or without Autopilot etc.) and is my understanding of the doc somewhat correct? I'm really confused at this point (probably because of my weak overall understanding of these concepts).
Solved! Go to Solution.
My understanding is the mention of a fully integrated network model simply means a flat networking model. Pod IP range is assigned to each GKE node (GCP VM Instance) using IP aliases and pods that can communicate between each other (*). This doesn't require any Kubernetes Network CNI.
In GKE there is both a Cilium based CNI which is called Dataplane V2 and an older Network Policy feature which is based on the Calico CNI. Both are mutually exclusive. Documentation does mention that although I understand it may be a bit confusing:
> GKE Dataplane V2 is implemented using Cilium. The legacy dataplane for GKE is implemented using Calico.
Ref: https://cloud.google.com/kubernetes-engine/docs/concepts/dataplane-v2#network-policy
Note:
If in doubt and unless you ever plan to use Network Policy at all, I would recommend enabling Dataplane v2. For new Autopilot cluster, it's enabled by default.
(*) To be precise this explanation is for VPC-native cluster which use alias IP ranges. This has been the default for a long time but old Routes-based cluster can still be found (or created if enabled explicitly) and work slightly differently.
My understanding is the mention of a fully integrated network model simply means a flat networking model. Pod IP range is assigned to each GKE node (GCP VM Instance) using IP aliases and pods that can communicate between each other (*). This doesn't require any Kubernetes Network CNI.
In GKE there is both a Cilium based CNI which is called Dataplane V2 and an older Network Policy feature which is based on the Calico CNI. Both are mutually exclusive. Documentation does mention that although I understand it may be a bit confusing:
> GKE Dataplane V2 is implemented using Cilium. The legacy dataplane for GKE is implemented using Calico.
Ref: https://cloud.google.com/kubernetes-engine/docs/concepts/dataplane-v2#network-policy
Note:
If in doubt and unless you ever plan to use Network Policy at all, I would recommend enabling Dataplane v2. For new Autopilot cluster, it's enabled by default.
(*) To be precise this explanation is for VPC-native cluster which use alias IP ranges. This has been the default for a long time but old Routes-based cluster can still be found (or created if enabled explicitly) and work slightly differently.
GKE does not support replacing the built-in CNI implementation(s) it uses.
Dataplane V2 (DPv2) clusters use an ebpf-based CNI achitecture based on Cilium but it is not the Cilium OSS plugin. With DPv2, Kubernetes NetworkPolicy is built-in so there is no need to enabled it.
For non-DPv2 clusters, GKE uses it's own CNI implementation for basic networking functions. If you choose to enable NetworkPolicy on non-DPv2 clusters, then GKE installs a managed version of Calico to provide this functionality and handles the chaining for you.