Overview

Mirantis Container Cloud is a set of microservices that are deployed using Helm charts and run in a Kubernetes cluster. Container Cloud is based on the Kubernetes Cluster API community initiative.

The following diagram illustrates an overview of Container Cloud and the clusters it manages:

../_images/cluster-overview.png

All artifacts used by Kubernetes and workloads are stored on the Container Cloud content delivery network (CDN):

  • mirror.mirantis.com (Debian packages including the Ubuntu mirrors)

  • binary.mirantis.com (Helm charts and binary artifacts)

  • mirantis.azurecr.io (Docker image registry)

All Container Cloud components are deployed in the Kubernetes clusters. All Container Cloud APIs are implemented using the Kubernetes Custom Resource Definition (CRD) that represents custom objects stored in Kubernetes and allows you to expand Kubernetes API.

The Container Cloud logic is implemented using controllers. A controller handles the changes in custom resources defined in the controller CRD. A custom resource consists of a spec that describes the desired state of a resource provided by a user. During every change, a controller reconciles the external state of a custom resource with the user parameters and stores this external state in the status subresource of its custom resource.

Container Cloud regions

Unsupported since 2.25.0

Caution

Regional clusters are unsupported since Container Cloud 2.25.0. Mirantis does not perform functional integration testing of the feature and intends to remove the related code in Container Cloud 2.26.0. If you still require this feature, contact Mirantis support for further information.

Container Cloud can have several regions. A region is a physical location, for example, a data center, that has access to one or several cloud provider back ends. A separate regional cluster manages a region that can include multiple providers. A region must have a two-way (full) network connectivity between a regional cluster and a cloud provider back end. For example, an OpenStack VM must have access to the related regional cluster. And this regional cluster must have access to the OpenStack floating IPs and load balancers.

The following diagram illustrates the structure of the Container Cloud regions:

../_images/regions.png

Container Cloud cluster types

The types of the Container Cloud clusters include:

Bootstrap cluster v2 Recommended since 2.25.0

  • Contains the Bootstrap web UI for the OpenStack and vSphere providers. The Bootstrap web UI support for the bare metal provider will be added in one of the following Container Cloud releases.

  • Runs the bootstrap process on a seed node that can be reused after the management cluster deployment for other purposes. For the OpenStack or vSphere provider, it can be an operator desktop computer. For the bare metal provider, this is a data center node.

  • Requires access to one of the following provider back ends: bare metal, OpenStack, or vSphere.

  • Initially, the bootstrap cluster is created with the following minimal set of components: Bootstrap Controller, public API charts, and the Bootstrap web UI.

  • The user can interact with the bootstrap cluster through the Bootstrap web UI or API to create the configuration for a management cluster and start its deployment. More specifically, the user performs the following operations:

    1. Select the provider, add provider credentials.

    2. Add proxy and SSH keys.

    3. Configure the cluster and machines.

    4. Deploy a management cluster.

  • The user can monitor the deployment progress of the cluster and machines.

  • After a successful deployment, the user can download the kubeconfig artifact of the provisioned cluster.

Bootstrap cluster v1 Deprecated since 2.25.0

  • Runs the bootstrap process on a seed node that can be reused after the management cluster deployment for other purposes. For the OpenStack or vSphere provider, it can be an operator desktop computer. For the bare metal provider, this is a data center node.

  • Requires access to one of the following provider back ends: OpenStack, vSphere, or bare metal.

  • Contains a minimum set of services to deploy management and regional clusters.

  • Is destroyed completely after a successful bootstrap.

Management and regional clusters

  • Management cluster:

    • Runs all public APIs and services including the web UIs of Container Cloud.

    • Does not require access to any provider back end.

  • Regional cluster:

    • Is combined with management cluster by default.

    • Runs the provider-specific services and internal API including LCMMachine and LCMCluster. Also, it runs an LCM controller for orchestrating managed clusters and other controllers for handling different resources.

    • Requires two-way access to a provider back end. The provider connects to a back end to spawn managed cluster nodes, and the agent running on the nodes accesses the regional cluster to obtain the deployment information.

    • Requires access to a management cluster to obtain user parameters.

    • Supports multi-regional deployments. For example, you can deploy a vSphere-based management cluster with vSphere-based and OpenStack-based regional clusters.

    Caution

    Regional clusters are unsupported since Container Cloud 2.25.0. Mirantis does not perform functional integration testing of the feature and intends to remove the related code in Container Cloud 2.26.0. If you still require this feature, contact Mirantis support for further information.

Management and regional clusters comprise Container Cloud as product. For deployment details, see Deployment Guide and Deploy an additional regional cluster (optional) sections for the required cloud provider.

Managed cluster

  • A Mirantis Kubernetes Engine (MKE) cluster that an end user creates using the Container Cloud web UI.

  • Requires access to a regional cluster. Each node of a managed cluster runs an LCM Agent that connects to the LCM machine of the regional cluster to obtain the deployment details.

  • Since 2.25.2, an attached MKE cluster that is not created using Container Cloud for vSphere-based clusters. In such case, nodes of the attached cluster do not contain LCM Agent. For supported MKE versions that can be attached to Container Cloud, see Release Compatibility Matrix.

  • Baremetal-based managed clusters support the Mirantis OpenStack for Kubernetes (MOSK) product. For details, see MOSK documentation.

All types of the Container Cloud clusters except the bootstrap cluster are based on the MKE and Mirantis Container Runtime (MCR) architecture. For details, see MKE and MCR documentation.

The following diagram illustrates the distribution of services between each type of the Container Cloud clusters:

../_images/cluster-types.png