Kubernetes is well known for its complexity, and properly protecting Kubernetes can be as complex as managing it. Backing it up is more complicated than backing up your other systems because of the multiple layers involved. The underlying worker nodes are often ephemeral, or at least expendable. But the configuration of Kubernetes itself, the Kubernetes resources which are typically stored in etcd, and the data stored in persistent volumes all need to be protected. If you are using managed cloud-based Kubernetes services such as EKS, AKS, or GKE, the configuration for them is stored in your cloud provider, and that should be preserved as well.

There are key factors to consider when deciding what parts of your Kubernetes infrastructure need to be protected, deciding what sort of protection they need, and choosing a protection solution. When evaluating Kubernetes backup solutions, remember that backups can be used for much more than just simple in-place recovery scenarios. While in-place recovery may be the most important use to which you will put your backups, it is likely that you will use them more frequently for other purposes. It is important to keep these other use cases in mind when choosing a backup solution and deciding which of your clusters to protect and how to protect them.

Disaster Recovery

First, consider your DR requirements. What would you need to do to recover in the event of a disaster? This could be the loss of an office or company datacenter, or it could be loss of access to a cloud provider account, region, or availability zone. Keep in mind that the need for DR may be triggered by events other than actual disasters. Cyber-attacks, outages, and even billing or legal disputes with service providers may call for activation of a DR plan. If you have lost an office or datacenter, you may want to restore to the cloud. If you have lost access to a cloud provider account, availability zone, or region, you may want to restore to a different account or region, or even a different cloud provider. In most of these use cases, the underlying infrastructure you are restoring to will be different from that which you backed up from. And any backups or snapshots stored locally may be destroyed or inaccessible.

Archive for Compliance and Legal

Next, consider your compliance and legal requirements. Developers and DevOps teams may be unfamiliar with the requirements imposed on them and their data by various laws and regulations. Unlike corporate IT operations teams, they may not yet have experienced the legal discovery process and various compliance audits. But like taxes, they are out there waiting for the initiated and unsuspecting alike. In today's increasingly litigious environment, even teams that are not in highly regulated industries like finance and health care are likely to have requirements imposed on them by their company legal departments. Backups may need to be taken at certain intervals and retained for certain periods. In these use cases, they also must not be retained beyond certain periods. In other uses cases, they may need to be unalterable. Consistent adherence and proof of adherence to policies is important. So is the security of the backups, and in many countries, the location of the backups, due to privacy and data sovereignty requirements. And of course, most important of all is the ability to reliably restore the state of your application on a specific day or time when needed.

Migration and Cloud Mobility

Another important use for Kubernetes backup solutions is migration. A good solution can make it easy to move a whole cluster or a single application or namespace from one location to another. This may be to a new cluster, a new cloud account, a new region, or a new cloud provider. This is not always straightforward since configuration data such as storage classes may need to be remapped from one cluster or type of cluster to another. Look for a solution that automates this as much as possible.

Dev/Test/Staging

Finally, a backup solution can be useful for replicating production Kubernetes environments for development and test. The requirements for this are like those for migration, but with important additions. First, it can be useful to trigger both backup and restore jobs either on a schedule or programmatically via an API or CLI. This can allow for scripted deployments, or deployments automatically triggered in your CI/CD pipelines. Second, you will often want to use different configurations for your dev/test cluster than you do for staging and production. If your solution can auto-create clusters for you in the cloud, it should also allow size and scaling-related parameters to be changed on restore. Third, you should make sure your solution provides a way to cleanly overwrite your dev/test environment with production data when restoring to an existing cluster.

Try Before You Buy

Think carefully about the ways in which you may want to use your Kubernetes backups before choosing a backup solution. A solution that may seem fine for simple restores may turn out to not be what you really need for more advance use cases. If in doubt, be sure to talk to the solution vendors and do proof-of-concept (POC) tests to try solutions out for yourself. SaaS solutions can make a great starting point for POCs, since there is no software to install or infrastructure to set up. At CloudCasa by Catalogic, we are always happy to talk to users and share our insights and experience, even if it is just to help crystallize their requirements!

##

To hear more about cloud native topics, join the Cloud Native Computing Foundation and the cloud native community at KubeCon + CloudNativeCon North America 2022 in Detroit (and virtual) from October 24-28. 

ABOUT THE AUTHOR

Bob Adair, Product Manager, CloudCasa by Catalogic

Bob Adair is the product manager for CloudCasa at Catalogic Software. Bob has 30 years of experience in the IT, storage, and data protection industries. Since beginning his career in IT on Wall Street, he has held senior positions in engineering and product development at companies including Storage Networks, Veritas, Symantec, Savvis, EMC, and Dell.