1. HOME
  2. Mirantis Container Cloud Reference Architecture
  3. Hardware and system requirements
  4. OpenStack-based cluster

OpenStack-based cluster

OpenStack-based cluster

While planning the deployment of an OpenStack-based Mirantis Container Cloud cluster with Mirantis Kubernetes Engine (MKE), consider the following general requirements:

  • Kubernetes on OpenStack requires the Cinder and Octavia APIs availability.

  • The only supported OpenStack networking is Open vSwitch. Other networking technologies, such as Tungsten Fabric, are not supported.

  • The bootstrap and management clusters must have access to *.mirantis.com to download the release information and artifacts.

Note

Container Cloud is developed and tested on OpenStack Queens.

Requirements for an OpenStack-based Container Cloud cluster

Resource

Bootstrap cluster 0

Management or regional cluster

Managed cluster

Comments

# of nodes

1

3 (HA) + 1 (Bastion)

5 (6 with StackLight HA)

  • A bootstrap cluster requires access to the OpenStack API.

  • Each management or regional cluster requires 3 nodes for the manager nodes HA. Adding more than 3 nodes to a management or regional cluster is not supported.

  • A managed cluster requires 3 nodes for the manager nodes HA and 2 nodes for the Container Cloud workloads. If the multiserver mode is enabled for StackLight, 3 nodes are required for the Container Cloud workloads.

  • Each management or regional cluster requires 1 node for the Bastion instance that is created with a public IP address to allow SSH access to instances.

# of vCPUs per node

2

8

8

  • The Bastion node requires 1 vCPU.

  • Refer to the RAM recommendations described below to plan resources for different types of nodes.

RAM in GB per node

4

16

16

To prevent issues with low RAM, Mirantis recommends the following types of instances for a managed cluster with 50-200 nodes:

  • 16 vCPUs and 32 GB of RAM - manager node

  • 16 vCPUs and 128 GB of RAM - nodes where the StackLight server components run

The Bastion node requires 1 GB of RAM.

Storage in GB per node

5 (available)

120

120

For the Bastion node, the default amount of storage is enough.

Operating system

Ubuntu 16.04 or 18.04

Ubuntu 18.04

Ubuntu 18.04

For management, regional, and managed clusters, a base Ubuntu 18.04 image with the default SSH ubuntu user name must be present in Glance.

Docker version

18.09

-

-

For management, regional, and managed clusters, Mirantis Container Runtime 19.03.12 In 2.2.0 or 19.03.13 Starting 2.3.0 is deployed by Container Cloud as a CRI.

OpenStack version

-

Queens

Queens

Obligatory OpenStack components

-

Octavia, Cinder, OVS

Octavia, Cinder, OVS

# of Cinder volumes

-

7 (total 110 GB)

5 (total 60 GB)

  • Each management or regional cluster requires 2 volumes for Container Cloud (total 50 GB) and 5 volumes for StackLight (total 60 GB)

  • A managed cluster requires 5 volumes for StackLight

# of load balancers

-

10 (management) + 7 (regional)

6

  • LBs for a management cluster:

    • 1 for MKE

    • 1 for Container Cloud UI

    • 1 for Keycloak service

    • 1 for IAM service

    • 6 for StackLight

  • LBs for a regional cluster:

    • 1 for MKE

    • 6 for StackLight

  • LBs for a managed cluster:

    • 1 for MKE

    • 5 for StackLight with enabled logging (or 4 without logging)

# of floating IPs

-

11 (management) + 8 (regional)

11

  • FIPs for a management cluster:

    • 1 for MKE

    • 1 for Container Cloud UI

    • 1 for Keycloak service

    • 1 for IAM service

    • 1 for the Bastion node (or 3 without Bastion: one FIP per manager node)

    • 6 for StackLight

  • FIPs for a regional cluster:

    • 1 for MKE

    • 1 for the Bastion node (or 3 without Bastion)

    • 6 for StackLight

  • FIPs for a managed cluster:

    • 1 for MKE

    • 3 for the manager nodes

    • 2 for the worker nodes

    • 5 for StackLight with enabled logging (4 without logging)
0

The bootstrap cluster is necessary only to deploy the management cluster. When the bootstrap is complete, this cluster can be deleted and its resources can be reused for a managed cluster workloads.

updated: 2021-01-20 12:43