Cloud native development is gaining traction as the optimal approach to designing and operating workloads built for the cloud – and many agree that cloud native architecture and technologies are the only way to take full advantage of all the cloud has to offer. IDC predicts 500 million new cloud native apps will be developed and deployed by 2023, and Gartner reports that 75% of enterprises are running containerized apps. And, according to ESG, 52% of IT organizations are on the hunt for dedicated backup tools, to help protect their cloud native data and applications.
But it’s not just backup tools organizations need to support cloud native initiatives; tools that address the wider scope of data management such as disaster recovery and application mobility are also essential. With the massive influx of hybrid cloud environments running container orchestration platforms such as Kubernetes both on-premises and in the cloud, organizations must be able to protect cloud native data and applications while maintaining the freedom of choice to run workloads where it makes the most sense for their business.
The introduction of stateful applications in Kubernetes is also an important trend. How do organizations safely and securely run databases in a cloud native environment to capitalize on its scalability, while still providing the service reliability users demand?
In a recent webinar, Kasten by Veeam’s Senior Technologist of Product Strategy Michael Cade explored five best practices for protecting data in Kubernetes. Let’s examine each of those best practices, and how a cloud native backup solution enables developers to safely and reliably backup, recover and move containerized applications and their data across Kubernetes clusters.
- Architecture: Kubernetes is application-centric. Therefore any Kubernetes backup solution must perform complete application capture, and be able to abstract the underlying infrastructure. Containerized applications consist of multiple microservices and artifacts, all of which must be captured in a consistent manner, to protect all of the data and the application as a whole, and to be able to recover and restore it quickly.
To that end, your backup and recovery solution should be natively deployed inside of your Kubernetes environment, and be agnostic to the virtual or physical infrastructure. Whether you have integrations into VMware, public cloud offerings such as Google or Amazon EKS, or OpenShift, if the backup solution is deployed in its own namespace in your cluster using a native Kubernetes API, then it can hook into that infrastructure, discover applications and the underlying components, and perform lifecycle operations.
There are other considerations as well, including the ability to backup applications into object storage and handling stateful workloads, since about 50% of Kubernetes clusters run stateful workloads today. Your solution should be able to integrate with infrastructure-specific APIs for block storage providers and S3-compatible object storage, as well as other file storage such as NFS for artifacts. Some solutions offer optional agentless application-centric hooks that can be invoked using easy-to-use blueprints.
- Recoverability: Believe it or not, in addition to outages, accidental deletion is one of the biggest problems developers contend with when it comes to Kubernetes and data management. Misconfigurations also happen – and those can be replicated if you’re relying solely on replication for backup. That’s why your Kubernetes backup solution must be able to back up and restore your data and applications to a known, good state. Moreover, it should be able to reproduce environment states to simplify compliance in case of an audit. To meet these requirements, multi-tenancy capabilities, RBAC, and polyglot persistence are key features to look for.
In disaster recovery scenarios, your solution should be able to restore all of the application components with a high degree of granularity. It should also provide policy-driven automation to simplify the process of managing backups and securely replicating them to off-site storage, and provide near-zero RTO for Kubernetes workloads.
- Operations: Day 2 operations are greatly simplified with policy-driven data management. To meet your SLAs, your backup and recovery solution should enable you to set up customer and default policies that provide automated enforcement. Observability is also critical, and can be achieved with an intuitive UI and a feature-rich dashboard that provides useful metrics and automated alerts. That way, you know the protection status of all your Kubernetes applications at all times, and it’s easier to determine if any corrective action is necessary. Make sure your solution can scale to accommodate the addition of application components, as well.
- Security: Containers are vulnerable from a security standpoint for numerous reasons. It’s very easy to create a container that has “godmode,” and that makes the whole deployment vulnerable to anyone who gains access to it. Overpermissioning during install and operations leads to a lack of privilege separation, and frequent releases of Kubernetes itself, as well as third-party tools, make it difficult to keep up to date while struggling with ongoing operations. Sophisticated attacks exploit gaps in backup and recovery processes, putting data and applications at risk.
It’s important to leverage robust authentication such as OIDC and tokens, as well as end-to-end encryption, both at-rest and in-motion, so that data is always secured with customer-managed keys. If you're operating in a multi-tenant environment, self-service portals that provide visibility and control into your applications – and only your applications – are essential. Adopt a least-privilege approach to common tasks such as monitoring by implementing RBAC, and when backing up containers, use a backup solution that provides immutability – that is, the ability to send backups into immutable storage such as S3-based object storage, using an object lock API.
- Portability. Application portability provides freedom of choice, resiliency and scale, and can be used for various use cases, including restore, migration and more. To that end, your Kubernetes backup solution should enable cross-cloud portability and migration, and make it easy to move applications between private and public Kubernetes deployments, or between clusters within a deployment. The ability to move applications between clusters or clouds – or clone and restore an application – without worrying about the underpinning storage provides maximum flexibility when determining where to run your workloads and assists in restore operations, as well.
Kasten K10 enables Kubernetes developers to apply all five of these best practices, with a cloud native backup, recovery and mobility solution that’s purpose-built for Kubernetes. Watch the full webinar to learn more, or try Kasten for free today.
