Cert-manager: no matches for kind "ClusterIssuer" in version "certmananger.k8s.io/v1alpha2"

[vitalidn]

I am trying to follow the migration instruction
https://cert-manager.io/docs/tutorials/acme/migrating-from-kube-lego/#1-scale-down-kube-lego.

There was a problem in step 4
error: unable to recognize "cluster-issuer.yaml": no matches for kind "ClusterIssuer" in version "cert-manager.io/v1alpha2"

after execution:
kubectl create -f cluster-issuer.yaml

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
name: letsencrypt-staging
spec:
acme:
server: https://acme-v01.api.letsencrypt.org/directory
email: [email protected]
privateKeySecretRef:
name: letsencrypt-private-key
solvers:
- http01:
ingress:
class: nginx

How to fix this error?
What needs to be added in the instruction that it worked?

[meyskens]

`error: unable to recognize "cluster-issuer.yaml": no matches for kind "ClusterIssuer" in version "certmananger.k8s.io/v1alpha2"

certmananger.k8s.io/v1alpha2 should be cert-manager.io/v1alpha2 Can you double check that?

/triage support

[vitalidn]

error: unable to recognize "cluster-issuer.yaml": no matches for kind "ClusterIssuer" in version "cert-manager.io/v1alpha2"

I checked it. As shown in the file cluster-issuer.yaml.

[vitalidn]

I created a kube-lego according to the instructions:
https://github.com/jetstack/kube-lego/tree/master/examples/nginh
And according to the instructions:
https://cert-manager.io/docs/tutorials/acme/migrating-from-kube-lego/
tried to migrate.
I'm using GCP with K8S v.1.14.10-gke.36.

[meyskens]

What do you get when doing kubectl get crd ?

[rubanooo]

I'm having the same issue when installing my helm chart on GCP on kubernetes 1.16.9-gke.6.

Running kubectl get crd gives me the following:

backendconfigs.cloud.google.com                2020-06-11T11:30:48Z
capacityrequests.internal.autoscaling.k8s.io   2020-06-11T11:31:16Z
managedcertificates.networking.gke.io          2020-06-11T11:31:17Z
scalingpolicies.scalingpolicy.kope.io          2020-06-11T11:31:17Z
updateinfos.nodemanagement.gke.io              2020-06-11T11:31:17Z

[meyskens]

@rubanooo
seems you're lacking the CRDs, you need to run

# Kubernetes 1.15+
$ kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.1/cert-manager.crds.yaml

# Kubernetes <1.15
$ kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.1/cert-manager-legacy.crds.yaml

(see https://cert-manager.io/docs/installation/kubernetes/#installing-with-helm)

[rubanooo]

@meyskens I'm installing cert-manager as an helm dependency, should this not happen automatically when installing my chart? Because when I try to install my chart after installing the CRDs manually I get the following error:

Error: rendered manifests contain a resource that already exists. Unable to continue with install: CustomResourceDefinition "certificaterequests.cert-manager.io" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "production"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "default"

[winromulus]

You have a race-condition where your certificate is installed before the CRDs. Install cert-manager with CRDs enabled first and then your certificates.

[jnu]

I'm running into this issue as well with helm 3.3.4. Setting the installCRDs flag unfortunately still requires a two-step install because helm will not know the CRDs exist when it tries to use them in your chart. Sounds like this is not a race exactly, but a caching problem. Either way, it doesn't work well, so it makes me wonder what the point of installCRDs is at all?

Sorry if this has been covered already, but why isn't cert-manager just using the crds/ directory as suggested by the helm docs? requiring multiple commands for install seems to somewhat defeat the point of using helm to simplify dependency management

[perezjasonr]

[edit]
nevermind, I deleted the crds, tried again with latest chart and seems like it did create the CRDs.

[jnu]

nevermind, I deleted the crds, tried again with latest chart and seems like it did create the CRDs.

this worked with a single helm command? by latest do you mean 1.0.2?

[perezjasonr]

@jnu
yes correct, order of events was:

kubectl delete -f https://github.com/jetstack/cert-manager/releases/download/v1.0.2/cert-manager.crds.yaml

make sure crds are gone (and they were missing)

helm install cert-manager jetstack/cert-manager --namespace cert-manager --set installCRDs=true --create-namespace --version v1.0.2

and then check crds:

kubectl get crds | grep cert-manager
certificaterequests.cert-manager.io        2020-10-07T17:50:01Z
certificates.cert-manager.io               2020-10-07T17:50:01Z
challenges.acme.cert-manager.io            2020-10-07T17:50:01Z
clusterissuers.cert-manager.io             2020-10-07T17:50:01Z
issuers.cert-manager.io                    2020-10-07T17:50:01Z
orders.acme.cert-manager.io                2020-10-07T17:50:01Z

I still have no idea where the CRDs are coming from, looking at the repo. I don't see in templates area so it must be some method im not familiar with. But they were made with that arg.

[jnu]

@perezjasonr ahh ok, yes this works for me as well

I still have no idea where the CRDs are coming from, looking at the repo

The CRDs are in the repo here: https://github.com/jetstack/cert-manager/blob/master/deploy/crds/. They use bazel to build the helm chart, which puts these CRD templates get put into the chart's templates/ directory with the other templates.

I'm still having a slightly different problem, though, which is in trying to use cert-manager as a helm dependency in a new chart I've written.

Seems that the dependency problem is that 1) helm doesn't know how to install _and use_ crds in a single step when installed from a subchart's templates/ directory, 2) helm doesn't allow you to use templates in the crds/ directory (which is their recommended way of installing CRDs -- I use prometheus-operator as a dependency which installs crds this way and it works fine in a single step), but 3) cert-manager's CRDs really are templates - their definitions reference values from the manifest.

I guess what I don't understand is why the CRDs need to be templates at all -- can't they be written in a way that any values from the manifest are passed to the _use_ of the CRD and not the definition of the CRD itself?

[BuckinghamIO]

I've also tried to use cert-manager as a sub chart and the same issue occurs on v1.0.2 and below also.

The chart does not seem to respect a top level value of --set cert-manager.installCRDs=true or --set installCRDs=true so I'm having to run a 2 step install which is annoying and feels clunky.

[meyskens]

I guess what I don't understand is why the CRDs need to be templates at all -- can't they be written in a way that any values from the manifest are passed to the use of the CRD and not the definition of the CRD itself?

This is the reason: https://github.com/helm/helm/issues/7735

I've also tried to use cert-manager as a sub chart and the same issue occurs on v1.0.2 and below also.

Our chart does not support being installed as a sub-chart, as it manages cluster wide resources this would be a bad idea.