This is a cache of https://docs.openshift.com/container-platform/4.17/edge_computing/image_based_upgrade/preparing_for_image_based_upgrade/cnf-image-based-upgrade-generate-seed.html. It is a snapshot of the page at 2024-11-27T07:49:04.856+0000.
Generating a seed image for the image-based upgrade with the Lifecycle Agent - Image-based upgrade for single-node OpenShift clusters | Edge computing | OpenShift Container Platform 4.17
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history bug_report picture_as_pdf
×

Generating a seed image for the image-based upgrade with the Lifecycle Agent

Use the Lifecycle Agent to generate the seed image with the SeedGenerator custom resource (CR).

Seed image configuration

The seed image targets a set of single-node OpenShift clusters with the same hardware and similar configuration. This means that the seed image must have all of the components and configuration that the seed cluster shares with the target clusters. Therefore, the seed image generated from the seed cluster cannot contain any cluster-specific configuration.

The following table lists the components, resources, and configurations that you must and must not include in your seed image:

Table 1. Seed image configuration
Cluster configuration Include in seed image

Performance profile

Yes

MachineConfig resources for the target cluster

Yes

IP version [1]

Yes

Set of Day 2 Operators, including the Lifecycle Agent and the OADP Operator

Yes

Disconnected registry configuration [2]

Yes

Valid proxy configuration [3]

Yes

FIPS configuration

Yes

Dedicated partition on the primary disk for container storage that matches the size of the target clusters

Yes

Local volumes

  • StorageClass used in LocalVolume for LSO

  • LocalVolume for LSO

  • LVMCluster CR for LVMS

No

OADP DataProtectionApplication CR

No

  1. Dual-stack networking is not supported in this release.

  2. If the seed cluster is installed in a disconnected environment, the target clusters must also be installed in a disconnected environment.

  3. The proxy configuration on the seed and target clusters does not have to match.

Seed image configuration using the RAN DU profile

The following table lists the components, resources, and configurations that you must and must not include in the seed image when using the RAN DU profile:

Table 2. Seed image configuration with RAN DU profile
Resource Include in seed image

All extra manifests that are applied as part of Day 0 installation

Yes

All Day 2 Operator subscriptions

Yes

DisableOLMPprof.yaml

Yes

TunedPerformancePatch.yaml

Yes

PerformanceProfile.yaml

Yes

SriovOperatorConfig.yaml

Yes

DisableSnoNetworkDiag.yaml

Yes

StorageClass.yaml

No, if it is used in StorageLV.yaml

StorageLV.yaml

No

StorageLVMCluster.yaml

No
Table 3. Seed image configuration with RAN DU profile for extra manifests
Resource Apply as extra manifest

ClusterLogForwarder.yaml

Yes

ReduceMonitoringFootprint.yaml

Yes

SriovFecClusterConfig.yaml

Yes

PtpOperatorConfigForEvent.yaml

Yes

DefaultCatsrc.yaml

Yes

PtpConfig.yaml

If the interfaces of the target cluster are common with the seed cluster, you can include them in the seed image. Otherwise, apply it as extra manifests.

SriovNetwork.yaml SriovNetworkNodePolicy.yaml

If the configuration, including namespaces, is exactly the same on both the seed and target cluster, you can include them in the seed image. Otherwise, apply them as extra manifests.

Generating a seed image with the Lifecycle Agent

Use the Lifecycle Agent to generate a seed image from a managed cluster. The Operator checks for required system configurations, performs any necessary system cleanup before generating the seed image, and launches the image generation. The seed image generation includes the following tasks:

  • Stopping cluster Operators

  • Preparing the seed image configuration

  • Generating and pushing the seed image to the image repository specified in the SeedGenerator CR

  • Restoring cluster Operators

  • Expiring seed cluster certificates

  • Generating new certificates for the seed cluster

  • Restoring and updating the SeedGenerator CR on the seed cluster

