Lifecycle Manager
How the platform knows which version of each of its parts runs, where new versions come from, and how an upgrade is planned, checked, rolled out and finished.
The Lifecycle Manager shows which version of each part of the platform is running, which
newer versions exist, and upgrades them. Platform administrators find it under
Settings → Lifecycle Manager in the sidebar, and on the Admin page. Opening it needs
lifecycle/view at the platform root, which Platform Owner, Platform Contributor and Platform
Reader hold; everything that changes something needs more — see
Permissions.
The page has four tabs: Components, Dependencies, Rollouts and After upgrading.
Components
A component is one part of the platform that is versioned and upgraded on its own:
| Kind, as the page shows it | What it is |
|---|---|
| Platform Core | The platform API |
| Platform Operator | The operator that runs in the cluster and carries out rollouts |
| Platform Portal | The portal |
| Service Orchestrator | A backend module, such as Apps, Secrets or Lifecycle itself |
| Component Definitions | The bundle of the platform's custom resource definitions (CRDs) |
| Dependency | A third-party Helm chart the platform runs on, such as cert-manager or CloudNativePG |
| Platform step (installer) | The installer of a platform release, run as a step of a release rollout |
The Components tab lists every component except the dependencies, which have a tab of their own. For each it shows the running version, the newest release, its health and when it last changed. The platform watches its own Deployments continuously, so what the tab shows is what runs in the cluster, not what was last requested.
Releases
New versions come from a release feed: a signed list of platform releases that the platform reads about once an hour, and whenever you choose Check for updates. A platform release is a named set of component versions. Every image in it is pinned by digest and every bundle by checksum, so a rollout installs exactly what the release names. How the feed is read, verified and configured is described in Releases and the release feed.
The version of the CRD bundle names the platform release: once a rollout has applied a release's bundle, the platform reports that release as its own version.
Rollouts
An upgrade is a rollout. You choose components and the versions to take them to; the platform turns that into a plan, orders it into batches — third-party charts first, then the CRD bundle, then the release's installer, then the platform's own components in dependency order — and checks it. When you execute it, the operator rolls one batch at a time and checks each component's health before it starts the next. A rollout that runs into trouble pauses rather than carrying on, and waits for you to resume, cancel or later roll it back; a batch that runs out of time ends it as failed.
Only one rollout runs at a time, across the whole platform. See Upgrade the platform.
Pre-upgrade checks
Before a rollout starts, the platform checks that the platform and the cluster are fit for it: components healthy, identity provider and database answering, images pullable, the cluster objects the release needs in place. A warning never stops a rollout; a failure has to be overridden deliberately, and a few failures cannot be overridden at all. Every check is listed in Pre-upgrade checks.
Drift
Drift is the difference between what the platform's records say and what the cluster runs. The Lifecycle Manager reports two kinds:
- Components that differ from their record — a platform image no component accounts for, a third-party chart that is no longer the version the last rollout applied, or Kubernetes permissions the running release declares but the cluster does not hold yet. These are warnings on the Components and Dependencies tabs; see Statuses.
- Platform settings changed by hand — fields of the platform's own cluster objects that someone edited directly in the cluster. The platform scans for them regularly, and the next release rollout stops before overwriting them. See Settings changed by hand.
After upgrading
Some upgrades end with a step the platform cannot take for itself, because it would mean the platform granting itself rights. The After upgrading tab collects them, and a reminder appears at the top of every page until they are done. See After upgrading.
Installing a component
An optional backend module that was not installed with the platform can be installed later from the Components tab — see Install a component. Changing the version of a component that is already installed is always a rollout.
Platform backups
The platform's own backups — where they go, when they run, and whether they worked — are part of the same module, under Settings → Backups. See Platform backups.