This is a draft document that was built and uploaded automatically. It may document beta software and be incomplete or even incorrect. Use this document at your own risk.

Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
SUSE Telco Cloud Documentation|Day 2 Operations|Edge 3.6 migration

57 Edge 3.6 migration

 

This section explains how to migrate your management and downstream clusters from SUSE Telco Cloud 3.5 to SUSE Telco Cloud 3.6.0.

Important
Important

Always perform cluster migrations from the latest Z-stream release of SUSE Telco Cloud 3.5.

Always migrate to the SUSE Telco Cloud 3.6.0 release. For subsequent post-migration upgrades, refer to the management (Chapter 58, Management Cluster) sections.

The following table lists the different types of clusters and the methods to upgrade clusters:

Table 57.1: Clusters and methods to upgrade downstream clusters
 
Cluster typeMethod

EIB provisioned clusters

See Section 57.1.3, “Fleet” for details.

Metal3 provisioned clusters

See Downstream cluster upgrades (Section 59.3, “Downstream cluster upgrades”) for details.

57.1 Management Cluster

 

This section covers the following topics:

Section 57.1.1, “Prerequisites” - prerequisite steps to complete before starting the migration.

Section 57.1.2, “Upgrade Controller” - how to do a management cluster migration using the Chapter 21, Upgrade Controller.

Section 57.1.3, “Fleet” - how to do a management cluster migration using Chapter 9, Fleet.

57.1.1 Prerequisites

 

57.1.1.1 Upgrade the Bare Metal Operator CRDs

 
Note
Note

Applies only to CAPI/Metal3 management clusters that require a Chapter 11, Metal3 chart upgrade.

The Metal3 Helm chart includes the Bare Metal Operator (BMO) CRDs by leveraging Helm’s CRD directory.

However, this approach has certain limitations, particularly the inability to upgrade CRDs in this directory using Helm. For more information, refer to the Helm documentation.

As a result, before upgrading Metal3 to an SUSE Telco Cloud 3.6.0 compatible version, users must manually upgrade the underlying BMO CRDs.

On a machine with Helm installed and kubectl configured to point to your management cluster:

  1. Manually apply the BMO CRDs:

    helm show crds oci://registry.suse.com/edge/charts/metal3 --version 306.0.26+up0.15.0 | kubectl apply -f -

57.1.1.2 Migrate Metal3 CA Certificate Configuration

 
Note
Note

Applies only to Metal3 deployments that use additional trusted CAs for external media servers with TLS.

The Metal3 Helm chart has changed how trusted CA certificates are configured. Previously, additional CAs were provided via a Secret (tls-ca-additional) with the additionalTrustedCAs boolean flag. The new version uses a ConfigMap containing the complete CA bundle referenced by the global.trustedCAs value.

If you have configured additional trusted CAs for Metal3, you need to migrate from the Secret-based approach to the ConfigMap-based approach:

  1. Create a ConfigMap containing your CA bundle from the existing Secret:

    Extract the certificates from the old Secret:

    kubectl get secret tls-ca-additional -n metal3-system -o jsonpath='{.data}' | \
  jq -r 'to_entries[] | .value' | base64 -d > ca-bundle.pem

    Optional - Include system CA bundle: If your Metal3 deployment also needs to trust public CAs (for example, when accessing external resources over HTTPS), you need to include the system CA bundle in addition to your custom CAs. Extract the system CA bundle from a container image and prepend it to your custom CAs:

    # Extract system CAs from a container image (using podman or docker)
podman run --rm registry.suse.com/bci/bci-base:latest cat /etc/ssl/certs/ca-certificates.crt > system-cas.pem

