GKE clusters have two main ways to route traffic from one pod to another.  A cluster can either use Alias IPs or it can use Google Cloud routes.  IP aliasing is when you assign more than one IP address to a network interface.  So in this method, you assign a whole range of IPs to your cluster, so it can use those IPs for different Nodes, Pods and Services.  GKE will then hand out those IP addresses as needed.

Google Cloud routes are just custom static routes that you manually define in a VPC.  So in this second method, you have to manually manage the routes yourself.  It works very similarly to creating static routes for VMs.

So we call a cluster that uses Alias IPs a VPC-native cluster.  And when creating a VPC-native cluster you specify a subnet to use for allocating IP addresses.  The cluster then creates three ranges.  The first range is used for Nodes.  The second range is used for Pods.  And the third range is used for Services.  When specifying the subnet during cluster creation, you must ensure the range is large enough to provide enough addresses for everything.  For example, if you are planning to run 1000 nodes, then your primary subnet should be at least a /22.  That would give you about 1020 addresses to work with.

A cluster that uses Google Cloud routes is called a Routes-based Cluster.  A Routes-based Cluster handles IP allocation differently.  Instead of specifying a single CIDR range, you manually create IP address ranges to use for Pods and Services.  A Routes-based Cluster requires using the Kubernetes control plane to maintain static routes to each Node.  

VPC-native is considered best practice, and is highly recommended for most clusters.  There really are no drawbacks, and you get a number of benefits:

1. Your Pod IP addresses are natively routable within the VPC

2. Your Pod IP addresses are also accessible via Cloud VPN and Cloud Interconnect

3. Since addresses are all pre-reserved, this prevents IP conflicts with other resources

4. Pod IP address ranges do not count against your static routes quota

5. You can create firewall rules that only apply to your Pod IPs instead of whole IP ranges

Basically, you should always choose VPC-native mode, unless you have a very specific requirement. So now, let me quickly show you how to create a VPC-native cluster and a Routes-based cluster.  Make sure you log in to the GCP console, navigate to the GKE page, and then start by clicking on Create.

Autopilot will automatically choose to create a VPC-native cluster.  You cannot override this.  So the easiest way to get a VPC-native cluster is to choose Autopilot.  A Standard cluster can be configured to be either VPC-native or Routes-based, so let me show you how to set that up.

You can toggle between the two options once you go to the Networking tab.  By default your Standard cluster is set to use VPC-native mode.  But if you want Routes-based, you just need to uncheck this box.  Now, that is all that is required to toggle between the two options, but each option still requires that you do some additional configuration.

For a Standard Routes-based cluster, you will also need to manually add valid routes.  For a Standard VPC-native cluster, you need to specify the Pod and Service IP ranges to use.  And if you would like to personally manage the secondary ranges, you can manually create those yourself and then uncheck this box as well.

Again, most of the time you are going to stick with VPC-native mode.  There are only a few edge cases that might require you to create a Routes-based cluster.