Prerequisites

  • RHACM and multicluster engine for Kubernetes Operator are not installed on the seed cluster.

  • You have configured a shared container directory on the seed cluster.

  • You have installed the minimum version of the OADP Operator and the Lifecycle Agent on the seed cluster.

  • Ensure that persistent volumes are not configured on the seed cluster.

  • Ensure that the LocalVolume CR does not exist on the seed cluster if the Local Storage Operator is used.

  • Ensure that the LVMCluster CR does not exist on the seed cluster if LVM Storage is used.

  • Ensure that the DataProtectionApplication CR does not exist on the seed cluster if OADP is used.

Procedure

  1. Detach the managed cluster from the hub to delete any RHACM-specific resources from the seed cluster that must not be in the seed image:

    1. Manually detach the seed cluster by running the following command:

      $ oc delete managedcluster sno-worker-example

      1. Wait until the managed cluster is removed. After the cluster is removed, create the proper SeedGenerator CR. The Lifecycle Agent cleans up the RHACM artifacts.

    2. If you are using GitOps ZTP, detach your cluster by removing the seed cluster’s SiteConfig CR from the kustomization.yaml.

      1. If you have a kustomization.yaml file that references multiple SiteConfig CRs, remove your seed cluster’s SiteConfig CR from the kustomization.yaml:

        apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

generators:
#- example-seed-sno1.yaml
- example-target-sno2.yaml
- example-target-sno3.yaml

      2. If you have a kustomization.yaml that references one SiteConfig CR, remove your seed cluster’s SiteConfig CR from the kustomization.yaml and add the generators: {} line:

        apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

generators: {}

      3. Commit the kustomization.yaml changes in your Git repository and push the changes to your repository.

        The ArgoCD pipeline detects the changes and removes the managed cluster.

  2. Create the secret object so that you can push the seed image to your registry.

    1. Create the authentication file by running the following commands:

      $ MY_USER=myuserid
$ AUTHFILE=/tmp/my-auth.json
$ podman login --authfile ${AUTHFILE} -u ${MY_USER} quay.io/${MY_USER}
      $ base64 -w 0 ${AUTHFILE} ; echo

    2. Copy the output into the seedAuth field in the secret YAML file named seedgen in the openshift-lifecycle-agent namespace:

      apiVersion: v1
kind: secret
metadata:
  name: seedgen (1)
  namespace: openshift-lifecycle-agent
type: Opaque
data:
  seedAuth: <encoded_AUTHFILE> (2)
      1 The secret resource must have the name: seedgen and namespace: openshift-lifecycle-agent fields.
      2 Specifies a base64-encoded authfile for write-access to the registry for pushing the generated seed images.

    3. Apply the secret by running the following command:

      $ oc apply -f secretseedgenerator.yaml

  3. Create the SeedGenerator CR:

    apiVersion: lca.openshift.io/v1
kind: SeedGenerator
metadata:
  name: seedimage (1)
spec:
  seedImage: <seed_container_image> (2)
    1 The SeedGenerator CR must be named seedimage.
    2 Specify the container image URL, for example, quay.io/example/seed-container-image:<tag>. It is recommended to use the <seed_cluster_name>:<ocp_version> format.

  4. Generate the seed image by running the following command:

    $ oc apply -f seedgenerator.yaml

    The cluster reboots and loses API capabilities while the Lifecycle Agent generates the seed image. Applying the SeedGenerator CR stops the kubelet and the CRI-O operations, then it starts the image generation.

If you want to generate more seed images, you must provision a new seed cluster with the version that you want to generate a seed image from.

Verification

  • After the cluster recovers and it is available, you can check the status of the SeedGenerator CR by running the following command:

    $ oc get seedgenerator -o yaml
    Example output
    status:
  conditions:
  - lastTransitionTime: "2024-02-13T21:24:26Z"
    message: Seed Generation completed
    observedGeneration: 1
    reason: Completed
    status: "False"
    type: SeedGenInProgress
  - lastTransitionTime: "2024-02-13T21:24:26Z"
    message: Seed Generation completed
    observedGeneration: 1
    reason: Completed
    status: "True"
    type: SeedGenCompleted (1)
  observedGeneration: 1
    1 The seed image generation is complete.
Additional resources