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

Starting with MOSK 25.2, the MOSK documentation set covers all product layers, including MOSK management (formerly MCC). This means everything you need is in one place. The separate MCC documentation site will be retired, so please update your bookmarks for continued easy access to the latest content.

Update a cluster in an air-gapped environment

Available since MCC 2.30.0 (21.0.0 and 20.0.0) TechPreview

Updating a cluster in an air-gapped private CDN involves the following additional steps aside from the standard MOSK update process depending on the way a cluster was originally deployed:

  • If a cluster was originally deployed in an air-gapped environment, the update process additionally includes stopping release-controller and transfering new release artifacts to a private CDN. Starting release-controller triggers the standard MOSK update process. This option is available since 25.2 for MOSK clusters and 2.30.0 for management clusters.

  • If a cluster was originally deployed in a non-airgapped environment, the update process is similar to updating an air-gapped cluster, but additionally includes applying a CA certificate and updating CDN paths in the Cluster object. This option is available since MOSK 25.1 after the management cluster update to 2.29.1.

Update an air-gapped cluster

  1. Download the latest available release files and prepare a new offline copy using the procedure for initial deployment of an air-gapped cluster. For details, see Prepare an offline copy for an air-gapped cluster and Prepare a demo CDN.

  2. Stop release-controller to prevent the cluster from an accidental update during data structure transfer:

    kubectl -n kaas scale deployment release-controller-release-controller --replicas 0
    
  3. Back up existing release files located in the releases directory on your binary CDN.

  4. Transfer new artifacts to the private CDN as described in Transfer artifacts from the demo CDN to private CDN.

  5. Start release-controller to trigger the management cluster update:

    kubectl -n kaas scale deployment release-controller-release-controller --replicas 1
    

    Warning

    This action cannot be paused. Therefore, ensure that all preparation steps are completed before starting release-controller.

  6. Proceed to the usual update procedure as described in Update to a major version or Update to a patch version.

Update a non-airgapped cluster in an air-gapped environment

  1. Prepare resources and storage for an offline copy of new release artifacts as described in Requirements for air-gapped clusters.

  2. Download the latest available release files and prepare a new offline copy using the procedure for initial deployment of an air-gapped cluster. For details, see Prepare an offline copy for an air-gapped cluster and Prepare a demo CDN.

  3. Stop release-controller to prevent the cluster from an accidental update during data structure transfer:

    kubectl -n kaas scale deployment release-controller-release-controller --replicas 0
    
  4. Select one of the following options:

    • Management cluster 2.29.1 or later with MOSK 25.1 or later: apply a proxy CA certificate

    • Management cluster 2.30.0 or later with MOSK 25.2 or later: apply a CDN CA certificate

    To apply a CDN CA certificate
    1. Download the CA certificate ca.crt for your private CDN endpoints and convert it to a base64 string:

      cat ca.crt | base64 -w0; echo ''
      
    2. In the Cluster object of the management cluster, update caBundle with the base64 CA certificate created in the previous step:

      Important

      The base64 value must be a single-line string.

      apiVersion: cluster.k8s.io/v1alpha1
      kind: Cluster
      spec:
        providerSpec:
          value:
            kaas:
              regional:
              - helmReleases:
                - name: baremetal-provider
                  values:
                    config:
                      lcm:
                        cdn:
                          caBundle: <BASE64 CA certificate as a single-line string>
      
    To apply a proxy CA certificate
    1. Download the CA certificate ca.crt for your private CDN endpoints and convert it to a base64 string:

      cat ca.crt | base64 -w0; echo ''
      
    2. Create a fake-proxy.yaml Proxy object with the following content:

      apiVersion: kaas.mirantis.com/v1alpha1
      kind: Proxy
      metadata:
        labels:
          kaas.mirantis.com/region: region-one
        name: fake-proxy
        namespace: default
      spec:
        httpProxy: http://127.0.0.1:3128
        httpsProxy: http://127.0.0.1:3128
        noProxy: <comma-separated private CDN IP addresses>,.mirantis.com,.mirantis.net,mirantis.azurecr.io
        caCertificate: <BASE64 CA certificate as a single-line string>
      

      Important

      The base64 CA certificate value must be a single-line string.

    3. Apply fake-proxy.yaml to your management cluster:

      kubectl create -f fake-proxy.yaml
      
    4. Update the Cluster object of your management cluster with proxy data:

      kubectl patch cluster kaas-mgmt --type 'merge' -p '{"spec": {"providerSpec": {"value": {"proxy": "fake-proxy"}}}}'
      

      While LCM is applying the CA certificate, the Cluster object switches to the Not Ready state.

    5. Wait until the Cluster object status switches back to Ready:

      kubectl get cluster kaas-mgmt -o wide -w
      
  5. Wait until all LCMMachine objects of the management cluster complete the Ready Prepare Deploy Reconfigure Ready cycle:

    kubectl get lcmmachine -o wide
    
  6. Wait until the Cluster object status switches back to Ready:

    kubectl get cluster kaas-mgmt -o wide -w
    

    Note

    Once done, manually interrupt the above command.

  7. Back up existing release files located in the releases directory on your binary CDN.

  8. Transfer new artifacts to the private CDN as described in Transfer artifacts from the demo CDN to private CDN.

  9. In the Cluster object of the management cluster, replace mirror URLs with endpoints of your private CDN:

    apiVersion: cluster.k8s.io/v1alpha1
    kind: Cluster
    spec:
      providerSpec:
        value:
          kaas:
            management:
              helmReleases:
              - name: release-controller
                values:
                  releasesBaseUrl: <MCC_CDN_BINARY>/releases
              - name: diagnostic-controller
                values:
                  releasesBaseUrl: <MCC_CDN_BINARY>/releases
            regional:
            - helmReleases:
              - name: baremetal-provider
                values:
                  config:
                    lcm:
                      cdn:
                        binary: <MCC_CDN_BINARY>
                        debian: <MCC_CDN_DEBIAN>
                        docker: <MCC_CDN_DOCKER>
                        mcrRepo: <MCC_CDN_MCR_REPO>
    

    Parameter name

    Description

    Endpoint format

    <MCC_CDN_BINARY>

    MOSK binary files such as Helm charts, deployment artifacts, release files, and so on.

    https://binary.<private CDN domain suffix>

    <MCC_CDN_DEBIAN>

    Ubuntu repository mirrors.

    https://debian.<private CDN domain suffix>

    <MCC_CDN_MCR_REPO>

    MCR Ubuntu repository.

    https://mcr.<private CDN domain suffix>

    <MCC_CDN_DOCKER>

    Docker reristry.

    registry.<private CDN domain suffix>

  10. Wait until all LCMMachine objects of the management cluster complete the Ready Prepare Deploy Reconfigure Ready cycle:

    kubectl get lcmmachine -o wide
    
  11. Wait until the Cluster object status switches back to Ready:

    kubectl get cluster kaas-mgmt -o wide -w
    

    Note

    Once done, manually interrupt the above command.

  12. Start release-controller to trigger the management cluster update:

    kubectl -n kaas scale deployment release-controller-release-controller --replicas 1
    

    Warning

    This action cannot be paused. Therefore, ensure that all preparation steps are completed before starting release-controller.

  13. Proceed to the usual update procedure as described in Update to a major version or Update to a patch version.