Upgrade cert-manager to version 1.0+

[Megian]

Context

The current used version 0.15.1 does not support the API version cert-manager.io/v1. This causes as long as we don't upgrade, all new objects use an outdated API version and have to be migrated later. Therefore it would make much sense to rise the version to 1.0+, which makes the current API version available cert-manager/cert-manager#3177.

Alternatives

I think there is not an alternative to it long term.

[Sebastian Widmer]

Breaking changes from v0.15.1 to v1.4.0 from cert-manager

https://github.com/jetstack/cert-manager/releases/tag/v0.16.0

• Support for AuditSink resources in the auditregistration.k8s.io/v1alpha1 API group has been removed

https://github.com/jetstack/cert-manager/releases/tag/v1.2.0

• The minimum supported Kubernetes version is now v1.16.0 as of cert-manager v1.2.0. Users still running Kubernetes v1.15 or below should upgrade to a supported version before installing cert-manager or use cert-manager v1.1.
• The User-Agent request header sent by cert-manager has changed to reflect the ownership transfer to the CNCF
• The --renew-before-expiration-duration flag of the cert-manager controller-manager has been deprecated. Please set the Certificate.Spec.RenewBefore field instead. This flag will be removed in the next release.
  Certificates issued by the Vault issuer have changed — the root CA instead of the issuing CA is now stored in ca.cr

https://github.com/jetstack/cert-manager/releases/tag/v1.3.0

• CertificateRequests are now immutable - the spec and metadata.annotations fields cannot be changed after creation. They were always designed to be immutable but this behavior is now enforced by the cert-manager webhook.
• This release updates the Venafi Cloud Issuer to use OutagePREDICT instead of DevOpsACCELERATE.

https://github.com/jetstack/cert-manager/releases/tag/v1.4.0

• The CA issuer now attempts to store the root CA instead of the issuing CA into the ca.crt field for issued certificates; this is a change of behavior. All of the information which was previously available is still available: the intermediate should appear as part of the chain in tls.crt.
• RunAsNonRoot is now enabled by default in the securityContext values. If you're using custom containers with the chart that run as root, you will need to set this back to false.

[Sebastian Widmer]

Tried upgrading to v1.4.0. The CRDs do not apply: CustomResourceDefinition.apiextensions.k8s.io "certificates.cert-manager.io" is invalid: spec.conversion.strategy: Invalid value: "Webhook": must be None if spec.preserveUnknownFields is true

We had to manually remove preserveUnknownFields: true from the existing CRDs so spec.conversion.strategy: "Webhook" is allowed.

[Sebastian Widmer]

Experimenting with patch

❯ kubectl patch crd certificates.cert-manager.io --type=json -p='[{"op": "remove", "path": "/spec/preserveUnknownFields"}]'
The CustomResourceDefinition "certificates.cert-manager.io" is invalid: spec.validation.openAPIV3Schema.type: Required value: must not be empty at the root

❯ kubectl patch crd certificates.cert-manager.io --type=json -p='[{"op": "replace", "path": "/spec/preserveUnknownFields", "value": false}]'       
The CustomResourceDefinition "certificates.cert-manager.io" is invalid: spec.validation.openAPIV3Schema.type: Required value: must not be empty at the root

[Chris]

Hm, how does it work if you try it via kubectl apply instead?
e.g. k get crd ... -o yaml > file.yml, then cleanup the metadata in the yaml similar to https://k8up.io/k8up/1.1.0/how-tos/upgrade.html#_install_1_x with yq, then apply again?

[Sebastian Widmer]

Hm, how does it work if you try it via kubectl apply instead?
e.g. k get crd ... -o yaml > file.yml, then cleanup the metadata in the yaml similar to https://k8up.io/k8up/1.1.0/how-tos/upgrade.html#_install_1_x with yq, then apply again?

Tried now and it works splendid 😊

❯ cat <<'EOF' > cert-manager-prepare-merge-crds.sh
#!/bin/sh

set -euo pipefail

for crd in certificaterequests.cert-manager.io certificates.cert-manager.io challenges.acme.cert-manager.io clusterissuers.cert-manager.io issuers.cert-manager.io orders.acme.cert-manager.io; do
  # Get CRD definition in YAML
  kubectl get crd "${crd}" -o yaml > "${crd}.yaml"
  # Remove all metadata properties except `metadata.name`
  yq -i eval 'del(.status) | del(.metadata) | .metadata.name += "'${crd}'"' "${crd}.yaml"
  # Apply the CRD again (this shouldn't change anything, except adding the annotation "kubectl.kubernetes.io/last-applied-configuration")
  # You will also see some warnings in the output mentioning the annotation.
  # This is expected and actually required.
  kubectl apply -f "${crd}.yaml"
done
EOF

❯ sh cert-manager-prepare-merge-crds.sh
customresourcedefinition.apiextensions.k8s.io/certificaterequests.cert-manager.io configured
customresourcedefinition.apiextensions.k8s.io/certificates.cert-manager.io configured
customresourcedefinition.apiextensions.k8s.io/challenges.acme.cert-manager.io configured
customresourcedefinition.apiextensions.k8s.io/clusterissuers.cert-manager.io configured
customresourcedefinition.apiextensions.k8s.io/issuers.cert-manager.io configured
customresourcedefinition.apiextensions.k8s.io/orders.acme.cert-manager.io configured

🦑 Argo is happily syncing and creation timestamp stays the same.

❯ kubectl get crd certificates.cert-manager.io -ojsonpath='{.metadata.creationTimestamp}'
2020-08-24T13:03:08Z
❯ kubectl get crd issuers.cert-manager.io -ojsonpath='{.metadata.creationTimestamp}'
2020-08-24T13:03:09Z

[Chris]

Interesting! But I don't see the preserveUnknownFields property removed in your script? does it get removed?

[Sebastian Widmer]

This baffled me too after our debug session yesterday. It works without modifying preserveUnknownFields. An updated "kubectl.kubernetes.io/last-applied-configuration" seems to be enough for kubectl to successfully apply the changes.

[Sebastian Widmer]

Auto-upgrade still pending #18.

[Sebastian Widmer]

#18 was merged.