Kubernetes is the key technology that allows running containers on any platform and in multiple scenarios, some of which are very interesting, and extraordinary, like the U.S. Air Force deploying Kubernetes on an F16.

Worldwide the Kubernetes adoption has crossed the chasm, being used by enterprise companies, and as well as by federal governments: alongside the CIS/NSA guidelines in hardening a Kubernetes cluster, there are multiple case studies and success stories for those agencies, and organizations.

One of the most intriguing projects we have ever worked on at CLASTIX was related to Kubernetes, obviously, and simulations: you couldn’t trust how multi-tenancy played a big role there.

The scenario

While nobody likes war, recent events in Europe and rising tensions in Asia have reminded us of the importance of being prepared for defence. Fortunately, we now have the means and technology to simulate the most complex scenarios, which are referred to as "dry-runs" in technical slang

Modern events in Europe and rising tensions in Asia have awakened many with a brutal reality check; preparing for any eventuality has become a priority for many defence ministries.

Simulations are occurring in a virtualized environment, where these scenarios are configured, as it could be the following: you’re in charge of engaging potential missiles, and some of them just showed up on your radar; you have to react, and you have to respond promptly to failures, or unknown side-effects (and yes, chaos-engineering applies even here).

Applying multi-tenancy

As with any regular application, also simulations need to get high throughput, and be able to run in a shared environment: what if you’d like to test the interaction between multiple actors in the scenario? 

What’s the relationship between these concepts and multi-tenancy? Applying the Capsule jargon we can understand it better.

A Tenant is a collection of Namespace resources to which rules and enforcements are applied. With that said, a Scenario is essentially a tenant and each Operator, human, or robot-based, can join by creating a Namespace.

In each Namespace, a set of custom resources can be deployed: these could be launchers, aircraft, interceptors, radars, or any other resource that binds to the simulation domain.

Once a simulation is completed, the offboarding process is straightforward. Upon the Tenant deletion, all the underlying Namespaces (aka the actors involved in the simulation) are automatically deleted, without the need for complex scripts with the risk of getting dangled resources.

Using a shared infrastructure

A simple question could arise, like why run on a shared infrastructure rather than a dedicated one? The reasons are many, although we want to focus on the key objective ones:

• Disposability of the scenarios

• Quick provisioning of these

• Dataset reinforcement for the trained artificial intelligence models

One of the features offered by Capsule is allowing the data sharing of Persistent Volumes at the Tenant level, allowing the developers to know which volumes can be used, or reused, for their applications. 

Furthermore, using a shared infrastructure drastically decreased the provisioning time of the whole architecture, allowing the prototype of new defensive strategies, and allowing end-users (aka human operators) to onboard fastly on new scenarios.

The internals with Capsule

As we had the chance to describe, each simulated scenario was a Tenant, and each actor involved a Namespace where the human operator was able to deploy a set of resources: these were mostly applications being able to communicate using proprietary protocols.

Upon a scenario start-up, a set of required resources were mandatory, such as the barebone of the whole simulation: this provisioning has been offloaded to Capsule too, thanks to its API named GlobalTenantResource that allows replicating arbitrary (or already existing) resources in specific tenants, and namespaces, thanks to the label selection offered by Kubernetes itself.

Once a simulation is completed, the offboarding process is pretty straightforward: upon the Tenant deletion, all the underlying Namespaces (aka the actors involved in the simulation) are automatically deleted, without the need for complex scripts with the risk of getting dangled resources.

The outcome

The organization that worked with CLASTIX in making up this solution has been impressed by the features that Multi-Tenancy, combined with Kubernetes, can provide.

Thanks to the multi-tenant toolkit that Capsule offers, the customer has been able to decrease by ~90% the creation of scenarios and be able to perform parallel over serial simulations in the same time window, without creating a bottleneck in their infrastructure.

Managing Open Source software in critical environments could be challenging, that’s the reason why CLASTIX, the commercial company behind Capsule, is offering their services to Federal Agencies and Governments by benchmarking the security of any Kubernetes cluster (on-prem, or cloud) and offering 24/7 support and solutions architecture services to serve any kind of requirement.

In conclusion, we were enlightened to see Kubernetes shining in the defence sector, and proud to play a big role in this critical sector. The future of war simulations is bright, and we look forward to what Capsule and Kubernetes can achieve in the future.