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 firstname.lastname@example.org.
- 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 routing in GCP. In this lesson, we will take a look at some of the key concepts and components as they relate to routing in Google cloud.
Now before we get into the different concepts of routing, let’s take a look at what Google cloud routes really refer to. A route is essentially the path that network traffic takes from a source VM to another destination. Such destinations can reside inside your VPC or outside of it.
Each defined route in a VPC network will consist of a single destination and a single next hop. What Google cloud will do when a VM instance, for example, in a VPC network sends a network packet, is deliver that packet to whatever the route’s next hop is. This process repeats itself until the packet reaches the destination.
VPC networks in Google cloud will include system-generated routes, custom routes, or a combination of the two.
System generated routes are added and updated automatically whenever you create a VPC network, whenever you add a subnet, expand a subnet, or edit the secondary IP range for a subnet. Routes that apply to a VPC network will apply to all instances attached to that VPC network.
The table on your screen shows what system-generated routes look like.
The default route is used to define the path out of the VPC network to which the route applies. It includes the path to the Internet and provides a standard path for private Google access. A system-generated default route will have a priority of 1000 and a destination of 0.0.0.0/0. What this means is that Google cloud will only use the default route if there are no other routes with more specific destinations defined.
This default route can be replaced with a custom route if necessary. It can also be deleted if necessary. You would typically do this in situations where you wish to completely isolate the network from the Internet or if you want to route Internet traffic to a different next hop. Organizations will sometimes route Internet traffic using a custom static route with a next hop defined as a cloud VPN tunnel or maybe a proxy server.
So now that you know a little bit about the default route, let’s talk about what a subnet route is. Basically, a subnet route is a system-generated route that defines the path to each different subnet within the VPC network. Every existing subnet will have at least one subnet route with a defined destination that matches the primary IP range of that given subnet. In cases where a subnet has been defined with a secondary IP range, Google cloud will also create a subnet route with a destination that corresponds to each defined secondary range.
It’s important to note that subnet routes cannot be deleted unless the associated subnets are modified or deleted first.
Now, let’s talk about custom routes a little bit. Custom routes come in two flavors. They can be static routes or dynamic routes. Static routes are routes that you typically create manually, while dynamic routes are automatically maintained by cloud routers.
It’s important to note that the destinations that you define for custom routes are not allowed to match or be more specific than any existing subnet routes that are already defined in the network.
Static routes that have been defined can use any of the static route next hops. Dynamic routes, as I mentioned, are managed by cloud routers. The destinations for dynamic routes will always represent IP ranges that are outside of the VPC network. On top of that, the next hops that are defined will always be BGP peer addresses.
I should mention that cloud routers can manage dynamic routes for cloud interconnect and for cloud VPN tunnels that leverage dynamic routing.
So, when an instance sends a packet, in what order does Google cloud perform routing?
Well, when an instance sends a packet, Google will consider subnet routes first. It does so because subnet route destinations are the most specific and will match the IP address ranges of each subnet in the network. That being the case, if the destination IP for a packet falls within the destination of a subnet route, Google will deliver that packet to that subnet.
If the packet being sent by the instance does not fit into the destination for a subnet route, Google cloud will try to identify a custom route with the most specific destination defined, and then deliver the packet based on that route. For example, let’s assume that a packet being sent by a VM instance is destined for a device with an IP address of 10.240.1.6. If there are two different routes defined, one with a destination of 10.240.1.0/24 and one with a destination of 10.240.0.0/16, the packet would be delivered via the route with the destination of 10.240.1.0/24, because that is the most specific destination.
Now, what happens if more than one custom route has the same identical, most specific destination? When this happens, Google cloud will run through a process to choose a route from a list of route candidates, which are custom static or dynamic routes that have the same most specific destination.
If Google Cloud determines that there are no applicable destinations found, it will drop the packet and reply to the source with an ICMP destination or network unreachable error.
Before we hop into the next lesson, let’s just take a look at the components that make up a static route. Since you’ll often find yourself manually creating static routes, it makes sense to at least expose you to these components.
When you define a static route, you’ll need to provide a name and description for the route. While the name is required, the description is optional. Route names within a project must all be unique.
Every static route that you create needs to be associated with exactly one VPC network.
The destination range for the route is also required. This range is defined as a single IPv4 CIDR block containing the IP addresses of any instances that receive incoming packets. I should point out that Google cloud does not support IPv6 destination ranges.
When you define a route, you also need to define its priority. The priority comes into play in situations where multiple defined routes have identical destinations. When this happens, Google cloud will use priority to determine which route should be used. I mentioned this earlier. The lower the number, the higher the priority. This means that a route with a priority of 200 has a higher priority than a route with a priority of 400. Consequently, since 0 is the smallest number, a route with a priority of 0 would have the highest priority possible.
The next hop component tells the static route where traffic should be sent next. When defining a static route, you can configure the next hop to be the default Internet gateway, a Google cloud instance, a cloud VPN tunnel, or a load balancer.
And lastly, we have tags. When creating a static route, you can define a list of network tags that tells Google cloud which instances the route applies to. When you define a list of tags, the routes will only apply to instances that include one of the tags that you define. If you create a route without any defined tags, Google cloud will apply that route to all instances in the network.
To learn more about routes in Google Cloud Platform, visit the URL that you see on your screen: https://cloud.google.com/vpc/docs/routes
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.