Mirantis Container Cloud overview
Mirantis Container Cloud 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 the Container Cloud overview:
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.
The types of the Container Cloud clusters include:
- Bootstrap cluster
Runs the bootstrap process on a seed node. For the OpenStack-based or AWS-based Container Cloud, it can be an operator desktop computer. For the baremetal-based Container Cloud, this is the first temporary data center node.
Requires access to a provider back end, OpenStack, AWS, or bare metal.
Contains minimum set of services to deploy the 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 a 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 an AWS-based management cluster with AWS-based and OpenStack-based regional clusters.
Supported combinations of providers types for management and regional clusters¶ Regional cluster provider
Bare metal
AWS
OpenStack
vSphere Tech Preview
Bare metal management cluster
✗
✗
✓
✗
AWS management cluster
✗
✓
✓
✓
OpenStack management cluster
✗
✗
✓
✗
vSphere management cluster Tech Preview
✗
✗
✗
✓
- Managed cluster
A Container Cloud cluster with Mirantis Kubernetes Engine (MKE) that an end user creates using Container Cloud.
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.
Starting from MKE 3.3.3, a user can also attach and manage an existing MKE cluster that is not created using Container Cloud. In such case, nodes of the attached cluster do not contain LCM agent.
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 the following Docker Enterprise documentation:
The following diagram illustrates the distribution of services between each type of the Container Cloud clusters:
