SPEAKER: Hello, everyone.
Welcome to part 2 on how to achieve seamless operations
with GKE load balancing.
Please check out the link in the description
below for part 1 of this video series
that talks about GKE load balancers
and the different load-balancing options
available for GKE clusters.
The content creators for this video
are Aishwarya Rajeev and Shakeel Ahmed Siddiqui,
who are technical account managers for Google Cloud
Consulting.
They are specialized in Google Kubernetes
Engine and networking.
This video covers the best practices
for setting up Load Balancers, health checking, and Pod
lifecycle, and Load Balancers to be used for Cluster Node
Operations.
So let's get started.
After choosing the right GKE load balancer for your needs,
the next step would be to understand the best practices
to configure either a layer 4 or layer 7 load balancer.
The first best practice to set up a layer 7 load balancer
is to keep the container native load balancing on,
which is configured by default. Container-native load balancer
is a great way to get started with layer 7 load balancing
on GKE.
It's easy to use and provides good performance
and reliability.
And, hence, there is no need to disable it,
unless you have a specific reason to do so.
Next, Google will not infer the correct health check
for your HTTPS services.
Hence, you will have to describe it with a BackendConfig,
using Ingress or GCPBackendPolicy with Gateway.
Container-native load balancer uses
the health checks you define in your Ingress or Gateway
resources to determine whether your Pods are
healthy and able to serve traffic.
If you don't define any health checks,
Container-native load balancer will use a default health
check.
However, the default health check
is not always accurate or comprehensive.
Hence, it is best to define your own health checks
to ensure your Pods are only exposed to traffic
when they are healthy.
If you need to have advanced traffic management capabilities
or more managed certificates while using layer 7 load
balancers, use Gateway API.
Gateway API supports the most up-to-date HTTPS load
balancers.
Gateway API is a more powerful API than Ingress,
and it supports advanced traffic management features,
such as Canary releases and more managed certificates
than Ingress.
The first best practice for a layer 4 load balancer
is to use a GKE load balancer controller.
Use GKE subsetting for layer 4 internal load balancers.
However, it is not available by default for layer 4 load
balancers and must be used as an add on.
Next, use regional backend services,
which require an annotation instead of target pool.
Regional load balancers are more scalable and resilient
than zonal load balancers.
Use a local external traffic policy only
when you need to preserve the client IP.
Use standalone network endpoint group plus load balancer
if you need a layer 4 proxy load balancer.
To use standalone network endpoint
groups plus load balancer, create a network endpoint group
and associate it with a load balancer.
Let us now look at some best practices that
need to be followed while serving applications
using load balancers.
While creating external and internal applications,
make sure you use the right load balancer type
and set the options correctly.
Use container-native load balancing and appropriate GKE
resources, health checks, and backend services
for efficient handling of HTTPS traffic,
both internally and externally.
Moving on, it's important to understand
that there are particular sequences of events
that occur when pods are created and destroyed.
The state of a pod in its contained applications
is determined by a variety of signals
that will tell the GKE platform when and when not to serve
traffic to a Pod instance.
This has downstream implications on whether traffic
reaches a healthy and ready Pod and can directly
impact the user experience.
Let's now learn about the entire Pod
lifecycle and the different health
checks that can be configured.
Like individual application containers,
Pods are considered relatively ephemeral, rather than durable.
When a user or controller, such as an autoscaler,
initiates the creation of a Pod that belongs to a service,
controllers react independently to the event
in the following ways.
As seen, Kubelet flow, marked in green dotted
lines, where the Kubelet watches the API
server for pod resources.
Endpoint Controller flow, marked in yellow dotted
lines, where the endpoint controller
watches for Pods matching service label selectors.
When a matching Pod is ready, it's added as an endpoint
to a service.
The controller modifies endpoint resources in the API server.
Network Endpoint Group Controller flow,
marked in red dotted lines, which
monitors the API server for Pod endpoints and service
Resources.
Pods may shut down for a variety of reasons.
Shut down can be initiated by the Pod's controller,
scaling down, updating the image or through failure, Pod, node,
et cetera.
When the Kubelet receives notification
of the pods termination, it starts the shutdown sequence.
When the endpoint controller receives
notification of the Pod termination,
it removes the Pod's IPs.
Endpoints to all the services that
match the Pod and the Network Endpoint Group Controller
leverage their own external Google Compute Engine health
check to determine Pod health.
In GKE, there are two types of health checks
that are used to determine the readiness of Pods.
The GKE Ingress controller uses Kubernetes liveness
and readiness probes to determine the state of a Pod
behind a load balancer.
The result influences the Pod readiness,
which indicates to Kubernetes whether pods
must be rescheduled.
This probe also indirectly influences the endpoints
that appear in a network endpoint group
and to identify when a container is ready to start
accepting traffic.
Additionally, you can use the kubectl drain command
to safely evict all of your Pods from a node
and will respect the Pod distribution budgets
that you have specified.
To summarize, load balancing and health checks
work together to seamlessly distribute traffic.
Next, let's explore the cluster node
operations and the best load balancer type
to be used for each case.
There are four different scaling operations
available for the clusters, being Horizontal Pod
Autoscaler, Vertical Pod Autoscaler, Cluster Autoscaler,
and Node Autoprovisioning.
Horizontal Pod Autoscaling, HPA, and Vertical Pod Autoscaling,
VPA, are two different ways to scale your Kubernetes
workloads.
HPA automatically adds or removes pods
to a deployment or replication controller
based on CPU utilization.
VPA automatically increases or decreases
the resources allocated to a Pod based on CPU utilization.
Cluster Autoscaler and Node Auto-Provisioning
are Kubernetes features that can help you automatically
scale your Kubernetes cluster.
Cluster Autoscaler automatically adds or removes nodes
from your cluster based on resource demand.
Node Auto-Provisioning automatically
creates new node pools when needed.
If we are looking to achieve load balancer based scaling,
we will need to create a Horizontal Pod Autoscaling
object.
Load balancer-based autoscaling scales your Pods
based on the number of requests received by a load balancer.
This can be useful for applications
that experience spikes in traffic,
as you can automatically add more pods
to handle the increased load.
The HPA object specifies the desired number
of Pods, the target metric, and the scaling policy.
HPA uses target metrics to scale the number of Pods.
The scaling policy specifies how the HPA
will scale the number of pods.
Once you have created the HPA object,
Kubernetes will automatically scale the number of Pods
in your deployment based on the target metric and the scaling
policy.
If you are using Kubernetes, we recommend
that you consider load balancer-based
autoscaling to improve the performance, scalability,
and reliability of your applications.
As we have seen previously, GKE's Cluster Autoscaler
automatically resizes the number of nodes
in a node pool based on demand.
This can increase availability and control costs.
You specify a minimum and maximum size,
and the rest is automatic.
However, workloads may experience transient disruption
during autoscaling.
Therefore, to target Pods running on node pools
with Cluster Autoscaler enabled, use container-native load
balancers.
Finally, let's describe preemptible Virtual Machines,
VMs, and the kind of load balancing to be used.
Preemptible VMs are priced lower than standard VMs
and provide no guarantee of availability.
They offer similar functionality to Spot VMs
but only last up to 24 hours after creation.
Since there is no availability guarantee,
it's recommended that you use container-native load balancing
for backend Pods running on preemptible nodes.
In addition, you can be more aggressive
and configure a load balancer health check to promptly remove
bad endpoints.
You have reached the end of this video.
We hope you found the content informative and useful.
Check out the links in the description
to learn more about load balancing in GKE,
or take some Google Cloud Skills Boost hands-on labs
on load balancing.
Happy cloud computing.