Cluster API Operator supports four lifecycles for a Provider. If you have managed a Provider in a Bootstrap cluster using clusterctl you are already familiar with them. If not let’s dive into the details.

Before we dive into the lifecycle let’s check what Cluster API Operator reconcile loop looks like

Provider Reconcile Loop Representation

Provider loop is gated by the Provider & ConfigSecret object hash which is a combined hash from Provider.Spec and ConfigSecret.Data acts as the first gate to detect changes in specification.

If a change is detected a loop is allowed to execute each Phase. Let’s take a deeper look into each phase and what it means in a reconcile loop.

Preflight

is a set a sanity checks performed before preparing for installing a Provider. Let’s see all the checks that are ensured in a preflight run

A variety of Preflight checks are run before each reconcile loop

Download. Load. Fetch

installs or fetches the Provider manifest from fetchConfiguration and prepares a rendered output after env substitution and patches etc.

Upgrade. Install

are self-explanatory as they either install the given Provider or help upgrade it.

Report Status

is a very generic part of every reconciler-based operator where Custom Resource is updated.

Now that we have covered reconciliation and its phases in Cluster API Operator. Let’s dive into the Lifecycle phases

Install

Installing Providers is an essential first step for your Bootstrap Cluster

• install — allows users to get started and set up a Bootstrap cluster by letting them install the provided component. If component fetchconfiguration is missing default Provider list from CAPI is used.

Upgrade

Rapid development cycle for CAPI projects leads to very frequent releases for Providers

• upgrade — allows user to upgrade Provider release version by changing the release version and manifest details. Custom Resource Definitions and Custom Resources are not destroyed during this operation. Upgrade here is similar to clusterctl based Provider upgrade.
  Given the fast release cycle among Cluster API and Cluster API Providers, project users will often find themselves in need of upgrading a Provider, it might have a security patch or your latest desired feature available.

Update

Updating a Provider is a day-to-day activity to enable debug profile or rotate credentials

• update — allows users to modify installed Provider for uses like modifying controller arguments, and changing/rotating configSecret values.
  Users who interact with Bootstrap clusters will find in times for need to change the Provider controller manager, say your Bootstrap cluster is now managing hundreds of AWSClusters and you want to increase concurrent reconciles count. Or you want to enable the profiler on your controller. And the most practical use case that you will encounter is rotating the credentials for a Provider.

Delete

Deleting a Provider is a cautionary step, users should proceed with care

• delete — allows to uninstall a Provider from a Bootstrap Cluster. I think users will seldom use this option either to uninstall a messed up provider or dismantle Bootstrap clusters.

This concludes our 4 articles in this series now we have a very good understanding of how the Cluster API Operator project is structured, how the Custom Resources are exposed and internal details as to how Cluster API Operator works. All these foundations set us to a smooth experience.

In the next article, we will use the Flux CD Git Ops solution to ensure a cluster similar to what we have prepared in our first article.