Home etc Blogs Google Cloud Announces Backup for Google Kubernetes Engine

Google Cloud Announces Backup for Google Kubernetes Engine

0
719

Google has recently announced the preview of Backup for GKE, a cloud-native way to protect, manage, and restore containerised applications and data running on Kubernetes.

Using the new service developers can create backups plans to schedule periodic backups of both application data and GKE cluster state data, restore each backup to a cluster in the same or in a different region. It also allows to customise backups to ensure application consistency for the most demanding, tier-one database workloads.

Organisations everywhere have been choosing to build on Google Kubernetes Engine (GKE), driven by benefits like higher developer productivity and lower infrastructure costs. And one of the fastest growing GKE architectures is the deployment of stateful workloads like relational databases, inside GKE containers.

“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,” said Jose Chavez, SaaS Platform and Delivery Engineer at Broadcom. “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.”

Chris Schilling and Manu Batra, product managers at Google Cloud, explain how the backup for GKE works.

“Prior to Backup for GKE, many GKE customers backed up their stateful application data separately from GKE cluster state data. Application data could be protected via a storage-based backup, while cluster state data might be captured occasionally using custom scripts and stored in a separate customer bucket. Customers with ongoing backup requirements relied on homegrown solutions to perform regular backups and to demonstrate compliance. In the event of a restore, customers had to perform more complex orchestration. Storage management tasks, like creating a clone for testing purposes, or migrating data from one cluster to another, meant additional operational overhead.”

 

 

NO COMMENTS

LEAVE A REPLY

Please enter your comment!
Please enter your name here