Operator Lifecycle Manager

Installation managed by OLM

Prerequisites

Install a supported version of Kubernetes or OpenShift.
Read Compatibility with Kubernetes Platform Providers if you are using Kubernetes on a cloud platform.

Option 1: Installing from OperatorHub Web Console on OpenShift

cert-manager is in the Red Hat-provided Operator catalog called "community-operators". On OpenShift 4 you can install cert-manager from the OperatorHub web console or from the command line. These installation methods are described in Red Hat's Adding Operators to a cluster documentation.

⚠️ In cert-manager 1.10 the secure computing (seccomp) profile for all the Pods is set to RuntimeDefault. On some versions and configurations of OpenShift this can cause the Pod to be rejected by the Security Context Constraints admission webhook.

📖 Read the Breaking Changes section in the 1.10 release notes before installing or upgrading from an older version to 1.10 or newer.

Option 2: Installing from OperatorHub.io

Browse to the cert-manager page on OperatorHub.io, click the "Install" button and follow the installation instructions.

Option 3: Manual install via `kubectl operator` plugin

Install OLM and install the kubectl operator plugin from the Krew Kubectl plugins index and then use that to install the cert-manager as follows:

operator-sdk olm install
kubectl krew install operator
kubectl create ns cert-manager
kubectl operator install cert-manager -n cert-manager --channel stable --approval Automatic --create-operator-group

You can monitor the progress of the installation as follows:

kubectl get events -w -n operators

And you can see the status of the installation with:

kubectl operator list

Release Channels

Whichever installation method you chose, there will now be an OLM Subscription resource for cert-manager, tracking the "stable" release channel. E.g.

$ kubectl get subscription cert-manager -n operators -o yaml
...
spec:
  channel: stable
  installPlanApproval: Automatic
  name: cert-manager
...
status:
  currentCSV: cert-manager.v1.14.5
  state: AtLatestKnown
...

This means that OLM will discover new cert-manager releases in the stable channel, and, depending on the Subscription settings it will upgrade cert-manager automatically, when new releases become available. Read Manually Approving Upgrades via Subscriptions for information about automatic and manual upgrades.

NOTE: There is a single release channel called "stable" which will contain all cert-manager releases, shortly after they are released. In future we may introduce other release channels with alternative release schedules, in accordance with OLM's Recommended Channel Naming.

Debugging installation issues

If you have any issues with your installation, please refer to the FAQ.

Configuration

The configuration options are quite limited when you install cert-manager using OLM. There are a few Deployment settings which can be overridden permanently in the Subscription and most other elements of the cert-manager manifests can be changed by editing the ClusterServiceVersion, but changes to the ClusterServiceVersion are temporary and will be lost if OLM upgrades cert-manager, because an upgrade results in a new ClusterServiceVersion resource.

Configuration Via Subscription

When you create an OLM Subscription you can override some of the cert-manager Deployment settings, but the options are quite limited. The configuration which you add to the Subscription will be applied immediately to the current cert-manager Deployments. It will also be re-applied if OLM upgrades cert-manager.

🔰 Read the Configuring Operators deployed by OLM design doc in the OLM repository.

🔰 Refer to the Subscription API documentation.

Here are some examples of configuration that can be achieved by modifying the Subscription resource. In each case we assume that you are starting with the following default Subscription from OperatorHub.io:

# cert-manager.yaml
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: my-cert-manager
  namespace: operators
spec:
  channel: stable
  name: cert-manager
  source: operatorhubio-catalog
  sourceNamespace: olm

kubectl create -f https://operatorhub.io/install/cert-manager.yaml

Change the Resource Requests and Limits

It is possible to change the resource requests and limits by adding a config stanza to the Subscription:

# resources-patch.yaml
spec:
  config:
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

kubectl -n operators patch subscription my-cert-manager --type merge --patch-file resources-patch.yaml

You will see all the cert-manager Pods are restarted with the new resources:

$ kubectl -n operators get pods -o "custom-columns=name:.metadata.name,mem:.spec.containers[*].resources"
name                                       mem
cert-manager-669867589c-n8dcn              map[limits:map[cpu:500m memory:128Mi] requests:map[cpu:250m memory:100Mi]]
cert-manager-cainjector-7b7fff8b9c-dxw6b   map[limits:map[cpu:500m memory:128Mi] requests:map[cpu:250m memory:100Mi]]
cert-manager-webhook-975bc87b5-tqdj4       map[limits:map[cpu:500m memory:128Mi] requests:map[cpu:250m memory:100Mi]]

⚠️ This configuration will apply to all the cert-manager Deployments. This is a known limitation of OLM which does not support configuration of individual Deployments.

Change the NodeSelector

It is possible to change the nodeSelector for cert-manager Pods by adding the following stanza to the Subscription:

# nodeselector-patch.yaml
spec:
  config:
    nodeSelector:
      kubernetes.io/arch: amd64

kubectl -n operators patch subscription my-cert-manager --type merge --patch-file nodeselector-patch.yaml

You will see all the cert-manager Pods are restarted with the new nodeSelector:

$ kubectl -n operators get pods -o "custom-columns=name:.metadata.name,nodeselector:.spec.nodeSelector"
name                                      nodeselector
cert-manager-5b6b8f7d74-k7l94             map[kubernetes.io/arch:amd64 kubernetes.io/os:linux]
cert-manager-cainjector-b89cd6f46-kdkk2   map[kubernetes.io/arch:amd64 kubernetes.io/os:linux]
cert-manager-webhook-8464bc7cc8-64b4w     map[kubernetes.io/arch:amd64 kubernetes.io/os:linux]

⚠️ This configuration will apply to all the cert-manager Deployments. This is a known limitation of OLM which does not support configuration of individual Deployments.

Configuration Via ClusterServiceVersion (CSV)

The ClusterServiceVersion (CSV) resource contains the templates for all the cert-manager Deployments. If you patch these templates, OLM will immediately roll out the changes to the Deployments.

⚠️ If OLM upgrades cert-manager your changes will be lost because it will create a new CSV with default Deployment templates.

Nevertheless, editing (patching) the CSV can be a useful way to override certain cert-manager settings. An example:

Change the log level of cert-manager components

The following JSON patch will append -v=6 to command line arguments of the cert-manager controller-manager (the first container of the first Deployment).

kubectl patch csv cert-manager.v1.14.5 \
  --type json \
  -p '[{"op": "add", "path": "/spec/install/spec/deployments/0/spec/template/spec/containers/0/args/-", "value": "-v=6" }]'

You will see the controller-manager Pod is restarted with the new arguments.

$ kubectl  -n operators get pods -o "custom-columns=name:.metadata.name,args:.spec.containers[0].args"
name                                      args
cert-manager-797979cbdb-g444r             [-v=2 --cluster-resource-namespace=$(POD_NAMESPACE) --leader-election-namespace=kube-system -v=6]
...

🔰 Refer to the ClusterServiceVersion API documentation.

Uninstall

Below is the processes for uninstalling cert-manager on OpenShift.

⚠️ To uninstall cert-manager you should always use the same process for installing but in reverse. Deviating from the following process can cause issues and potentially broken states. Please ensure you follow the below steps when uninstalling to prevent this happening.