Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT
Version of Helm and Kubernetes:
Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
Which chart:
stable/cert-manager v0.6.0
What happened:
New install fails with "validation error"
validation failed: [unable to recognize "": no matches for kind "Certificate" in version "certmanager.k8s.io/v1alpha1", unable to recognize "": no matches for kind "Certificate" in version "certmanager.k8s.io/v1alpha1", unable to recognize "": no matches for kind "Issuer" in version "certmanager.k8s.io/v1alpha1", unable to recognize "": no matches for kind "Issuer" in version "certmanager.k8s.io/v1alpha1"]
What you expected to happen:
Successful install without additional options.
How to reproduce it (as minimally and precisely as possible):
helm install stable/cert-manager --name cert-manager --namespace kube-system --version v0.6.0
Anything else we need to know:
This is a new install of cert-manager, not an upgrade.
I am getting the same issue. Running on AKS brand new cluster.
Seems with the new release you have to run this first.
$ kubectl apply \
-f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.6/deploy/manifests/00-crds.yaml
@PixelRobots Thanks for the update, was having the same issue.
I feel that requiring a user to apply a static manifest outside of the helm workflow is at best a workaround for this issue, not a solution.
I'm trying to install Rancher on windows using this guide: https://rancher.com/blog/2018/2018-05-18-how-to-run-rancher-2-0-on-your-desktop/
I am resting the kubernetes cluster before running the tutorial.
Command that fails:
helm install stable/cert-manager --name cert-manager --namespace kube-system --wait
Result of helm ls --all cert-manager:
cert-manager 1 Tue Jan 29 16:46:56 2019 FAILED cert-manager-v0.6.0 v0.6.0 kube-system
After more debug i get this message (same as @jgreat)
validation failed: [unable to recognize "": no matches for kind "Certificate" in version "certmanager.k8s.io/v1alpha1", unable to recognize "": no matches for kind "Certificate" in version "certmanager.k8s.io/v1alpha1", unable to recognize "": no matches for kind "Issuer" in version "certmanager.k8s.io/v1alpha1", unable to recognize "": no matches for kind "Issuer" in version "certmanager.k8s.io/v1alpha1"]
Can i use @PixelRobots workaround and how?
@danpette For the time being we are updating our instructions to pin the cert-manager version to v0.5.2.
helm install stable/cert-manager \
--name cert-manager \
--namespace kube-system \
--version v0.5.2
@jgreat Thanks, that worked.
@jgreat Thank you, it worked for me too.
Using the createCustomResource chart value installed the CRDs during a fresh install of cert-manager.
helm install stable/cert-manager --name cert-manager --namespace kube-system --version v0.6.0 --set createCustomResource=true
Using the
createCustomResourcechart value installed the CRDs during a fresh install of cert-manager.
helm install stable/cert-manager --name cert-manager --namespace kube-system --version v0.6.0 --set createCustomResource=true
Error: customresourcedefinitions.apiextensions.k8s.io "certificates.certmanager.k8s.io" already exists
Using the
createCustomResourcechart value installed the CRDs during a fresh install of cert-manager.
helm install stable/cert-manager --name cert-manager --namespace kube-system --version v0.6.0 --set createCustomResource=trueError: customresourcedefinitions.apiextensions.k8s.io "certificates.certmanager.k8s.io" already exists
I am getting error it already exist but in case I deploy in another name space its giving web hook error
@pikvik After I posted my comment here about using createCustomResource I believe that chart value is not documented because it is no longer intended to be used. The intent is to install the custom resource definitions (CRDs) prior to installing the Helm chart, as described in the installation document. However, I believe your Error: customresourcedefinitions.apiextensions.k8s.io "certificates.certmanager.k8s.io" already exists is caused by the custom resource definitions (CRDs) already being installed from a past installation of cert-manager. IF you have had cert-manager installed on your cluster already, and especially if you have existing certificates, see the upgrade documentation which describes upgrading from different versions of cert-manager, and backing up certificate and other objects.
Regarding your web hook error when installing into a different namespace, you may be missing the label on that namespace that disables validation - see the troubleshooting document for more detail.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.
Any maintainers from cert-manager available to comment on this issue? @munnerz @simonswine @kragniz
It would be really great if there was some guidance on how to use this chart without applying additional manifests outside the helm workflow.
Are there guidelines for helm charts? This does not appear to be setup correctly as helm install stable/cert-manager will always fail.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.
Any maintainers from cert-manager available to comment on this issue? @munnerz @simonswine @kragniz
It would be really great if there was some guidance on how to use this chart without applying additional manifests outside the helm workflow.
Just to satisfy my own curiousity I'd like to know the answer to this too. It seems like a lot of people are using an older version of cert-manager mainly so they can avoid applying manifests manually. Why has this changed? Why can't cert-manager be installed solely via helm anymore? I'm assuming this is due to a design change that hasn't been integrated with the existing Helm charts but it would be good to have some clarification on this.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.
This issue is being automatically closed due to inactivity.
This is still a problem
This is still a problem. Please reopen.
/remove-lifecycle stale
@woodcockjosh @demisx The comments above indicate (as does the official cert-manager Helm chart, which has moved to its own repository at jetstack/cert-manager BTW) that the CRDs need to be manually installed. Unless you know something we don't, I'm not sure if they're working on making the CRD integration with the Helm chart.
@sc250024 the question we're trying to get answered is _why_ the CRDs were removed from the Helm chart in the first place. If the CRDs are only installed for cert-manager, they should be a part of the chart. Likewise if you want to remove cert-manager, you should be able to do so using Helm and have it clear up all of the CRDs.
If it was an architectural decision and it has to be done this way going forward we would at least like to know why that is, because it doesn't really seem logical from the outside.
@sc250024 the fact that a crappy requirement to manually install CRDs is communicated doesn't make the user experience any less crappy. Instead of just deleting the CRDs from the templates they can at least be put back with a flag that disables them so that people who want to have a good user experience and install them along with the rest of the templates can do so. There is basically this idea that you must install some things or parts of the chart separately which I think defeats the whole purpose for having a package manager.
The workaround is that I have to wrap the chart in another chart that adds the CRD's back. Pretty silly if you ask me.
@woodcockjosh my sentiments exactly 馃挴
@woodcockjosh @rudolphjacksonm Actually the manual CRD process is / was not uncommon. The Prometheus Operator project also does the same (https://hub.helm.sh/charts/stable/prometheus-operator). The reason why that chart (and probably this one too) implemented the fix was most likely because of this bug => https://github.com/helm/helm/pull/5112.
Not cleaning up CRD resources automatically actually makes sense in certain cases because, in the case of cert-manager, a user might not necessarily want to delete their Certificate resources or ClusterIssuer resources just because they uninstall cert-manager itself.
My point was, this issue is not the place to vent these frustrations because:
A.) The issue is closed
B.) JetStack now manages the chart elsewhere (https://github.com/jetstack/cert-manager)
With that said, calmness should ensue.
@sc250024 not a problem. I think it's time to put the CRD's back now that the issue is resolved.
so... PR to add the CRDs back? Jetstack can continue doing it the painful way in their own repository
For anyone coming along this months down the line, I've added a few notes as to why we (and many other operators) choose not to include CRDs as part of the Helm chart here: https://github.com/jetstack/cert-manager/issues/2330#issuecomment-559582511
Please let's not continue discussion in this issue, as it is closed and not likely to gain much traction (plus the chart is not maintained in this repository, and has not been for almost a year now!)
Thanks for the explanation @munnerz , much appreciated 馃挴
Most helpful comment
I am getting the same issue. Running on AKS brand new cluster.
Seems with the new release you have to run this first.
IMPORTANT: you MUST install the cert-manager CRDs before installing the
cert-manager Helm chart
$ kubectl apply \
-f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.6/deploy/manifests/00-crds.yaml