GKE Load Balancing: Overview

Key Takeaways

hello everyone and welcome to this video on how to achieve seamless operations with gke load balancing the content creators for this video are Aishwarya Rajiv and Shakil Ahmed Siddiki who are technical account managers for Google Cloud Consulting and are specialized in Google kubernetes engine and networking in this video we will go over understanding gke load balancers the different load balancers that are supported by gke and how to choose the right load balancer for your use case in addition you will gain a deeper understanding of container native load balancing so let's get started to begin with what is a gke load balancer gke load balancers are used to distribute traffic to pods in a kubernetes cluster gke provides a variety of kubernetes native constructs like service Ingress Gateway and network endpoint groups to manage layer 4 and layer 7 load balancers on Google Cloud we will learn more about these constructs in this video you can create a gke load balancer either by using the kubernetes API or the kubexl command line tool gke load balancers work by routing traffic to pods based on a set of rules these rules can be based on the hostname path or HTTP method of the requests when a client sends a request to the load balancer the load balancer first checks the routing rules to see which rule matches the request if a rule matches the load balancer then routes the request to the Pod that is associated with the rule and if no rule matches the request the load balancer will route the request to a pod randomly gke load balancers use a round robin algorithm to distribute traffic across the pods that match a rule Additionally you can also configure gke load balancers to use different algorithms like weighted round robin algorithms for Distributing traffic to better comprehend we can expose Services outside a cluster let's define some terms like node Port service load balancer service Ingress and Gateway a node Port is used to expose a service on each node's specific port cluster IP is the cluster's internal IP the load balancer service is useful for routing traffic between services in the same network Ingress Gateway creates https load balancers by using an Ingress resource however https load balancers are designed to terminate https requests and can make better context aware load balancing decisions they offer features like customizable URL maps and TLS termination gke automatically configures health checks for https load balancers if you are exposing an https service hosted on gke https load balancing is the recommended method there are a few challenges when operating seamless services with gke however gke is a powerful platform for running kubernetes clusters by carefully planning and managing your gke cluster you could overcome these challenges and deliver a seamless experience for your users let us look at some common load balancing challenges with gke when traffic reaches a kubernetes node it is handled the same way regardless of the type of load balancer the load balancer is not aware of which nodes are running pods for its service therefore it balances traffic across all nodes in the cluster even those not running a relevant pod on a regional cluster the load is spread across all nodes in all zones for the Clusters region when traffic is routed to a node the node routes the traffic to a pod which may be running on the same node or a different node additionally clusters are dynamic in nature meaning that pods can be created and destroyed at any time this can make it difficult to track which pods are healthy and available to receive traffic traffic can also get forwarded to a pod on a different node this requires extra Network hops if you want to avoid the extra hops you can specify that traffic must go to a pod that is on the same node that initially received the traffic throughout this video you'll learn how to achieve seamless Services over the network and to minimize or eliminate traffic disruption let's now transition to gke supported load balancers gke offers diverse load balancing options through the Ingress and service API resources these options include internal or external load balancing layer 3 layer 4 supporting TCP and UDP protocol or layer 7 supporting HTTP and https and Global and Regional scopes this table Maps gke objects to Google Cloud load balancers where the gke resource and gcp resource columns correspond to each other the gke resources are used to expose kubernetes services to the outside world while the gcp resources are the underlying load balancers that handle the traffic additionally let's take a moment to describe a Gateway class a Gateway class is a resource that defines a template for TCP UDP layer 4 load balancers and https layer 7 load balancers in a kubernetes cluster gke provides Gateway classes as cluster scoped resources cluster operators specify a Gateway class when creating gateways in their clusters hence to summarize gke supports three types of load balancers layer 4 TCP UDP pass-through load balancers which forward traffic to pods within the same cluster without proxy and processing you can create it using the service API with the type load balancer annotation layer 4 TCP UDP proxy load balancers which forward traffic to pods within the same cluster with proxy and capabilities for tasks like SSL termination and header rewriting it is created using Standalone Network endpoint groups and an external load balancer and lastly layer 7 https proxy load balancers which forward traffic to pods within the same cluster with proxyin and https routing capabilities you can create it using the Gateway API or the Ingress API let's now see what a gke load balancer controller is and how you can use one for internal load balancing gke load balancer is at kubernetes add-on that uses Google Cloud load balancing to distribute HTTP and https traffic across pods they are scalable highly available easy to use add-ons that integrate with Google Cloud load balancing they can be configured via yaml the controller is composed of two parts the first part runs in control plane nodes and watches load balancer services and Ingress API the second part runs in the infrastructure and watches multi-cluster Ingress and Gateway apis in order to use this controller enable the add-on in your gke cluster and then create an Ingress resource to Define traffic routing the controller will then create and manage load balancer resources now let us understand the gke Gateway controller and how it is used for external load balancing the Gateway controller is Google's implementation of the Gateway API for cloud load balancing similar to the gke Ingress controller the Gateway controller watches a kubernetes API for Gateway API resources and reconciles Cloud load balancing resources it then implements the networking Behavior specified by the Gateway resources the gke Gateway controller is essentially an evolution of Ingress there are two versions of the gke Gateway controller single cluster manages single cluster gateways for a single gke cluster this controller is generally available multi-cluster manages multi-cluster gateways for one or more gke clusters both Gateway controllers are Google hosted and monitor the kubernetes API for gke clusters unlike the gke Ingress controller the Gateway controllers are not hosted on gke control planes or in the user's project making them more scalable and robust finally let's explore gke Ingress which exposes kubernetes services to the internet there are two gke Ingress types Ingress for external https load balancers deploys the global external https load balancer this internet-facing load balancer is deployed globally across Google's Edge Network as a managed and scalable pool of load balancing resources the second type Ingress were internal https load balancers which deploys the internal https load balancer these internal https load balancers are powered by Envoy Proxy Systems outside of your gke cluster but within your VPC Network now here's the big question how do you choose the right load balancer there are so many options when choosing which load balancer service configuration to use for layer 4 consider the following aspects first the IP address type which means whether your load balancer can have an internal or an external IP address next what type and how many nodes does the load balancer support after you determine your network architecture requirements use this decision tree to determine which load balancer service is best for your network configuration to choose a layer 7 load balancer you must understand the difference between gke Ingress and Gateway Ingress is a kubernetes object that provides routing rules for HTTP and https traffic they can be used to expose services to the internet or to the other services within a cluster and can be configured to use a variety of Ingress controllers including the gke Ingress controller a Gateway is a powerful and flexible kubernetes API used to Route traffic and they support a wide range of protocols including HTTP https TCP and UDP it can create complex routing configurations including multi-cluster routing configurations which allow traffic to be routed between clusters in a distributed environment note that Ingress is a legacy object that has been superseded by Gateway although Ingress is still supported in gke it is recommended that you use Gateway instead finally after understanding how to choose the right load balancers let's briefly discuss container native load balancers container native load balancing load balances directly to pod endpoints in gke using network endpoint groups which let the compute engine load balancers communicate directly with pods traffic is then distributed directly to the Pod IPS as opposed to traversing the virtual machine IPS and Kube proxy networking currently container native load balancing is only supported on layer 7 load balancers and is enabled by default container native load balancing must be used when exposing Services by using https externally deploying Ingress with network endpoint groups is highly recommended as container native load balancing allows for fewer Network hops lower latency and more precise traffic distribution it also increases visibility and enables the use of features such as Cloud CDN and Cloud armor in addition it increases visibility all the way to the Pod and fixes rolling upgrades this concludes the gke load balancer overview to learn more about the best practices for configuring layer 4 and layer 7 load balancers with gke click the link in the description below until then Happy cloud computing foreign