Mirantis OpenStack for Kubernetes 22.1 enables you to seamlessly maintain an up-to-date security posture for your infrastructure

This week we released Mirantis OpenStack for Kubernetes 22.1, which delivers solutions to solve our customers’ challenges of:

• Complying with local and national regulations such as GDPR and HIPAA, as well as protecting user data in their private clouds
• Seamlessly maintaining the security posture of their infrastructure and upgrading in a non-impactful manner
• Achieving the maximum performance with a heterogeneous hardware environment
• Expanding the set of customers they can serve in multi-tenant scenarios

Object storage encryption

Many applications deal with security-sensitive information such as personal data, and they need to comply with multiple local or national regulations, such as GDPR or HIPAA. So it is not uncommon for cloud users to feel concerned about the safety of the pieces of data their application stores in the cloud. In 22.1 we’ve rounded out the building blocks of encryption capabilities needed to help protect our customers' data by adding support to the Ceph RADOS gateway, the backend for Mirantis OpenStack for Kubernetes object storage, to enable encryption for objects uploaded to the S3-compatible API.

Mirantis OpenStack for Kubernetes already provides a wide range of tenant data encryption capabilities to satisfy these requirements, including the ability to encrypt ephemeral data, block storage, and network traffic. Object storage encryption was the last remaining piece of the puzzle, and now, with version 22.1, we’ve added support for that as well. Ceph RADOS gateway implements a subset of the Amazon SSE-KMS specification, which allows cloud users to enable encryption for objects uploaded to the S3-compatible API that MOSK exposes. A cloud user creates a secret key in the Mirantis OpenStack for Kubernetes Secret Manager service (OpenStack Barbican) and then associates it with an S3 bucket. The object storage service, having access to the key, performs on-the-fly encryption and decryption of the objects written to and read from the bucket, allowing the assurance of safety for data stored at rest in the cloud.

The examples of use cases already leveraging Mirantis OpenStack for Kubernetes data encryption capabilities include:

• An American software company is delivering a Cloud Security Platform SaaS, providing real-time protection and audit for any cloud-based application anywhere.
• A Global 50 manufacturer is building a general-purpose IaaS that complies with very strict internal security policies.
• A European software company is deploying an HR SaaS application, with their software processing millions of employee records for many of the world’s most famous companies.

Host CPU passthrough by default

In this release we provide a means for enhanced performance of the guest OS across a variety of deployed hardware configurations--enabling customers to gain the most efficiency out of a heterogeneous hardware environment. Originally, Mirantis OpenStack for Kubernetes would abstract virtualized workloads from the physical CPU. The idea was to guarantee that OpenStack instances could safely undergo a live migration across the cloud at any time in order to avoid impacting applications during cloud maintenance or troubleshooting. This was achieved by exposing only basic sets of CPU instructions to the guest OS, resulting in the high portability of the workloads between different hardware. Naturally, the downsides were certain performance overhead and incompatibility with some modern OSes, such as the latest Windows Server.

As more customers leveraged Mirantis OpenStack for Kubernetes in their infrastructure, we learned that many of them actually prefer performance over workload resiliency. Ready and willing to take the risks, they did post-deployment tweaking of their Mirantis OpenStack for Kubernetes clouds to enable workloads to use the whole instruction sets their host CPUs offered. Taking into account these learnings and the fact that the majority of cloud operators tend to buy hardware in bulk quantities, resulting in relatively homogeneous hardware configuration, we decided to make the Mirantis OpenStack for Kubernetes reference architecture less stringent in terms of virtual CPU configuration.

Starting from release 22.1, every new instance within will automatically select the virtual CPU model closest to the physical hardware. This allows a good balance between the performance of the guest OS and the ability to safely tolerate minor deviations in the physical CPU specification when migrating between hosts. Going one step further, a future release of Mirantis OpenStack for Kubernetes will allow cloud users to decide for themselves which virtual CPU model to use for each instance.

Today, multiple customers are taking advantage of the host CPU model pass-through feature to maximize the performance of their systems, while others are leveraging this feature to deploy Windows Server as one of their core workloads.

VXLAN encapsulation in Tungsten Fabric

We have expanded the options available to our service provider customers providing hosted services for connecting to their customers’ networks--thus expanding the pool of available customers and revenue.

Tungsten Fabric, which is the Mirantis OpenStack for Kubernetes SDN of choice for telco clouds, offers several ways to encapsulate tenant traffic passing through the virtual networks, each suitable for its own particular case. These include:

