Kasten sponsored this post.
Organizations continue to make the shift to Kubernetes environments, but challenges involving stateful data backup remain.
According to a 2019 survey conducted by the Cloud Native Computing Foundation (CNCF), 78% of the respondents said they were using Kubernetes in some form, and 95% report they are using, evaluating or planning storage use in Kubernetes.
However, what is left unsaid in these statistics is how deploying applications on Kubernetes without the appropriate data backup and management systems creates a number of risks for data breaches, loss or corruption.
This assertion may contradict some widely held beliefs about the Kubernetes platform — many assume that the ability to run replication data services across failure domains is good enough data protection. But replication isn’t data backup or storage.
While replication enables highly reliable applications, it doesn’t protect against data loss and corruption. For example, errors that delete data can get replicated just as easily — and that can cause a data disaster.
Native Backup Is Your Best Bet — Here’s Why
Although you may be tempted to leverage legacy backup tools such as those used for virtual machines, there are several important reasons why that isn’t a good idea in containerized Kubernetes environments.
In fact, backing up Kubernetes applications using traditional backup solutions can actually increase your risk of data loss, due to the nature of containers and the combination of stateful and stateless components within them. The data and the state need to be preserved to recover an application, and while stateful components maintain the data and state in persistent storage volumes, stateless components do not. Recovering an application without backing up stateless components in a separate location will result in failed restores, misconfiguration and lost data.
A Kubernetes-native backup solution can help lower risk and enable faster recovery time, while providing other key benefits that help your team execute backups more efficiently. Let’s examine why a Kubernetes-native backup solution is the best choice for protecting your expanding Kubernetes environment:
- It accommodates Kubernetes deployment patterns. In containerized applications, there’s no mapping to any servers or virtual machines. Application components are distributed across all servers to improve fault tolerance and performance. As such, traditional backup solutions are unable to capture the state of a specific application without collecting data from others, and as such, misconfigurations can result. While traditional solutions are appliance-centric and designed for backing up VMs, a Kubernetes-native solution can adapt to the dynamic aspects of containerized applications, performing load-balancing to accommodate the changing needs and contents of the container, discovering changes in real-time and capturing all application context.
- It aligns with “Shift-left” development: Kubernetes is all about rapid development cycles. Its unique design necessitates application-centric backup solutions and alignment with DevOps’ “shift-left” philosophy. In the shift-left approach, developers are the ones who define the application and infrastructure components as code and dynamically provision those programmatic requests. Although shift-left is a cornerstone of an agile development environment, it can introduce risk of data loss resulting from a misconfiguration. Backing up and protecting Kubernetes requires discovering new and changing applications automatically, without developers needing to make any changes to their applications or packaging. The solution should also be API-driven, to remove any barriers to adoption.
- It simplifies operations: The skills gap is real. Many developers are coming to Kubernetes having worked only in Linux or vSphere environments, so it’s important that the backup tool offers CLI access and an easy-to-use dashboard. This will help bridge the gap and hide underlying complexity to simplify backup workflows. In this way, operators don’t have to understand how to protect millions of components in a cluster or perform a miscellany of manual tasks to update applications with restored volumes.
- It accommodates multicluster scalability. Handling the millions of discrete components in a Kubernetes cluster requires a solution that can capture and understand the relationships between the applications, data and Kubernetes state — at scale. It must be able to dynamically accommodate application and cluster changes and scale down to zero when not in use — all with minimal operator involvement. The requirement is compounded by the increasing use of Kubernetes multicluster configurations, which are often distributed across environments, team and application boundaries, regions, clouds and on-premise data centers. A solution that accommodates multicluster scalability will eliminate significant operational burden, saving teams time and money.
- It closes protection gaps: Kubernetes is architected for fault tolerance — but replication isn’t a backup. Replications can suffer from data corruption and deletions — even in the cloud. Think of on-premises storage snapshots — they’re often not resistant to hardware failure, and if you delete one, related snapshots may also be lost. What’s more, quiescing file systems for backups may require elevated security privileges. A native solution can prepare the data for backup without sacrificing security, and work transparently across a wide range of application stacks and deployment methods, without adding complexity to the operator’s workflow.
- It bolsters security: Traditional backup solutions cannot discover, let alone access or quiesce applications without weakening isolation policies within the cluster. By contrast, a Kubernetes-native solution can embed itself into the control plane and circumvent those limitations. Role-based access control (RBAC) is a critical requirement, and should align with the roles defined within Kubernetes to support self-service capabilities and minimize the need for developers to learn additional role management systems.
A native backup system will understand Kubernetes certificate management and storage-integrated Key Management Systems (KMSs), and support Customer-Managed Encryption Keys (CMEKs) through the Kubernetes Secrets interface, to avoid transferring application data in plain text. It can perform independent backups to protect against malware and ransomware, and will likely have deep platform integrations to enable rapid, automated restores.
- Integration with the cloud native ecosystem. The development ecosystem has expanded to include multiple data services (e.g., MongoDB, MySQL, and Cassandra), and often these are used within the same application. A Kubernetes-native backup solution can capture a consistent copy of the entire application stack, both within and across services. It can also identify and gather data from replicas, reducing the impact on the application, and improving performance and efficiency. As more and more organizations run Kubernetes clusters across different environments, the ability to integrate backup with the cloud native tools that developers and operators are accustomed to — such as Prometheus or Kubernetes APIs for logging and root-cause analysis — will be critical.
Stop Data Loss with a Native Backup Plan
While regular backups are standard procedure for development teams, the increasing adoption of Kubernetes calls for revisiting traditional backup methods to ensure data protection and security, as well as the reliability and availability of enterprise applications.
But Kubernetes isn’t like other development environments — it has unique characteristics that necessitate a new approach to backing up critical application data and storage. Traditional appliance-based approaches simply don’t cut it, and relying on replication services is a risky approach. A Kubernetes-native backup solution is the only way to ensure secure, reliable data backup, without disrupting developers’ workflows or adding complexity that could inhibit innovation.
Feature image via Pixabay.