[clusterctl] Manage the cert-manager lifecycle

[fabriziopandini]

User Story

As an operator, I would like to get the cert-manager lifecycle managed by clusterctl

Detailed Description

The cert-manager manifest is embedded in clusterctl, so we can provide a better Day 1 experience.

However, this comes with some downsides, like e.g the fact that the manifest cannot be easily changed, and most important in the long term, there is not yet a well-defined upgrade path for cert-manager.

It should be noted that upgrading cert-manager most probably requires also additional code changes like e.g. the wait-for-cert manager loop should adapt to the new manifest.

I see few options here:

1. clusterctl should be improved to manage the cert-manager version according to the cluster-api version + continue to have the cert-manager manifest is embedded in clusterctl
   When upgrading to a cluster-api version that requires a new cert-manager version, in order to do upgrades it is required to install a new version of clusterctl (with the new manifest/with the new wait-for-cert manager loop)
2. clusterctl should be improved to manage the cert-manager version according to the cluster-api version + add the cert-manager manifest as part of the clusterctl bundle (instead of having it embedded in the binary)
   When upgrading to a cluster-api version that requires a new cert-manager version, the new cert-manager manifest will be fetched together with the other YAML manifests. TBD how to manage the new wait-for-cert manager loop.
3. split the cert-manager lifecycle from the cluster-api lifecycle
   This probably requires to review the day 1 workflow as well

Anything else you would like to add:

#2558 introduced the possibility to override images in the cert-manager, but this was designed to address air-gapped use cases, not upgrades. However, it can be used as a workaround only for patch upgrades where only the image number is changed.

Similarly, #2566 discuss if/how to allow to change the overriding image for cert-manager after init, but also this does not address upgrades (same as above).

/kind feature

[fabriziopandini]

/area clusterctl

[wfernandes]

Commenting on this issue so I can be in the loop. This looks like a lot of work and I would like to help out where ever I can 🙂

[wfernandes]

Referencing this issue #2934 here as it may be relevant when we design this out.

[wfernandes]

Referencing this issue #3033 here as it may be relevant when we design this out.

[vincepri]

/milestone v0.3.9

This will be at least partially fixed by #3313 #3364.

On a separate note, in the future we'll need to update the cert-manager resources we ship with Cluster API

[wfernandes]

@vincepri Should we close this issue since #3313 and #3364 have been merged in? It seems that any other work for management of cert-manager lifecycle would probably fall under v0.4.x. WDYT?

[vincepri]

SGTM 👍

[fabriziopandini]

/close

[k8s-ci-robot]

@fabriziopandini: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.