Kubernetes: Test Cluster Suddenly Runs a Multi-Tenant Production Environment

It’s more common than you might think. A Kubernetes cluster is set up on-premises to support development and testing activities. So far so good, everything works well. Until word gets around that it works too well, and more users start using it. All of a sudden this small development deployment runs a production workload and when it goes down, so goes the happiness of your users.

Local flash is typically recommended for Kubernetes clusters for high performance. The challenge with this deployment method is that workloads are confined to their specific server and cannot move around the platform. One of the greatest benefits of Kubernetes is lost–portability. But it runs well because you’re using flash as local storage, so it is plenty quick. No immediate issue right?

Running early production workloads on local storage has its drawbacks. The immediate one is that workloads can’t move around other servers across the platform. The other drawback is that it typically results in overprovisioning and stranded capacity. What’s really needed is persistent storage that can run containerized workloads, but also virtualized workloads. And this can be done by using  Kubevirt, an open-source solution that makes it possible to run virtual machines as pods and to coexist with the K8s cluster. Shared storage can solve these challenges. However, you would want to choose a solution that doesn’t make you compromise on high performance or low latency, nor do you want to make any changes to your existing network.

Kubernetes Container Storage Interface (CSI) defines a standard interface to expose storage systems to containers. Lightbits offers the ability to run your workloads on persistent volumes, using the Kubernetes CSI driver. Lightbits Intelligent Flash Management allows you to improve performance, maintain consistently low latency, and increase efficiency by pooling all your NVMe together into a centralized Lightbits data platform using standardized server hardware and networking. At the same time, Lightbits improves utilization, by pooling NVMe and sharing them across all worker nodes. This allows otherwise stranded capacity to be utilized to the fullest and at the same time allows NVMe flash to achieve its potential, a performance that a single worker node would not be able to achieve. At the same time, Lightbits clustering will add significantly improved resiliency and availability.

Cloud-native technologies form the basis for Lightbits, allowing Kubernetes administrators to mount Lightbits NVMe-over-TCP (NVMe/TCP) volumes across various environments. Whether you’re running Kubernetes on-premise, in the public cloud, or at the edge.

Running Lightbits and Kubernetes as a Service

If you are a Cloud Service Provider, you can offer your customers fast, secure, and reliable services that are also flexible and offer the ability to self-service using Lightbits with Kubernetes. Doing so would give your customers the flexibility to deploy various workloads on containers and perhaps virtual machines using Kubevirt. You can also define storage classes, based on existing storage or perhaps define different storage tiers on Lightbits utilizing our QoS functionality that can limit IOPS or Bandwidth on each volume and allow your customers to deploy the required volumes themselves. Data services, such as compression and thin provisioning ensure customers who deploy large volumes but don’t actually use them,  do not end up being just unused reserved space on your storage. Other data services such as compression, will make your storage platform even more efficient.

Secure Multi-Tenancy

Another requirement for Cloud Service Providers is to be able to separate their customers’ workloads. Especially for customers running sensitive workloads, it often comes as a requirement. In this case, the platform should offer strict authentication. Every action in the system, both on behalf of tenants and admins, must be carried out only after the entity requesting it has been successfully authenticated. The entity will have a predefined role and security setting. After the entity is authenticated, access permissions are applied based on those security settings and it will then be authorized by the system to carry out specific actions. Note that I’m talking about entities, because credentials could be used to authenticate a person, but also machines or (part of) applications. If we take a Kubernetes deployment as an example; tenants could be granted the rights to create and attach/detach new volumes and deploy new containers without the intervention of an admin to do so for them.

Role Based Access Control (RBAC) is what makes the administration of the different privileges inside a system easier. RBAC allows collecting one or more individual privileges into a “role”, and then assigning this role to as many entities as necessary. These roles could be based on administrator or tenant-specific roles, such as a superuser.

All operations should be logged to enable audits and analysis later. This will enable detection and a historic record of events for investigations in case of security incidents and audits. The logs could also be used to further improve security. It will also be beneficial when performing root-cause analysis in case of failures or malicious intent.

Lightbits has developed secure multi-tenancy definitions into the solution, which works especially well in a Kubernetes context. This functionality sees continued development and improvements, as our customers actively use and depend on these features. We would be glad to have a conversation about it with you, and explain how we have implemented it. In addition, our customers are also happy to talk about their experiences with Lightbits.

Running Containers on the public cloud

Running Containers on the public cloud is easy and Lightbits can now deliver predictable high performance and low latency equivalent or better to running on-prem in a cost-efficient package. While you sometimes have a choice of running your own dedicated container environment or consuming from public cloud providers that run large managed container platforms, typical cloud deployments still utilize a lot of direct attached storage in the local hypervisor or bare metal. (DAS) The native persistent storage offerings that are available on the cloud, can’t match the speed of DAS and will increase your costs enormously when running at high speed and large capacity. At the same time, enterprise data services are unavailable or far too expensive and difficult to manage with the native storage solutions in the cloud (eg. thin-provisioning, compression, snapshots, clones, etc). Lightbits can support your containerized workloads on the public cloud while offering high performance and consistent low latency equivalent to local flash while also delivering unmatched simplicity and cost efficiency.

Lightbits now available for the public cloud!

Lightbits is available to deploy from the AWS Marketplace and in Microsoft Azure. This will allow you to have dedicated, very high-performant, NVMe-backed block storage for all your workloads in the cloud. Especially suited to run persistent containerized workloads at up to half the cost of its public cloud block alternatives. Offering enterprise-grade features and functionality using a consumption-based or yearly subscription model.

Additional resources:

About the Writer: