no matches for kind "ClusterIssuer" in version "cert-manager.io/v1"

[RobbieJVMW]

Bugs should be filed for issues encountered whilst operating cert-manager.
You should first attempt to resolve your issues through the community support
channels, e.g. Slack, in order to rule out individual configuration errors.
Please provide as much detail as possible.

Describe the bug:
Following the installation instructions for OpenShift (https://cert-manager.io/docs/installation/openshift/#login-to-your-openshift-cluster). The deployment completes successfully however kind:ClusterIssuer is not recognised.

Expected behaviour:
kind: ClusterIssuer recognised in the yaml.

Steps to reproduce the bug:
Using OpenShift 4.5.7 follow installation instructions (Option 1).

Environment details::

• Kubernetes version (e.g. v1.10.2): OpenShift 4.5.7
• Kubernetes Version: v1.18.3+2cf11e2
• Cloud-provider/provisioner (e.g. GKE, kops AWS, etc): vSphere 7
• cert-manager version (e.g. v0.4.0): v1.0
• Install method (e.g. helm or static manifests): static manifests

/kind bug

[vosuyak]

I am also getting this error when upgrading to v1.0.0
no matches for kind "ClusterIssuer" in version "cert-manager.io/v1

[meyskens]

Can you get us the output of kubectl get crd and kubectl describe crd clusterissuers.cert-manager.io?

[RobbieJVMW]

attached..
clusterissuers.txt
crd.txt

[wallrj]

@RobbieJVMW we haven't finished updating the installation instructions for OpenShift. See cert-manager/website#318

Is it possible that you've actually installed cert-manager 0.16.1? That previous version does not support the new V1 API.

[RobbieJVMW]

Sounds entirely possible - the install guide did point at a 0.16.1 .. look's like the doc has been updated. I will re-test.

[RobbieJVMW]

yes, the new doc's pointing at the 1.0 release has resolved the issue.

[vosuyak]

Sounds entirely possible - the install guide did point at a 0.16.1 .. look's like the doc has been updated. I will re-test.

Robbie please share the updated doc link, you have used to resolve this.

[RobbieJVMW]

The install guide on on cert-manager.io has been updated to link to the v1.0 deployment yaml. I didn’t need to do anything apart from re-test using the new config.

[vosuyak]

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    email: {{email}}
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-staging
    solvers:
    - http01:
        ingress:
          class: nginx

This ClusterIssuer still does not working when following steps found here:
cert-manager.io

Kube version: 1.18
Helm version: 3
Guide: Installation/Kubernetes

Error Response back:
**no matches for kind "ClusterIssuer" in version "cert-manager.io/v1"**
@wallrj

[meyskens]

@vosuyak what do you see for kubectl describe crd clusterissuers.cert-manager.io ?

[proligde]

@vosuyak Had the same problem but found out that in the newer versions when using HELM the cluster CRDs are not installed by default. It worked after uninstalling an reinstalling with:

helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --version v1.0.1 \
  --set installCRDs=true

note the --set installCRDs=true at the end.

Hope this helps.

[jnu]

@proligde I'm still running into this issue on a fresh install with helm 3.3.4 using cert-manager as a dependency:

e.g.

 > helm install my-project --set cert-manager.installCRDs=true

...

Error: unable to build kubernetes objects from release manifest: unable to recognize "": no matches for kind "ClusterIssuer" in version "cert-manager.io/v1"

From what I've read, the problem sounds like the discovery caching logic in helm3. So you can't both install CRDs and use them in a single helm install step, if installing CRDs through an ordinary template, like cert-manager does.

The recommended way of installing CRDs in helm3 is putting them in the crds/ directory -- I'm using another dependency (prometheus-operator) which does this and I'm able to install everything cleanly in one step. Is there a reason why this can't be done in the cert-manager chart?

Right now the workaround is to install my project in two separate commands - one to installCRDs for cert-manager, the other to set up my project and reference these CRDs, which is a little annoying.

[meyskens]

@jnu cert-manager as a chart dependancy will always give issues due to the Helm dependancy model.
the crds folder in Helm doesn't allow us to update the CRDs there is an open discussion to improve this on the Helm side.

[newtorob]

@RobbieJVMW we haven't finished updating the installation instructions for OpenShift. See cert-manager/website#318

Is it possible that you've actually installed cert-manager 0.16.1? That previous version does not support the new V1 API.

This was my issue. Thanks!

[JustinGuese]

@vosuyak Had the same problem but found out that in the newer versions when using HELM the cluster CRDs are not installed by default. It worked after uninstalling an reinstalling with:

helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --version v1.0.1 \
  --set installCRDs=true

note the --set installCRDs=true at the end.

Hope this helps.

this fixed it for me, deleting the cert-manager and reinstalling it using the --set installCRDs=true

[ctc24]

@proligde I'm still running into this issue on a fresh install with helm 3.3.4 using cert-manager as a dependency:

e.g.

 > helm install my-project --set cert-manager.installCRDs=true

...

Error: unable to build kubernetes objects from release manifest: unable to recognize "": no matches for kind "ClusterIssuer" in version "cert-manager.io/v1"

From what I've read, the problem sounds like the discovery caching logic in helm3. So you can't both install CRDs and use them in a single helm install step, if installing CRDs through an ordinary template, like cert-manager does.

The recommended way of installing CRDs in helm3 is putting them in the crds/ directory -- I'm using another dependency (prometheus-operator) which does this and I'm able to install everything cleanly in one step. Is there a reason why this can't be done in the cert-manager chart?

Right now the workaround is to install my project in two separate commands - one to installCRDs for cert-manager, the other to set up my project and reference these CRDs, which is a little annoying.

@jnu did you find a workaround? I'm still hitting this exact same issue.

[dvdblk]

Setting disableValidationOnInstall: true on the release that was dependent on the CRDs worked for me.

[zak905]

in this case, why not add a crd folder for the cert-manager project if this solves the issue. The crd installation can be skipped using the --skip-crds flag, so I see no need to add a installCRDs toggle as part of the chart values, unless this is for backward compatibility

[m1mohamad]

I'm having the same issue and flux keeps failing to upgrade the chart :

✗ Helm upgrade failed: unable to build kubernetes objects from current release manifest: resource mapping not found for name: "letsencrypt-dns" namespace: "" from "": no matches for kind "ClusterIssuer" in version "cert-manager.io/v1alpha2"

I'm upgrading from 0.13.0 > 1.11.1

I tried removing the CRDs before the upgrade 0.13.1

and tried installing the new CRDs but it still fails