# Combine system CAs with your custom CAs
cat system-cas.pem ca-bundle.pem > combined-ca-bundle.pem
mv combined-ca-bundle.pem ca-bundle.pem
    Important
    Important

    If you include the system CA bundle, it becomes your responsibility to keep it up-to-date. The system CAs in the container image may become outdated over time as CA certificates expire or are revoked. You should periodically refresh the system CA bundle by re-extracting it from an updated container image.

    Create the ConfigMap with the final CA bundle:

    kubectl create configmap tls-ca-bundle -n metal3-system --from-file=ca-bundle.pem=ca-bundle.pem

  2. Update your Metal3 Helm values to use the new ConfigMap reference:

    Change from:

    global:
  additionalTrustedCAs: true

    To:

    global:
  trustedCAs: tls-ca-bundle

  3. After upgrading the Metal3 Helm chart with the new configuration, you can delete the old Secret:

    kubectl delete secret tls-ca-additional -n metal3-system

57.1.2 Upgrade Controller

 
Important
Important

The Upgrade Controller currently supports SUSE Telco Cloud release migrations only for non air-gapped management clusters.

The following topics are covered as part of this section:

Section 57.1.2.1, “Prerequisites” - prerequisites specific to the Upgrade Controller.

Section 57.1.2.2, “Migration steps” - steps for migrating a management cluster to a new SUSE Telco Cloud version using the Upgrade Controller.

57.1.2.1 Prerequisites

 
57.1.2.1.1 SUSE Telco Cloud 3.6 Upgrade Controller
 

Before using the Upgrade Controller, you must first ensure that it is running a version that is capable of migrating to the desired SUSE Telco Cloud release.

To do this:

  1. If you already have Upgrade Controller deployed from a previous SUSE Telco Cloud release, upgrade its chart:

    helm upgrade upgrade-controller -n upgrade-controller-system oci://registry.suse.com/edge/charts/upgrade-controller --version 306.0.3+up0.1.3

  2. If you do not have Upgrade Controller deployed, follow Section 21.3, “Installing the Upgrade Controller”.

57.1.2.2 Migration steps

 

Performing a management cluster migration with the Upgrade Controller is fundamentally similar to executing an upgrade.

The only difference is that your UpgradePlan must specify the 3.6.0 release version:

apiVersion: lifecycle.suse.com/v1alpha1
kind: UpgradePlan
metadata:
  name: upgrade-plan-mgmt
  # Change to the namespace of your Upgrade Controller
  namespace: CHANGE_ME
spec:
  releaseVersion: 3.6.0

For information on how to use the above UpgradePlan to do a migration, refer to Upgrade Controller upgrade process (Section 58.1, “Upgrade Controller”).

57.1.3 Fleet

 
Note
Note

Whenever possible, use the Section 57.1.2, “Upgrade Controller” for migration.

Refer to this section only for use cases not covered by the Upgrade Controller.

Performing a management cluster migration with Fleet is fundamentally similar to executing an upgrade.

The key differences being that:

  1. The fleets must be used from the release-3.6.0 release of the suse-edge/fleet-examples repository.

  2. Charts scheduled for an upgrade must be upgraded to versions compatible with the SUSE Telco Cloud 3.6.0 release. For a list of the SUSE Telco Cloud 3.6.0 components, refer to Section 75.3, “Release 3.6.0”.

Important
Important

To ensure a successful SUSE Telco Cloud 3.6.0 migration, it is important that users comply with the points outlined above.

57.2 Downstream Clusters

 

Section 57.2.1, “Fleet” - how to do a downstream cluster migration using Chapter 9, Fleet.

57.2.1 Fleet

 

Performing a downstream cluster migration with Fleet is fundamentally similar to executing an upgrade.

The key differences being that:

  1. The fleets must be used from the release-3.6.0 release of the suse-edge/fleet-examples repository.

  2. Charts scheduled for an upgrade must be upgraded to versions compatible with the SUSE Telco Cloud 3.6.0 release. For a list of the SUSE Telco Cloud 3.6.0 components, refer to Section 75.3, “Release 3.6.0”.

Important
Important

To ensure a successful SUSE Telco Cloud 3.6.0 migration, it is important that users comply with the points outlined above.