Kubernetes Data Protection In the Age of Namespace-as-a-Service
Kubernetes has revolutionized the way organizations deploy and manage containerized applications, providing a robust and scalable platform for container orchestration. However, “cluster sprawl”—the proliferation of Kubernetes clusters—has proven to be a challenge in many organizations, taxing the resources of DevOps, platform engineering and operations teams, and often wasting on-premises or cloud server resources via underutilization.
Historically, major IT infrastructure advances have often been about sharing resources to improve efficiency and reduce costs. Multiprocessing and multi-user operating systems, virtual memory, shared storage and virtual machines were all developed with this goal. In the past 10-20 years, much work has also gone toward delivering resources as-a-service to improve agility and efficiency. It should, therefore, come as no surprise to anyone that IT shops increasingly want to share their shiny new Kubernetes clusters among disparate groups of users and to do so using an easy-to-consume service model. The trend has been to do this by offering namespace-as-a-service (NaaS).
Kubernetes Namespace-as-a-Service
Namespaces in Kubernetes provide a mechanism for isolating groups of resources within a cluster, providing a way to logically divide cluster resources between multiple users or groups. When offering Kubernetes NaaS, you essentially create a multi-tenant environment from a single cluster where different teams or users, by requesting namespaces, can deploy their applications with some degree of isolation from each other.
Kubernetes on its own isn’t really designed for multi-tenancy, but by making use of the scoped naming provided by namespaces, and of access controls (RBAC) and resource quotas, a soft multi-tenancy solution can be created. Adding third-party security controls using admission webhooks to provide additional layers of security can provide more complete isolation, including for cluster-wide objects not scoped by namespaces. Several popular tools, such as Capsule, take this approach.
Other tools can be used to automate the creation of resources necessary to provide an easy-to-consume self-service model, including network policies, resource quotas, role and role bindings and security policies. This allows operations teams to automate the creation of new namespaces for users on demand. NaaS users can then concentrate on deploying their applications rather than on fiddling with cluster and network configuration and are prevented from making changes that may be destructive to the cluster or to the wider environment.
Data Protection for NaaS
So NaaS can lead to more efficient resource utilization and reduced effort for both developers and operations teams, and self-service NaaS has further efficiency advantages for everyone. But while providing NaaS to your users can be beneficial in many ways, it also brings about new challenges, particularly when it comes to data protection.
What’s been missing from the picture is a solution for providing necessary data protection in the form of self-service backup and restore to NaaS tenants. Back in the days when Kubernetes applications were all stateless, this may not have been much of a consideration, but those days are gone. Totally stateless applications are now more the exception than the rule, and proper data protection for stateful applications is critical.
Unfortunately, standard Kubernetes backup and restore solutions, including the popular open source tool Velero, do not work well in a NaaS environment. At least not on their own. Most backup solutions require (or worse, grant) admin access to the entire cluster, which is obviously not a good fit.
Backup and restore solutions for NaaS must be cognizant of namespace-based access controls and should ideally follow the same self-service model as NaaS itself. In some environments, operations and platform engineering teams may want to exert central control over backups, feeling that backup schedules, retention times, storage locations and immutability settings must be assured to meet policy, legal and regulatory requirements. In other environments, configuration of backups may be left to the discretion of the development or DevOps teams who own the applications on the assumption that they have the best understanding of how applications need to be protected. The backup solution you choose should have the flexibility to support both models.
In either case, self-service restore is almost always highly desirable. This allows development and DevOps teams to recover from software faults and failed deployments and to build development and test instances from backups, all without having to involve other teams. A simple and easy-to-use user interface is important here since users requesting a restore will often be in a rush and will typically not be storage or data protection experts. And, of course, the solution must prevent different NaaS consumers running on the same cluster from affecting each other, inadvertently or otherwise.
Conclusion
Offering namespaces-as-a-service can greatly improve efficiency and reduce management overhead in Kubernetes environments. However, it also introduces complexities in terms of backup and recovery. In many environments, a SaaS data protection solution is the ideal fit for protecting a NaaS offering. It should include namespace-based access controls, RBAC, an organization structure flexible enough to provide self-service and an easy-to-use user interface.
To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2023 – November 6-9, 2023.
