Does GKE use an overlay network?

2
votes

GKE uses the kubenet network plugin for setting up container interfaces and configures routes in the VPC so that containers can reach eachother on different hosts.

Wikipedia defines an overlay as a computer network that is built on top of another network.

Should GKE's network model be considered an overlay network? It is built on top of another network in the sense that it relies on the connectivity between the nodes in the cluster to function properly, but the Pod IPs are natively routable within the VPC as the routes inform the network which node to go to to find a particular Pod.

1
networkingkubernetesgoogle-compute-enginegoogle-kubernetes-engine
Generally not, but some aspects could be considered like an overlay: For example services and how they are setup with iptables rules on the nodes. However this question sounds a bit like the XY Problem, what problem are you trying to solve? – mensi
I'm not really trying to solve a problem, I literally just want to know whether I should refer to GKE's networking setup as an overlay network or not and why - I seem remember it being said that GKE does not use an overlay network (unfortunately I can't remember where so I can't confirm that) and I want to know why GKE doesn't conform the definition I linked above – dippynark
I wouldn't say the service implementation would have anything to do with whether the network is defined as an overlay or not, but maybe that is case – dippynark

1 Answers

0
votes

VPC-native and non VPC native GKE clusters uses GCP virtual networking. It is not strictly an overlay network by definition. An overlay network would be one that's isolated to just the GKE cluster.

VPC-native clusters work like this:

Each node VM is given a primary internal address and two alias IP ranges. One alias IP range is for pods and the other is for services. The GCP subnet used by the cluster must have at least two secondary IP ranges (one for the pod alias IP range on the node VMs and the other for the services alias IP range on the node VMs).

Non-VPC-native clusters:

GCP creates custom static routes whose destinations match pod IP space and services IP space. The next hops of these routes are node VMs by name, so there is instance based routing that happens as a "next step" within each VM.

I could see where some might consider this to be an overlay network. I don’t believe this is the best definition because the pod and service IPs are addressable from other VMs, outside of GKE cluster, in the network.

For a deeper dive on GCP’s network infrastructure, GCP’s network virtualization whitepaper can be found here.