SPEAKER: Hello, everyone.
In this video, we'll discuss disaster recovery for GKE,
available on Google Cloud.
The content creators for this video
are Tanvi Desai and Aakriti Gupta,
who are technical account managers for Google Cloud.
They have curated the information for you
to have a deeper understanding of how to protect your GKE
workloads in Google Cloud.
Let's talk about why it is important to discuss disaster
recovery and what it looks like for GKE.
We will review how to enable backup for GKE
and see how some of our customers
are finding this feature useful.
Finally, we will share some resources for you
to follow up with.
So let's dive right in.
Why do you need to plan for disaster recovery?
Disasters come in forms that can affect your critical workloads
and business.
It could be in the form of a natural disaster,
like flooding, fires, or earthquakes.
It could be a technological disaster,
such as power outages, cyber attacks, and data breaches.
Or the disaster recovery scenarios
can include human-caused disasters,
such as explosions, terrorist attacks, or huge production
errors.
Disasters can occur any time and in any form.
They are often unavoidable.
The key is to always be prepared with a recovery plan.
No matter what type of disaster strikes,
a disaster recovery plan can help you protect your data,
restore your IT infrastructure, and recover your business
operations.
Now, more than ever, significant infrastructure downtime
can have a devastating impact on an enterprise business.
As shown here, analysts have estimated
the average cost of data center outages around $9,000 a minute.
That's $13 million per day, a potentially huge impact.
And the impact isn't just monetary.
In many cases, the impact to a business's reputation
can be even more catastrophic and take longer
to recover from, if ever.
As a result, enterprises are increasingly
mandating the implementation of robust backup and disaster
recovery solutions to provide them with insurance
against the unexpected.
This can help you to avoid costly downtime,
lost productivity, and even business failure.
By implementing backup and disaster recovery
in Google Cloud, you can help to protect your critical cloud
workflows from a variety of threats.
You can ensure that your business continues
to operate even in the event of a disaster.
This can give you peace of mind and help you to focus
on running your business.
Every workload is unique.
And Google Cloud offers a variety
of protection strategies to choose from, depending
on your business and industry.
It enables on-demand resource allocation
for unprepared events to minimize the cost of support
and help you focus on backing up your critical workloads.
So how do you design strategies for disaster recovery?
Think about, what are the most important things
your organization does?
These are the functions that you need
to make sure can be recovered quickly
in the event of a disaster.
Recovery Time Objective, RTO, is the goal
your organization sets for the maximum length of time
it should take to restore normal operations following an outage
or data loss.
Recovery Point Objective, RPO, is your goal
for the maximum amount of data the organization can tolerate
losing.
You will need to determine how much data you need to protect
and how quickly you need to be able to recover
when the disaster happens.
The lower the RTO and RPO requirements are,
the cost of disaster recovery gets higher.
What are the types of disasters that
are most likely to impact your organization?
Once you know what risks you face,
you can start to develop strategies to mitigate them.
Your recovery plan should include steps
for recovering each of your critical business functions.
It should also include a timeline
for recovery and a budget.
It's important to review your recovery plan regularly,
run tabletop exercises, and simulate disaster scenarios
to make sure your disaster recovery plan is effective
and up to date.
Consider the additional costs and capacity needed
for running these exercises.
Make sure the key stakeholders in your organization
know their role and understand your disaster recovery plan.
While planning for disaster recovery, be flexible.
No two disasters are the same.
So your recovery plan should be flexible enough
to adapt to different situations.
Get help from experts.
If you don't have the expertise in house
to develop a disaster recovery plan,
consider working with Google Cloud experts.
Let's talk about Google Cloud's high-level approach
on disaster recovery on GKE by discussing its key components.
GKE Node Auto Repair repairs unhealthy nodes
in a GKE cluster.
When enabled, GKE will periodically
check the health of each node in the cluster.
If a node fails consecutive health checks over an extended
time period, GKE will initiate a repair process for that node.
The repair process for an unhealthy node
may involve one or more of the following steps.
GKE will start draining the node by stopping scheduling
new pods on the node.
It will then replace the node and migrate pods
from the unhealthy node to the new node.
Lastly, GKE will scale the cluster
by creating additional nodes in the cluster
to compensate for the loss of the unhealthy node.
This will keep your cluster healthy,
reduces manual intervention, improves availability,
and reduces costs.
GKE allows you to specify a liveness check that
will run periodically to ensure your pod is
running successfully.
This mechanism ensures that a container
is running and healthy.
When you configure Liveness Probe in your pod spec,
kubelet checks the health of the pod every 5 seconds.
If the pod fails the liveness probe three times in a row,
it will be restarted.
GKE safeguards your storage availability
by mapping to persistent disks through persistent volume
abstraction.
Persistent volumes are a Kubernetes resource
that provides a way to store data
that persists even if the pods that use the data are deleted.
They are backed by physical storage, such as Google Compute
Engine persistent disks.
This can be useful for storing data
that needs to be available even if a pod fails or is restarted.
The multi-cluster gateway supports
internal and external load balancing, weight-based traffic
splitting, traffic capacity-based load balancing,
and traffic mirroring between your clusters.
Multi Cluster ingress lets you configure shared load balancing
of resources across multiple GKE clusters in different regions.
It improves application availability,
reduces operational complexity, and increases scalability,
and provides a single entry point for users
to access applications, and manages traffic
across multiple clusters.
Spreading the Kubernetes control plane and its nodes
across different zones or regions for the workloads
is very important to achieve high availability.
One option is choosing to deploy your Kubernetes workload
in a regional or a zonal cluster.
Second, within zonal, GKE offers two types of node pools--
single zone and multi-zonal.
Single-zone clusters have one control plane machine
and worker nodes in the same zone.
Multi-zonal clusters are similar to zonal clusters.
But they span nodes across multiple zones.
A regional, or multi-zonal, cluster
will provide a highly available cluster.
Regional clusters are better suited for high availability,
as they have multiple control planes
across multiple compute zones in a region,
while zonal clusters have one control
plane in a single compute zone.
However, if cost is a factor or your workload is not
as critical, a multi-zonal cluster
could be a better choice.
In regional clusters, the control plane
remains available during cluster maintenance, like rotating IPs,
upgrading control plane VMs, or resizing clusters or node
pools.
When upgrading a regional cluster,
two out of three control plane VMs
are always running during the rolling upgrade.
So the Kubernetes API is still available.
Similarly, a single-zone outage won't cause any downtime
in the regional control plane.
Backup for GKE is a fully managed service
that helps you protect, manage, and restore your Kubernetes
workloads and data in a simple, scalable, and secure way.
Let's hear what one of our customers
is saying about backup for GKE.
Jose Chavez, SaaS platform and delivery engineer at Broadcom
says, "Backup for GKE makes it easier
for us to protect our stateful workloads in GKE.
And it makes restoring those stateful workloads
much simpler and faster.
We see integrated backup as another sign of GKE's maturity
for stateful workloads.
And we look forward to using it to serve
our worldwide internal customers at Broadcom."
Backup for GKE is a simple way to protect, manage, and restore
your containerized applications and data.
With backup for GKE, you can meet
your service-level objectives and automate common backup
and recovery tasks.
You can protect Kubernetes resources
such as namespaced resources, cluster-wide resources,
and persistent volumes, application data,
including databases, file systems, and logs.
You can seamlessly restore your backups
to a new or existing Kubernetes cluster.
Backup for GKE is configurable, flexible, and easier
to adopt for enterprises.
Backup options allow you to select preferred backup
destinations or select and skip certain resources.
You can configure backup not to include secrets
so the data is not visible via persistent disk control plane.
By enabling time-lock backups, you
can disable manual or automated deletion of backups
to protect from malicious attacks.
All data is encrypted by default with the option
of using customer-managed encryption keys, CMEC.
The restore options let you restore a cluster
into a new cluster or a region and flexibility
of parameterizing the restore options to different storage
classes.
The sub-scope feature lets you restore a specific namespace
or application if it's accidentally deleted
or an upgrade fails.
By delegating an admin, cluster admins
can give access to app admins to do ad hoc backups
before critical application upgrades.
This diagram shows the relationship
between the different components for backup in GKE.
The resource-based REST API-based service
serves as the control plane for backup for GKE
and includes Google Cloud Console UI elements
that interact with the API.
The agent runs in every cluster where backups or restores are
performed and performs backup and restore operations
by interacting with the backup for GKE API.
Let's demonstrate how you can enable backup for GKE
through the GCP console.
In the Google Cloud Console, navigate to Google Kubernetes
Engine and click "Backup."
If this is the first time you are creating a backup,
enable the backup for GKE API.
Click "Enable Backup" next to the cluster that
requires backup and restore.
Add required details to create plan for the backup.
Now you're all set for more resilient GKE workloads
on Google Cloud.
We hope you found this video helpful.
Check out the links in the description
to learn more about backups for GKE
and to try some hands-on labs.
Thanks for watching.