Google Kubernetes Engine Clusters
Configuring and Managing Firewall Rules
The course is part of these learning paths
This course explores how to implement virtual private clouds on the Google Cloud Platform. It starts off with an overview, where you'll be introduced to the key concepts and components that make up a virtual private cloud.
After covering basic VPC concepts and components, we'll dive into peering VPCs, shared VPCs, and VPC flow logs, including a hands-on demonstration of how to configure flow logs. We’ll also look at routing and network address translation, before moving on to Google Kubernetes Engine clusters. We’ll cover VPC-native clusters and alias IPs, as well as clustering with shared VPCs.
You’ll learn how to add authorized networks for GKE cluster master access and we finish off by looking at firewall rules. We’ll cover network tags, service accounts, and the importance of priority. You’ll also learn about ingress rules, egress rules, and firewall logs.
If you have any feedback related to this course, feel free to contact us at email@example.com.
- Get a foundational understanding of virtual private clouds on GCP
- Learn about VPC peering and sharing
- Learn about VPC flow logs and how to configure them
- Learn about routing in GCP and how to configure a static route
- Understand the pros and cons of VPC-native GKE clusters
- Learn about cluster network policies
- Understand how to configure and manage firewall rules in GPC
This course is intended for anyone who wants to learn how to implement virtual private clouds on the Google Cloud Platform.
To get the most from this course, you should already have experience with the public cloud and networking, as well as an understanding of GCP architecture.
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.
Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions.
In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs.
In his spare time, Tom enjoys camping, fishing, and playing poker.