• MPLS over GRE--the traditional encapsulation mechanism supported by several network equipment vendors, including Cisco and Juniper.
• MPLS over UDP--a variation of MPLS over GRE, the default and the most widely-commonly with Mirantis OpenStack for Kubernetes. MPLS over UDP basically is similar to MPLSoGRE but uses UDP headers with GRE. An advantage of this method is that a hash of the packet payload (entropy) is stored in the source UDP port to enhance ECMP load balancing across the underlying IP fabric. Just like the previous protocol, MPLS over UDP is only able to transport Layer 3 traffic, or basically, any protocol that has IP underneath.
• VXLAN, created by VMware, Arista Networks, and Cisco and widely backed by many major vendors, is an evolution of efforts to standardize on an overlay encapsulation protocol that would be able to offer the capabilities of VLAN technology, but on top of pure layer 3 networking.

Today, multiple customers rely on VXLAN technology in combination with EVPN function in Tungsten Fabric to create advanced cloud networking topologies to, for example, provide transparent layer 2 interconnections between the VNFs running on top of the cloud and physical traffic generator appliances hosted elsewhere.

Starting with the 22.1 release, VXLAN encapsulation will become officially supported. Cloud operators will be able to set VXLAN as a default encapsulation for their cloud using the Tungsten Fabric life cycle management API provided by the Mirantis OpenStack for Kubernetes.

Host OS kernel 5.4 and seamless upgrade mechanism

It is critical for our customers to minimize downtime of the infrastructure, but also ensure they have the latest security patches or other enhancements they require. This requires the ability to provide a seamless upgrade mechanism to deploy new releases, but also provide the administrators with the control they need to address specific business requirements.

Mirantis OpenStack for Kubernetes and Mirantis Container Cloud are built on the foundation of many open source projects, including Ubuntu as the host operating system. Stability is the primary criteria for selecting the version of a component to include in the product. Mirantis Container Cloud and Mirantis OpenStack for Kubernetes have been relying on Ubuntu 18 (Bionic Beaver) with kernel 4.15 as the long-term supported bundle. However, time flies quickly, and now Ubuntu 18 is already 4 years old and is too old to work with the latest server hardware, whether it be CPUs such as 2nd and 3rd generation AMD EPYC, hardware RAID controllers, or network interface cards.

To bring the platform up to date, we decided to switch to Linux kernel 5.4, which is the latest LTS kernel available in Ubuntu 18 and includes an updated hardware enablement stack carried over from Ubuntu 20.04. The new kernel will get automatically rolled out on Mirantis OpenStack for Kubernetes clusters together with the 22.1 release, which basically means a fresh package will get downloaded and installed to the nodes within a cluster, with a reboot to follow.

Naturally, such an impactful operation should only be applied to the cluster node by node under the supervision of a human operator. The life cycle management API for Mirantis Container Cloud and Mirantis OpenStack for Kubernetes was extended to enable an operator to define the preferred way of upgrading each individual node, taking advantage of 3 options:

• Upgrade the node by automatically live-migrating all the OpenStack instances from it--this mode is default and is applicable to the majority of compute nodes
• Upgrade the node only once the operator explicitly confirms it is ready--this mode should be used for the controller nodes or computes running critical applications
• Upgrade the node completely automatically ignoring the workloads--this mode should be used for storage nodes or computes hosting non-critical workloads

By thoughtfully applying one of these policies to each node of the cluster and arranging maintenance windows, cloud operators can ensure that even large clouds can get seamlessly upgraded with no impact on the business.

Migration to Kernel 5.4 and the new seamless upgrade mechanism have delivered business value to customers of Mirantis OpenStack for Kubernetes in ways such as:

• Compliance with enterprise requirements that mandate that the hosts must be running an OS that officially supports the target hardware
• Ability to leverage latest drivers included into the kernel, enabling the use of the RAID controller or NICs of choice.

Automatic backup of Tungsten Fabric databases (technical preview)

As we often do with our products, we like to provide “previews” of features that are in the works, enabling you to start to work with these functionalities and see how they can benefit your infrastructure, as well as to provide us with early feedback. In 22.1 we have included a technical preview of a feature that enables automatic backup of Tungsten Fabric databases.

Taking regular snapshots of the cloud metadata and writing it to external storage living outside the cloud infrastructure is an essential part of a disaster recovery strategy. Previously Mirantis OpenStack for Kubernetes provided automatic backups only for the OpenStack database layer, but starting with the 22.1 release, an operator can configure a similar regular routine for the Zookeeper and Cassandra clusters that are part of Tungsten Fabric. The backup data will then get transparently pushed “off-cloud” by writing it to an NFS share (or any other container storage supported by Mirantis Kubernetes Engine) mounted as a persistent K8s volume.

Conclusion

We hope that this overview of these new features in Mirantis OpenStack for Kubernetes 22.1 has been insightful and informative. We are excited to continue to bring new capabilities to our customers who employ the power of OpenStack in their infrastructure. For more details on these and other changes in the 22.1 release, please refer to the Release Notes. If you would like to experience the power that Mirantis OpenStack for Kubernetes can bring to your infrastructure, we welcome you to take it for a spin with the free trial.