Hello and welcome to VPC-Native Clusters. In this lesson, we are going to talk a bit about VPC-Native clusters, their benefits, their restrictions, and considerations to take into account when creating them and configuring them.

When you deploy a cluster that uses alias IP address ranges, it’s referred to as a VPC-native cluster. The Pod IP addresses in a VPC-native cluster are natively routable within not only the VPC network that the cluster is attached to, but also within any VPC networks that are connected to its VPC network through Network Peering.

Because the IP addresses for the pods in a VPC-native cluster are reserved in the cluster’s VPC before the pods are created, IP address conflicts with other resources in the VPC are avoided.

I should mention that a VPC-native cluster’s Pod IP address ranges do not depend on static routes. This means that you don’t have to worry about them chewing up your system-generated routes quota, or even your custom static routes quota. Instead, routing for a VPC-native cluster is handled by automatically generated subnet routes.

As far as firewall rules go in the context of VPC-native clusters, firewall rules can be created and applied to the Pod IP address ranges, rather than IP addresses on the cluster nodes themselves. And speaking of Pod IP address ranges, those ranges can be accessed from on-prem networks that are attached to the VPC via Cloud VPN or through Cloud Interconnect via Cloud Routers.

It’s important to keep in mind that once you’ve created a VPC-native cluster, you cannot convert it into a routes-based cluster. The same goes for routes-base clusters. They cannot be converted into VPC-native clusters. As you would expect, you cannot create VPC-native clusters on legacy networks. They must be created on VPC networks, hence the term “VPC-native clusters”.

Whenever you deploy a VPC-native cluster, there are three different subnet IP ranges that are used by the cluster. These ranges include the subnet’s primary IP range for all node IP addresses, one secondary IP range that’s for all Pod IP addresses, and then another secondary IP range for all cluster IP addresses, or service addresses.

The node IP addresses in the Nodes range are assigned from the Primary IP range for the subnet that’s associated with the cluster being deployed. The image on your screen depicts the maximum number of nodes that can be created in all clusters that use the subnet, given the size of the subnet's primary IP address range.

Pod IP addresses, or the Pods range, are IP addresses that are taken from the cluster subnet’s secondary IP range for Pods. The image on your screen shows the maximum number of nodes and Pods you can create in all clusters that use the subnet, given the size of the subnet's secondary IP address range used by Pods:

The Services range, or service addresses, are taken from the cluster subnet’s secondary IP range for Services. The image on your screen shows the maximum number of Services you can create in a single cluster using the subnet, given the size of the subnet's secondary IP address range for Services:

Before we wrap this lecture up, I just want to touch on some things you need to consider when deploying a VPC-native cluster in a Shared VPC. First and foremost, if you determine that you need to deploy a VPC-native cluster in a shared VPC, you’ll need someone who is either a project owner, editor, or who is an IAM member with the Network Admin role in the Shared VPC to do some prep work for you. This user will need to create the cluster’s subnet and secondary IP ranges manually. 

It’s also important to note that to create a cluster in a shared VPC as a service project admin, you’ll need at least subnet-level permissions to the subnet in the Shared VPC network’s host project. 

Join me in the next lecture, where I’ll explain the use of cluster network policies for configuration enforcement of network policies in GKE.