Mirantis Container Cloud (MCC) becomes part of Mirantis OpenStack for Kubernetes (MOSK)!

Now, the MOSK documentation set covers all product layers, including MOSK management (formerly Container Cloud). This means everything you need is in one place. Some legacy names may remain in the code and documentation and will be updated in future releases. The separate Container Cloud documentation site will be retired, so please update your bookmarks for continued easy access to the latest content.

Create subnets for a cluster using MOSK management console

After creating the MetalLB configuration as described in Configure and verify MetalLB and before creating an L2 template, create the required subnets to use in the L2 template to allocate IP addresses for the MOSK cluster nodes.

To create subnets for a MOSK cluster using the MOSK management console:

  1. Log in to the MOSK management console with the operator permissions.

  2. Switch to the required non-default project using the Switch Project action icon located on top of the main left-side navigation panel.

    Caution

    Do not create a MOSK cluster in the default project (Kubernetes namespace), which is dedicated for the management cluster only. If no projects are defined, first create a new mosk project as described in Create a project for MOSK clusters.

  3. Create basic cluster settings as described in Create a MOSK cluster.

  4. In the left sidebar, navigate to Networks. The Subnets tab opens.

  5. Click Create Subnet.

  6. Fill out the Create subnet form as required:

    • Name

      Subnet name.

    • Subnet Type

      Subnet type:

      • DHCP Optional

        DHCP subnet that configures DHCP address ranges used by the DHCP server on the management cluster. For details, see Configure multiple DHCP address ranges.

      • LB

        Cluster API LB subnet.

      • LCM

        LCM subnet(s).

      • Storage access Optional

        Does not apply for MiraCeph. Storage access subnet.

      • Storage replication Optional

        Does not apply for MiraCeph. Storage replication subnet.

      • Custom Optional

        Custom subnet. For example, external or for Kubernetes workloads. For details, see optional steps in Create subnets for a cluster using CLI.

      For description of subnet types in a MOSK cluster, see MOSK cluster networking.

    • Cluster

      Cluster name that the subnet is being created for. Not required only for the DHCP subnet.

    • CIDR

      A valid IPv4 address of the subnet in the CIDR notation, for example, 10.11.0.0/24.

    • Include Ranges Optional

      A comma-separated list of IP address ranges within the given CIDR that should be used in the allocation of IPs for nodes. The gateway, network, broadcast, and DNSaddresses will be excluded (protected) automatically if they intersect with one of the range. The IPs outside the given ranges will not be used in the allocation. Each element of the list can be either an interval 10.11.0.5-10.11.0.70 or a single address 10.11.0.77.

      Warning

      Do not use values that are out of the given CIDR.

    • Exclude Ranges Optional

      A comma-separated list of IP address ranges within the given CIDR that should not be used in the allocation of IPs for nodes. The IPs within the given CIDR but outside the given ranges will be used in the allocation. The gateway, network, broadcast, and DNS addresses will be excluded (protected) automatically if they are included in the CIDR. Each element of the list can be either an interval 10.11.0.5-10.11.0.70 or a single address 10.11.0.77.

      Warning

      Do not use values that are out of the given CIDR.

    • Gateway Optional

      A valid IPv4 gateway address, for example, 10.11.0.9. Does not apply to the MetalLB subnet.

    • Nameservers

      IP addresses of nameservers separated by a comma. Does not apply to the DHCP and MetalLB subnet types.

    • Use whole CIDR

      Optional. Select to use the whole IPv4 address range that is set in the CIDR field. Useful when defining single IP address (/32), for example, in the Cluster API load balancer (LB) subnet.

      If not set, the network address and broadcast address in the IP subnet are excluded from the address allocation.

    • Labels

      Optional user-defined key-value pairs attached to the selected subnet to distinguish different subnets of the same type. For an example of user-defined labels, see Expand IP addresses capacity in an existing cluster.

      Caution

      The values of the created subnet labels must match the ones in the spec.l3Layout section of the corresponding L2Template object.

      The following special values define the storage subnets:

      • ipam/SVC-ceph-cluster

      • ipam/SVC-ceph-public

      For more examples of label usage, see Service labels and their life cycle and Create subnets for a cluster using CLI.

      Click Add a label and assign the first custom label with the required name and value. To assign consecutive labels, use the + button located in the right side of the Labels section.

  7. Click Create.

  8. In the Networks tab, verify the status of the created subnet:

    • Ready - object is operational.

    • Error - object is non-operational. Hover over the status to obtain details of the issue.

    Note

    To verify subnet details, in the Networks tab, click the More action icon in the last column of the required subnet and select Subnet info.

Proceed to creating L2 templates as described in Create L2 templates.