New capabilities: Capsule multi-tenancy v0.1.0 for native Kubernetes environments!

By Dario Tranchitella, 20 Sep 2021.

The Cloud-Native methodology has been widely adopted, with Kubernetes, acting as the framework for achieving it. Start-ups and mid-size companies began using it mostly to achieve horizontal scaling to serve traffic spikes. Now, the enterprise world has crossed the adoption chasm, selecting Kubernetes as the de-facto standard for the Cloud. That is good news!

Unfortunately, the rapid and effortless adoption of Kubernetes, with its “one tenant one cluster” architecture, has resulted in many cases with cluster sprawl problems, where large amounts of clusters get deployed as each organization needs their own tenant. This sprawl then causes significant operational challenges as well as poor infrastructure utilization, driving up costs.

Capsule was designed to solve this challenge, providing the framework for achieving a light multi-tenancy scenario where customers can have a secure “many tenants to one cluster” architecture in native Kubernetes environment. The result is a win for users that can have tenants available just as easily as they did without multi-tenancy, and it's a win for IT managers that end up with far fewer clusters to manage that are better utilized, which significantly reduce costs.

Impressively, production users of Clastix’ capsule multi-tenancy operator, have been able to architect native Kubernetes environments requiring over 80% fewer clusters!

A more evolved Capsule

Customer feedback has helped us incorporate powerful new capabilities in this major release. The new Capsule v0.1.0 release brings many hotly requested new features that allow flexible design when implementing a tailored-made scenario. Let’s focus on the highlights:

Support for Kubernetes 1.22

The latest Kubernetes release provided several API version deprecations and Capsule can automatically detect the running version, leveraging the available APIs without the need for external configuration.

Monitoring

When adopting the CALMS pillars, measurement is essential, and one of the direct implementations is monitoring. A Grafana dashboard has been provided to help the cluster administrators monitor and detect failures: this enables the median time requested to reconcile a Tenant resource to be used as a Service Level Indicator, or the inner Kubernetes API REST HTTP client request latency may be used to identify bottlenecks and take immediate action.

Performance enhancement

Handling a Tenant with hundreds of Namespace resources can be time-consuming, potentially creating a lag in the reconciliation process. Taking advantage of the Go’s goroutines that are low-memory consuming, Capsule can easily manage extreme scenarios, with efficient resource consumption.

CVE-2021-25740, or security

In July, a new CVE was announced. Without a patch in the Kubernetes upstream code: if you’re providing a platform, you’re responsible for acting and securing your users, and relying on third party components could be perilous. Capsule allows you to build a Platform for your needs and putting in place policies to allow or disallow the usage of certain types of Service resources, such as ExternalName, ClusterIP, NodePort, or LoadBalancer.

Ingress hostname collision

Managing a public platform is challenging due to segregation requirements, especially when dealing with exposed services. Not publishing the same Ingress hostname is crucial to avoiding collision situations, and Capsule helps here as well, by checking the collision of Ingress and related paths at multiple levels (Namespace, Tenant, or Cluster).

ResourceQuota are now configurable at the Namespace level

Capsule is providing the Tenant abstraction, a collection of Namespace resources where a ResourceQuota is applied: this feature overcomes the limitations of the ResourceQuota resource which doesn’t provide a Namespace selector since it’s a Namespaced scope nature. However, in certain scenarios, you need to define the quotas for each Namespace of your Tenant, avoiding sharing the limits: if this is the case, the Capsule v0.1.0 release is what you’re looking for!

Configuring Capsule options using a CRD

Most programs allow specifying options using CLI flags or reading environment variables, or even a configuration file backed by a ConfigMap, in Kubernetes. Using the CapsuleConfiguration custom resource definition, your multi-tenant Operator can change its behavior at runtime, without the need to restarting the controller!

Pod PriorityClass support

The new v1beta1 Tenant version allows specifying which Pod PriorityClasses a Tenant is allowed to use, using an exact match or a regex one. The pod PriorityClass is absolutely a must-have to specify the priority of Pods to ensure reliable cluster critical components, or just to provide QoS options to your customers, or teams, via Capsule.

Tenant cordoning

Switching a filesystem to read-only mode is a piece of cake, not so with Kubernetes: you may need to freeze all operations due to maintenance, such as backup or restoration. With the latest Clastix version, you’ll be able to freeze an entire Tenant according to your business needs.

Allowed Pod’s ImagePullPolicy values

According to the Kubernetes multi-tenancy working group, in a shared scenario, all the Pods should be running with an `Always` image pull policy to ensure the ServiceAccount is allowed to use a private image. Capsule allows Tenant level specificity, determining which policies are supported and, we include full examples of the supported benchmarks.

Tenant events, and violations

Visibility plays a key role in managing production-grade software, and Events provided by Kubernetes can be a good place to understand what’s going on in your cluster, or even better, in your Tenant. Describing your Tenant, you’ll be able to get a full picture of the reconciliation results, even of the violations of the policy enforced.

ARM container image

Kubernetes is now on ARM, as well, which Capsule supports, allowing the management of a fleet of Tenants on the edge!

Multiple tenant owners and a new kind

Capsule recognizes Tenant owners such as Users or a user belonging to a specific Group. However, in Kubernetes also the Service Accounts are considered users, although mostly reference such as robot accounts, supported from the Tenant v1beta1 API version. And the best is yet to come, allowing you to now specify multiple owners of the same Tenant, bringing a powerful and unopinionated management design!

We want to thank our user and contributor community for helping to shape this v0.1.0 release!

Many key features have been added, the code has been made more robust, several bugs have been addressed, with the end result being enhanced reliability and performance. This wouldn’t have been possible without the community’s rapidly growing support and feedback. Now with more than 500 stargazers on GitHub and an ever-increasing list of new contributors, we warmly welcome your questions, suggestions, feature requests, and best of all, bug reports, which help us make Capsule even more battle-proof.

The next release is already planned and gathering feature requests from both the community and Clastix customers that already have Clastix in production: check out the upcoming milestones and don’t be shy to ask for a feature, we’re here to help you solve the multi-tenancy dilemma!

Credits to Steven Corman for the social sharing image.