In this course, you will learn about some of the more advanced options available when creating a Google Kubernetes Engine cluster.
You will learn the main differences between:
- Standard vs. Autopilot clusters
- Private vs. Public clusters
- Zonal vs. Regional clusters
- Routes-based vs. VPC-native clusters
- GCP Network Engineers
- GCP Security Engineers
- Anyone preparing for a Google Cloud certification (such as the Professional Cloud Network Engineer exam)
- Basic understanding of Kubernetes and GKE
- Some experience building and deploying containers
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:
Your Pod IP addresses are natively routable within the VPC
Your Pod IP addresses are also accessible via Cloud VPN and Cloud Interconnect
Since addresses are all pre-reserved, this prevents IP conflicts with other resources
Pod IP address ranges do not count against your static routes quota
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.
Daniel began his career as a Software Engineer, focusing mostly on web and mobile development. After twenty years of dealing with insufficient training and fragmented documentation, he decided to use his extensive experience to help the next generation of engineers.
Daniel has spent his most recent years designing and running technical classes for both Amazon and Microsoft. Today at Cloud Academy, he is working on building out an extensive Google Cloud training library.
When he isn’t working or tinkering in his home lab, Daniel enjoys BBQing, target shooting, and watching classic movies.