managed-upgrade-operator

Managed Upgrade Operator

The Managed Upgrade Operator has been created for the OpenShift Dedicated Platform (OSD) to manage the orchestration of automated in-place cluster upgrades.

Whilst the operator's job is to invoke a cluster upgrade, it does not perform any activities of the cluster upgrade process itself. This remains the responsibility of the OpenShift Container Platform. The operator's goal is to satisfy the operating conditions that a managed cluster must hold, both pre- and post-invocation of the cluster upgrade.

Examples of activities that are not core to an OpenShift upgrade process but could be handled by the operator include:

• Pre and post-upgrade health checks.
• Worker capacity scaling during the upgrade period.
• Alerting silence window management.

If you like to contribute to the Managed Upgrade Operator, please read our Contribution Policy first.

• Info
  • Documentation
    • For Developers
  • Workflow - UpgradeConfig
    • Example CR

Info

Documentation

• FAQ -- Frequently Asked Questions.

For Developers

• Design -- Describes the interaction between the operator and the custom resource definition.
• Development -- Instructions for developing and deploying the operator.
• Metrics -- Prometheus metrics produced by the operator.
• Testing -- Instructions for writing tests.

Workflow - UpgradeConfig

1. The operator watches all namespaces for an UpgradeConfig resource.
2. When an UpgradeConfig is found or modified, the operator checks the Status History to determine if this upgrade has been applied to the cluster.
   • If the UpgradeConfig history indicates that the cluster has been successfully upgraded to the defined version, no further action is taken.
3. If there is no previous history for this UpgradeConfig, or if it indicates that the upgrade is New, Pending or Ongoing, the operator creates a ClusterUpgrader to either initiate a new upgrade or or maintain an ongoing upgrade.
4. The ClusterUpgrader runs through an ordered series of upgrade steps, executing them or waiting for them to complete.
   • As steps are launched or complete, they are added to the UpgradeConfig's Status History.
5. Once all steps have been completed, the upgrade is considered complete and a Status History entry is written to indicate that the UpgradeConfig has been applied.

Sample UpgradeConfig CR definition

Example 1 - OSD upgrade using to version 4.4.6 using fast channel

apiVersion: upgrade.managed.openshift.io/v1alpha1
kind: UpgradeConfig
metadata:
  name: managed-upgrade-config
spec:
  type: "OSD"
  upgradeAt: "2020-01-01T00:00:00Z"
  PDBForceDrainTimeout: 60
  capacityReservation: true
  desired:
    channel: "fast-4.4"
    version: "4.4.6"

Example 2 - OSD upgrade using to 4.7.13 using image digest

apiVersion: upgrade.managed.openshift.io/v1alpha1
kind: UpgradeConfig
metadata:
  name: managed-upgrade-config
spec:
  type: "OSD"
  upgradeAt: "2021-01-01T00:00:00Z"
  PDBForceDrainTimeout: 60
  desired:
    image: "quay.io/openshift-release-dev/ocp-release@sha256:783a2c963f35ccab38e82e6a8c7fa954c3a4551e07d2f43c06098828dd986ed4"