Bootstrap a management cluster

After you complete the prerequisite steps described in Prerequisites, proceed with bootstrapping your Mirantis Container Cloud management cluster based on the Azure provider.

To bootstrap an Azure-based management cluster:

  1. Log in to the bootstrap node running Ubuntu 20.04 that is configured as described in Prerequisites.

  2. Prepare the bootstrap script:

    1. Download and run the Container Cloud bootstrap script:

      apt install wget
wget https://binary.mirantis.com/releases/get_container_cloud.sh
chmod 0755 get_container_cloud.sh
./get_container_cloud.sh

    2. Change the directory to the kaas-bootstrap folder created by the script.

  3. Obtain your license file that will be required during the bootstrap:

    1. Create a user account at www.mirantis.com.

    2. Log in to your account and download the mirantis.lic license file.

    3. Save the license file as mirantis.lic under the kaas-bootstrap directory on the bootstrap node.

    4. Verify that mirantis.lic contains the exact Container Cloud license previously downloaded from www.mirantis.com by decoding the license JWT token, for example, using jwt.io.

      Example of a valid decoded Container Cloud license data with the mandatory license field:

      {
    "exp": 1652304773,
    "iat": 1636669973,
    "sub": "demo",
    "license": {
        "dev": false,
        "limits": {
            "clusters": 10,
            "workers_per_cluster": 10
        },
        "openstack": null
    }
}

      Warning

      The MKE license does not apply to mirantis.lic. For details about MKE license, see MKE documentation.

  4. Prepare the Azure configuration for the new cluster:

    1. Create an Azure service principal. Skip this step to use an existing Azure service principal.

      1. Create a Microsoft Azure account.

      2. Install Azure CLI.

      3. Log in to the Azure CLI:

        az login

      4. List your Azure accounts:

        az account list -o table

      5. If more than one account exists, select the account dedicated for Container Cloud:

        az account set -s <subscriptionID>

      6. Create an Azure service principal:

        Caution

        The owner role is required to create role assignments.

        az ad sp create-for-rbac --role contributor --scopes="/subscriptions/<subscriptionID>"

        Example of system response:

        {
   "appId": "0c87aM5a-e172-182b-a91a-a9b8d39ddbcd",
   "displayName": "azure-cli-2021-08-04-15-25-16",
   "name": "1359ac72-5794-494d-b787-1d7309b7f8bc",
   "password": "Q1jB2-7Uz6Cka7xos6vL-Ddb4BQx2vgMl",
   "tenant": "6d498697-7anvd-4172-a7v0-4e5b2e25f280"
}

    2. Configure deployment templates:

      1. Change the directory to kaas-bootstrap.

      2. Export the following parameter:

        export KAAS_AZURE_ENABLED=true

      3. In templates/azure/azure-config.yaml.template, modify the following parameters using credentials obtained in the previous steps or using credentials of an existing Azure service principal obtained from the subscription owner:

        • spec:subscriptionID is the subscription ID of your Azure account

        • spec:tenantID is the value of "tenant"

        • spec:clientID is the value of "appId"

        • spec:clientSecret:value is the value of "password"

        For example:

        spec:
  subscriptionID: b8bea78f-zf7s-s7vk-s8f0-642a6v7a39c1
  tenantID: 6d498697-7anvd-4172-a7v0-4e5b2e25f280
  clientID: 0c87aM5a-e172-182b-a91a-a9b8d39ddbcd
  clientSecret:
    value: Q1jB2-7Uz6Cka7xos6vL-Ddb4BQx2vgMl

      4. In templates/azure/cluster.yaml.template, modify the default configuration of the Azure cluster location. This is an Azure region that your subscription has quota for.

        To obtain the list of available locations, run:

        az account list-locations -o=table

        For example:

        providerSpec:
  value:
  ...
    location: southcentralus

        Also, modify other parameters as required.

  5. Optional. In templates/azure/machines.yaml.template, modify the default configuration of the Azure virtual machine size and OS disk size.

    Mirantis Container Cloud only supports Azure virtual machine sizes that meet the following minimum requirements:

    1. More than 8 CPU

    2. More than 24 GB RAM

    3. Ephemeral OS drive supported

    4. Temporary storage size is more than 128 GB

    Set the OS disk size parameter to at least 128 GB (default value) and verify that it does not exceed the temporary storage size.

    To obtain the list of all Azure virtual machine sizes available in the selected Azure region:

    az vm list-skus -l southcentralus -o=json

    To filter virtual machine sizes by the Container Cloud minimum requirements:

    1. Install jq.

    2. Run the following command:

      az vm list-skus -l eastus -o=json | jq '.[] | {name: .name}+{vCPUs: .capabilities[]? | select(.name == "vCPUs" and (.value | tonumber >= 8))}+{RAM: .capabilities[]? | select(.name == "MemoryGB" and (.value | tonumber >= 16))}+{EphemeralOSDiskSupported: .capabilities[]? | select(.name == "EphemeralOSDiskSupported" and .value == "True")}+{TempStorageSize: .capabilities[]? | select(.name == "CachedDiskBytes" and (.value | tonumber >= 137438953472))}'

      The default VM size is Standard_F16s_v2:

      providerSpec:
  value:
  ...
    vmSize: Standard_F16s_v2
    osDisk:
      osType: Linux
      diskSizeGB: 128

    Also, modify other parameters as required.

  6. Optional if servers from the Ubuntu NTP pool (*.ubuntu.pool.ntp.org) are accessible from the node where the management cluster is being provisioned. Otherwise, this step is mandatory.

    Configure the regional NTP server parameters to be applied to all machines of regional and managed clusters in the specified region.

    In templates/azure/cluster.yaml.template, add the ntp:servers section with the list of required server names:

    spec:
  ...
  providerSpec:
    value:
      kaas:
      ...
        regional:
          - helmReleases:
            - name: azure-provider
              values:
                config:
                  lcm:
                    ...
                    ntp:
                      servers:
                      - 0.pool.ntp.org
                      ...
            provider: azure
            ...

  7. Export the following parameter:

    export KAAS_AZURE_ENABLED=true

  8. If you require Internet access to go through a proxy server, in bootstrap.env, add the following environment variables to bootstrap the management and regional cluster using proxy:

    • HTTP_PROXY

    • HTTPS_PROXY

    • NO_PROXY

    Example snippet:

    export HTTP_PROXY=http://proxy.example.com:3128
