Kubernetes Multi-cluster and Multi-tenancy with Kasten K10 3.0

Kasten by Veeam has introduced multi-cluster support in K10 v3.0 that extends to multi-tenant environments. These capabilities have been introduced in direct response to tremendous customer demand and provide immense productivity advantages. This post takes a step back to explain why customers are using multiple clusters. The post then dives under the covers to explain the benefits provided with the novel approach Kasten K10 has taken to handle backup and disaster recovery in these growing Kubernetes multi-tenant and multi-cluster environments.

Kubernetes Multi-Cluster and Multi-Tenancy Deployments Increasingly Popular

Kubernetes provides the flexibility of cluster deployment architectures. Enterprise organizations are increasingly using multiple clusters. The State of Kubernetes, 2020 report by VMware highlighted that 20% of the organizations with Kubernetes in production already have fifty or more clusters. These clusters run workloads based on attributes such as specific applications, security domains, deployment readiness (e.g., test/dev/prod), organization (e.g., individual business units), geography (e.g., East vs. West coast), etc.  This multi-cluster approach provides many benefits including customizing clusters (e.g., node size) to fit the specific workload requirements, reducing the blast radius, etc.

With the growing usage of Kubernetes across enterprises, it is now a common requirement to support multiple tenants in the Kubernetes environments. IT/Cloud Ops teams need to ensure that there is a scalable and secure way to support not only various business units, departments, etc. but also enable self-service portals with granular access control to operate at DevOps speed. These self-service portals of course must allow you to see and act on the applications and resources based on your authorization and enable audit control.

At the same time, the need for contingency planning has never been more visible and is a common requirement across all the deployment and operational scenarios. Contingency planning in this context includes critical Data Management functions of Backup and DR of Kubernetes applications to recover from mistakes (e.g., application misconfiguration), infrastructure failure, and malicious attacks (e.g., ransomware).

Data Management Requirements for Multi-Cluster and Multi-Tenancy

However, multi-cluster environments bring new requirements to Data Management solutions. Done right, a Kubernetes-native data management solution can help ease the job of the IT/CloudOps teams to automate tasks like backup/recovery as well as ensure compliance at a global scale. The data management requirements for seamless operations in multi-cluster environments include:

• Security: There is an absolute need to ensure not just data security but also secure operations. It is an imperative to ensure that the right users and systems have the appropriate level of visibility and control into the Kubernetes applications and data management actions.
• Easy Setup: Allow for multi-cluster operations without complicated installations or overhead of installing daemon sets or overlay storage layers in all clusters. Setting up policies and resources spanning multiple clusters must also be extremely simple to set up and manage.
• Automated Discovery: Automatically discover Kubernetes applications, backup policies, and any changes across all clusters. Setting up policies and resources spanning multiple clusters must also be extremely simple to set up and manage.
• Global View: Enable Ops teams to use a single pane of glass (UI and API) to get a real-time and aggregated view into global status including compliance status for backup policies, consolidated alerts and resource usage reports, and application status.
• Global Policies and Resources: Allow teams to define global policies (e.g., how frequently an application needs to be backed up) and resources (e.g., target storage location) which could be applied to applications in any group of clusters.
• Flexible Cluster Grouping: Given the scale of multi-cluster deployments, a user should be able to easily define flexible and arbitrary logical grouping of clusters (e.g., clusters 1,2 are test clusters while Clusters 1,3 are in the east coast) for distribution of global policies and resources.
• Single Cluster Drill-Down: While the ability to operate at a multi-cluster level will be common, the need to easily navigate into an individual cluster to look under the hood or set up cluster-specific policies is equally important and should be a part of the workflow. 

Multi-Cluster and Multi-Tenant Backup and DR with Kasten K10 v3.0

With Kasten K10 enterprises now have the ability to scale their operations and handle an accelerating growth in Kubernetes applications across multiple clusters and tenants. These capabilities build on the security and operational simplicity pillars of K10 to bring about cloud-native scale for data and deployment portability and flexibility.

K10 addresses the requirements highlighted above in a very elegant manner with the following approach:

• API and User Interface Access: Multi-cluster capabilities can be accessed via both kubectl APIs or the K10 dashboard that enterprises already use and love.
• Seamless Install: K10 Multi-cluster support is not predicated on installing special software on the clusters. As long as K10 is running in the user-specified namespace with restricted access, a simple bootstrapping process can designate one cluster as primary and leverage the Kubernetes recommended practice of ingress end points to communicate with additional clusters (designated as secondary).
• Secure Multi-Tenancy: K10 leverages Kubernetes-native security constructs coupled with tight ecosystem integration for authentication and authorization to ensure a secure and flexible approach to RBAC. This approach ensures that fine-grained role-based access control (RBAC) so that the right users can exercise the appropriate action.

• • Multiple Authentication: K10 supports several authentication methods and rich vendor integrations including:
    • Token-based,
    • OpenID Connect (OIDC) - e.g., Okta, KeyCloak, GoogleAuth, etc.
    • Red Hat OpenShift OAuth Proxy,
    • Active Directory, etc.
    This provides a flexible approach that meets the secure authentication protocols used by the enterprise team.

• • Multiple Authorization Roles: K10 supports Role Based Access Control (RBAC) with the definition of multiple roles that can control the who and the what.
    • Roles can be dynamically associated with the appropriate users and applications.
    • Roles can define the allowed operations (e.g., view, backup, restore, etc.)

    With this approach, an admin role for instance could be given rights to set backup target locations while a user assigned to a basic role might have access only rights to trigger backup applications that are a part of his responsibility. K10 provides this dynamism in multi-tenant environments with fine grained visibility and control by tying into Kubernetes-native constructs like cluster roles and (cluster) role bindings

• • Multiple Encryption Keys: Additionally, K10 also supports secure end-to-end encryption with customer managed keys both while data is in rest and in motion.
    
    
•  Ability to Work with Dynamic Applications Without Developer Overhead: Without requiring any developer changes, K10 auto-discovers applications across clusters, adapts to changes, and dynamically maps policies to the current state of the application.
• A Global Perspective: When multiple clusters are present, the K10 Multi-cluster dashboard provides a simple way to get the aggregate and real-time status of critical parameters including the total number of clusters, policies, applications. You can even get the rolled-up count of applications that are non-compliant (since they are not covered by a protection policy).  
• Policies that Work Across Clusters:  K10 provides a powerful capability to define global policies on the primary cluster that can be selectively applied to secondary clusters. K10 manages backups at scale through automation leveraging these dynamic policies. This avoids the need for custom scripting and allows operations teams to easily create both broad and custom policies for data management compliance. This capability also allows you to define global profiles such as a pointer to an object store that can serve as a target store for snapshots.
  
  

• Define Your Own Cluster Groups: K10 introduces another powerful approach (termed distributions) to logically group clusters. These distributions allow you to create your own groupings and individual clusters can belong to many distributions. With this approach you can distribute global policies to whichever logical group of clusters you decide with the click of a button.
  
  

• Easy Shift to Individual Clusters:  K10 allows you to easily search for a specific cluster (e.g., by using names, labels) and then seamlessly switch into the individual cluster so that you can not only get additional views into cluster related resources but also define and operate on policies that are specific only to that cluster.
• Single-Sign On: Last but definitely not the least K10 makes the job of signing into individual clusters very easy. Users with the appropriate access can seamlessly switch into a specific cluster from the global multi-cluster console without repeating the sign-on process. 

You can watch a demo of the multi-cluster manager here.

Finally, remember that this capability is available across multiple Kubernetes distributions – both on-premises and on public clouds giving you complete freedom of choice!