Mirantis Container Cloud 2.7 Release

VMware support, proxy, artifacts caching, and UI improvements headline this release

Mirantis Container Cloud 2.7 is now generally available, sporting a new provider enabling deployment and lifecycle management of Container Cloud Management, Regional and (Mirantis Kubernetes Engine) child clusters. Container Cloud can now perform all its functions on VMware clouds, including non-disruptive self- and child-cluster updates and upgrades, plus cache and proxy for air-gapped and high security environments.

The new VMware provider supports deployments of Red Hat Enterprise Linux (RHEL) 7.8(9) as the underlying operating system for Container Cloud and managed cluster nodes. RHEL's activation mechanism is supported to keep users compliant with Red Hat licensing and tracking requirements: OS deployments can be activated by providing Container Cloud with a username/password, or via an activation key obtained from Red Hat's customer customer portal or a Red Hat Satellite server.

Using IPAM, the Container Cloud VMware provider can automatically allocate IP addresses to nodes in networks without a DHCP server. Of course, networks with pre-configured DHCP servers are also supported. The Container Cloud bootstrap utility now incorporates automated functionality that lets the user build a base virtual machine image (VM template) for cluster machines.

The short video below (no sound) shows creation of a Mirantis Kubernetes Engine managed cluster on VMware, using Mirantis Container Cloud.

Proxy support

If you require all Internet access to go through a proxy server for security or audit purposes, you can use the new HTTP proxy for all types of clusters (management, regional and managed). To bootstrap a management or regional cluster, you need to set three standard environment variables prior to starting the bootstrap process:

• HTTP_PROXY
• HTTPS_PROXY
• NO_PROXY

Proxy settings will be propagated to Docker daemon, APT or YUM package managers and internal Mirantis Container Cloud components. For child cluster deployment, you can use the Mirantis Container Cloud UI to register your proxy and enable it for newly created clusters.

Also see the video below (no sound).

Artifacts caching support

Mirantis artifacts used for child cluster deployment (e.g., Docker images, Helm charts, packages, and tarballs) are downloaded to nodes from an Nginx-based cache running on the regional cluster. This lets users deploy managed Mirantis Kubernetes Engine clusters faster, without direct Internet access, while also minimizing traffic. The feature is enabled by default on new child clusters and will be automatically enabled on existing clusters when they are next upgraded.

New status displays in Container Cloud webUI

Mirantis Container Cloud 2.7 introduces greater detail in its user interface. Now, operators can monitor realtime status of cluster components at a glance, and hover over items to reveal more information, for example:

• Bastion - For OpenStack and AWS-based clusters, the Bastion node IP address status confirming Bastion node creation
• Helm - Installation or upgrade status of all Helm releases
• Kubelet - Readiness of the node in a Kubernetes cluster, as reported by kubelet
• Kubernetes - Readiness of all requested Kubernetes objects
• Nodes - Are all requested nodes in Ready state?
• OIDC - Readiness of the cluster OIDC configuration
• StackLight - Health of all StackLight-related objects in a Kubernetes cluster
• Swarm - Readiness of all nodes in a Docker Swarm cluster

Here are the examples of Ready and Not Ready clusters:

A ready cluster, its status displayed in the Mirantis Container Cloud webUI.

A not-ready cluster, its status displayed in the Mirantis Container Cloud webUI.

Users can hover over items listed on the Machines page, too, to reveal additional information.