Shulou(Shulou.com)05/31 Report--

How to upgrade cert-manager smoothly and gracefully in Rancher 2.x, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can get something.

If you are using Helm Chart provided by Rancher to install cert-manager in a Kubernetes cluster managed by Rancher, you may have received a reminder from Let's Encrypt recently:

Check the cert-manager log in the cluster and you can see that Let's Encrypt rejects the request to update the certificate because "your ACME client version is too old, please upgrade to a newer version". So, let's start now!

Update with Helm Chart provided by Rancher

I think the first thought in your mind should be similar to mine: upgrade cert-manager with the relevant latest version of Helm Chart. You don't have to think about this option, because the latest version of cert-manager Helm Chart provided by Rancher is version 0.5.2, so don't think about one-click upgrade!

Upgrade using the official Helm Chart

Reference link: https://forums.rancher.com/t/update-on-cert-manager-application-in-the-catalog/15598

The plan is simple: just remove the Helm Chart of the cert-manager provided by Rancher and replace it with the chart maintained by Jetstack in Helm.

We need to be cautious before we begin. From v0.5.2 to the current version of stable v0.11.0, a lot of things have changed. The newly introduced CRDs and the corresponding configuration format will have a profound impact on your deployment. Therefore, after the update upgrade, you need to update the resource definition to the new format. Fortunately, cert-manager provides us with an upgrade script, which we will use later.

Remove Helm Chart provided by Rancher

1. Log in to your Rancher UI

2. Switch to the project where cert-manager was originally installed (possibly System)

3. Click "APPs"

4. Click the vertical ellipsis button, and then select "Delete".

Now you have removed the original installation of cert-manager. Please note that this action will not affect the previously created certificate, and your ingress configuration should work as before.

Install Tiller

Tiller is a server-side component of Helm, so in order to use Helm in our CLI, we need to install Tiller in the Kubernetes cluster. You can verify that Tiller is installed by running the following command:

Helm version

If your output is similar to the above, then Tiller is not installed. If you have completed the installation, please skip this section.

OK, now let's install Tiller. First, we need to create a service account that gives us permission to install Tiller remotely, and then to install Chart.

Kubectl-n kube-system create serviceaccount tillerkubectl create clusterrolebinding tiller\-- clusterrole=cluster-admin\-- serviceaccount=kube-system:tiller

To start the installation of Tiller:

Helm init-service-account tiller

After a few seconds, you can verify that Tiller is installed by re-entering the command helm version, or verify your Kubernetes Tiller deployment with the following command:

Kubectl-n kube-system rollout status deploy/tiller-deploy:

Install cert-manager

Before installing cert-manager, we need to make the following preparations:

1. Disable resource verification to allow the webhook component of cert-manager to work properly

2. Install the new (v0.11.1) CRDs

3. Add Jetstack repos

Kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=truekubectl apply-validate=false-f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.11/deploy/manifests/00-crds.yamlhelm repo add jetstack https://charts.jetstack.io & & helm update

At this point, we are ready to install and verify cert-manager

Helm install\-name cert-manager\-namespace cert-manager\-version v0.11.0\ jetstack/cert-managerkubectl get pods-namespace cert-manager

Cert-manager v0.11.0 installed successfully

Upgrade old resource references and configurations

Reference link:

Https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/

If you check your ingress certificate, you will find that nothing has changed. This is to be expected because the ingress-defined configuration used in the previous version v0.5.2 does not apply to v0.11.0. Cert-manager provides us with simple code to find out which cluster resource still references the old comment:

Kubectl get ingress\-all-namespaces\-o json |\ jq '.items [] | select (.metadata.annotations | to_entries | map (.key) [] | test ("certmanager")) | "Ingress resource\ (.metadata.namespace) /\ (.metadata.namespace) contains old annotations: (\ (.metadata.annotations | to_entries | map (.key) [] | select (. | test (" certmanager ")

Depending on the number of Kubernetes cluster deployments, the above list may be shorter or longer. It can take a long time to try to manually change the old comments for all deployments. The following CLI tool automates this process, but it doesn't make any changes to your cluster:

# first, download the binary file wget-O api-migration https://github.com/jetstack/cert-manager/releases/download/v0.11.0/api-migration-linux# according to your platform or mark the binary file as executable according to Darwinwget-O api-migration https://github.com/jetstack/cert-manager/releases/download/v0.11.0/api-migration-darwin# Then run the binary file chmod + x api-migration & &. / api-migration-- kubeconfig / path/to/my/kubeconfig.yaml# on the cluster to see the output of CLI and check the difference diff ingress.yaml ingress-migrated.yaml# in the file. Finally, after review the new ingress resources, apply manifestkubectl apply-f ingress-migrated.yaml-- kubeconfig / path/to/my/kubeconfig.yaml

Be sure to update all Ingress resources to ensure that your certificate is up to date.

Reintroduce cluster Issuer

We are almost done now, and the final step is that we need to reintroduce the cluster Issuer (if you only want to change the kind annotation to Issuer, you can also choose the Issuer for each namespace).

Create two cluster Issuer using Let's Encrypt stage and Production and HTTP01. The following is a code summary:

-apiVersion: cert-manager.io/v1alpha2kind: ClusterIssuermetadata: name: letsencrypt-stagingspec: acme: email: example@example.com server: https://acme-staging-v02.api.letsencrypt.org/directory privateKeySecretRef: name: letsencrypt-staging-account-key solvers:-http01: ingress: class: nginx---apiVersion: cert-manager.io/v1alpha2kind: ClusterIssuermetadata: name: letsencrypt-prodspec: acme: email: Example@example.com server: https://acme-v02.api.letsencrypt.org/directory privateKeySecretRef: name: letsencrypt-prod-account-key solvers:-http01: ingress: class: nginx

After a minute or two, all your ingress will be updated to point to the newly issued certificate. But keep in mind that if your previous certificate is not in the renewal window, you will not find any difference. For Rancher's own applications, cert-manager supports a maximum version of v0.9. If it is a self-owned application service, it can support the latest version. Due to well-known reasons, the use of cert-manager is not recommended in China, and a self-signed certificate with a validity period of 10 years is recommended.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.