Disaster Recovery in GKE

Key Takeaways

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 the kriti 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 anytime 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 nine thousand dollars a minute that's 13 million dollars 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 SAS 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 CMAC 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 subscope 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