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 an L2 template for a new cluster

After you create subnets for one or more MOSK clusters or projects as described in Create subnets, follow the procedure below to create L2 templates for a MOSK cluster.

L2 templates are used directly during provisioning. This way, a hardware node obtains and applies a complete network configuration during the first system boot.

Create an L2 template for a new MOSK cluster

Caution

Create L2 templates before adding any machines to your new MOSK cluster.

1. Log in to a local machine where your management cluster kubeconfig is located and where kubectl is installed.

   Note

   The management cluster kubeconfig is created during the last stage of the management cluster bootstrap.

2. Create a set of L2Template YAML files specific to your deployment using exemplary templates provided in Create L2 templates.

   Note

   You can create several L2 templates with different configurations to be applied to different nodes of the same cluster. See Assign L2 templates to machines for details.

3. Add or edit the mandatory labels and parameters in the new L2 template. For description of mandatory labels and parameters, see L2Template.

4. Optional. To designate an L2 template as default, assign the ipam/DefaultForCluster label to it. Only one L2 template in a cluster can have this label. It will be used for machines that do not have an L2 template explicitly assigned to them.

   Note

   You may skip this step and add the default label along with other custom labels using the MOSK management console, as described below in this procedure.

   To assign the default template to the cluster, use the mandatory cluster.sigs.k8s.io/cluster-name label in the L2 template metadata section.

5. Optional. Add custom labels to the L2 template. You can refer to these labels to assign the L2 template to machines.

6. Add the L2 template to your management cluster. Select one of the following options:

   Using the MOSK management API

   kubectl --kubeconfig <pathToManagementClusterKubeconfig> apply -f <pathToL2TemplateYamlFile>
   

   Using the MOSK management console

   1. Log in to the MOSK management console with the m:kaas:namespace@operator or m:kaas:namespace@writer 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. In the left sidebar, navigate to Networks and click the L2 Templates tab.

   4. Click Create L2 Template.

   5. Fill out the Create L2 Template form as required:

      • Name

        L2 template name.

      • Cluster

        Cluster name that the L2 template is being added for. To set the L2 template as default for all machines, also select Set default for the cluster.

      • Specification

        L2 specification in the YAML format that you have previously created. Click Edit to edit the L2 template if required.

      • Labels

        Key-value pairs attached to the L2 template. For details, see L2Template metadata.

7. Optional. Further modify the template, if required. For description of parameters, see L2Template.

   kubectl --kubeconfig <pathToManagementClusterKubeconfig> \
   -n <ProjectNameForNewMOSKCluster> edit l2template <L2templateName>
   

   Caution

   Modification of L2 templates in use is only allowed with a mandatory validation step from the infrastructure operator to prevent accidental cluster failures due to unsafe changes. The list of risks posed by modifying L2 templates includes:

   • Services running on hosts cannot reconfigure automatically to switch to the new IP addresses and/or interfaces.

   • Connections between services are interrupted unexpectedly, which can cause data loss.

   • Incorrect configurations on hosts can lead to irrevocable loss of connectivity between services and unexpected cluster partition or disassembly.

   For details, see Modify network configuration on an existing machine.

8. Proceed with Add a machine. The resulting L2 template will be used to render the netplan configuration for the MOSK cluster machines.

Workflow of the netplan configuration using an L2 template

1. The kaas-ipam service uses the data from BareMetalHost, L2Template, and Subnet objects to generate the netplan configuration for every cluster machine.

2. The generated netplan configuration is saved in the status.netconfigFiles section of the IpamHost object. If the status.netconfigFilesState field of the IpamHost object is OK, the configuration was rendered in the IpamHost object successfully. Otherwise, the status contains an error message.

   Caution

   The netconfigFilesStates field contains a dictionary of statuses of network configuration files stored in netconfigFiles. The dictionary contains the keys that are file paths and values that have the following meaning for each file:

   • For a successfully rendered configuration file: OK: <timestamp> <sha256-hash-of-rendered-file>, where a timestamp is in the RFC 3339 format.

   • For a failed rendering: ERR: <error-message>.

3. The baremetal-provider service copies data from status.netconfigFiles of the IpamHost object to the Spec.StateItemsOverwrites[‘deploy’][‘bm_ipam_netconfigv2’] parameter of LCMMachine.

4. The lcm-agent service on every host synchronizes the LCMMachine data to its host. The lcm-agent service runs a playbook to update the netplan configuration on the host during the pre-download and deploy phases.