export HTTPS_PROXY=http://user:pass@proxy.example.com:3128
export NO_PROXY=172.18.10.0,registry.internal.lan

    The following formats of variables are accepted:

    Proxy configuration data

    Variable

    Format
    HTTP_PROXY
    HTTPS_PROXY

    • http://proxy.example.com:port - for anonymous access

    • http://user:password@proxy.example.com:port - for restricted access

    NO_PROXY

    Comma-separated list of IP addresses or domain names

    For implementation details, see Proxy and cache support.

    For the list of Mirantis resources and IP addresses to be accessible from the Container Cloud clusters, see Requirements for an Azure-based cluster.

  9. Optional. Configure external identity provider for IAM.

  10. Optional. Enable infinite timeout for all bootstrap stages by exporting the following environment variable or adding it to bootstrap.env:

    export KAAS_BOOTSTRAP_INFINITE_TIMEOUT=true

    Infinite timeout prevents the bootstrap failure due to timeout. This option is useful in the following cases:

    • The network speed is slow for artifacts downloading

    • An infrastructure configuration does not allow booting fast

    • A bare-metal node inspecting presupposes more than two HDDSATA disks to attach to a machine

  11. Run the bootstrap script:

    ./bootstrap.sh all

    • In case of deployment issues, refer to Troubleshooting and inspect logs.

    • If the script fails for an unknown reason:

      1. Run the cleanup script:

        ./bootstrap.sh cleanup

      2. Rerun the bootstrap script.

  12. When the bootstrap is complete, collect and save the following management cluster details in a secure location:

    • The kubeconfig file located in the same directory as the bootstrap script. This file contains the admin credentials for the management cluster.

    • The private ssh_key for access to the management cluster nodes that is located in the same directory as the bootstrap script.

      Note

      If the initial version of your Container Cloud management cluster was earlier than 2.6.0, ssh_key is named openstack_tmp and is located at ~/.ssh/.

    • The URL for the Container Cloud web UI.

      To create users with permissions required for accessing the Container Cloud web UI, see Create initial users after a management cluster bootstrap.

    • The StackLight endpoints. For details, see Access StackLight web UIs.

    • The Keycloak URL that the system outputs when the bootstrap completes. The admin password for Keycloak is located in kaas-bootstrap/passwords.yml along with other IAM passwords.

    Note

    The Container Cloud web UI and StackLight endpoints are available through Transport Layer Security (TLS) and communicate with Keycloak to authenticate users. Keycloak is exposed using HTTPS and self-signed TLS certificates that are not trusted by web browsers.

    To use your own TLS certificates for Keycloak, refer to Configure TLS certificates for cluster applications.

    Note

    When the bootstrap is complete, the bootstrap cluster resources are freed up.

  13. Optional. Deploy an additional regional cluster of a different provider type or configuration as described in Deploy an additional regional cluster (optional).

Now, you can proceed with operating your management cluster through the Container Cloud web UI and deploying managed clusters as described in Create and operate an Azure-based managed cluster.

See also