Support for 1.15+ cert-manager resources
ledsole opened this issue · comments
I received the following while testing this out:
$ helm install designate-certmanager --namespace=cert-manager designate-certmanager-webhook
Error: failed to download "designate-certmanager-webhook" (hint: running helm repo update may help)
I'm running kubernetes 1.17 with the following crds:
https://github.com/jetstack/cert-manager/releases/download/v0.15.1/cert-manager.crds.yaml
I suspect this is looking for the legacy crds?
EDIT: I pasted the wrong error above. The error I was actually getting was due the naming change that ocurred in cert-manager crds v0.11.0
Did you clone the repository first ? This chart is not part of the official helm charts. Looking at the error message. I would say that the repository is missing.
This should do the trick:
For now, we do not host a chart repository. To use this chart, you must clone this repository. Edit the values.yaml file and add your OpenStack settings if you did not create the secret before. Then you can install the helm chart with the command:
helm install --name designate-certmanager --namespace=cert-manager designate-certmanager-webhook
So I got it to install and it sees my openstack credentials and designate endpoint. However, when I try to issue a certificate, the challenge get stuck in a pending state and I get the following:
"error"="the server is currently unable to handle the request (post designatedns.acme.syseleven.de)"
I think this might be due to my version of cert-manager/kubernetes. @frittenlab What is the latest version that this will work on?
Here's what my logs look like for the designate-webhook pod:
$ kubectl logs designate-certmanager-designate-certmanager-webhook-599d5b5nw9r -n cert-manager
I0608 18:12:50.897415 1 secure_serving.go:116] Serving securely on [::]:443
time="2020-06-08T18:12:50Z" level=info msg="Using OpenStack Keystone at https://redactedcloudname.net:5000/v3/"
time="2020-06-08T18:12:51Z" level=info msg="Found OpenStack Designate service at https://redactedcloudname.net:9001/"
I0608 18:12:58.627609 1 log.go:172] http: TLS handshake error from 192.168.0.1:47334: remote error: tls: bad certificate
I0608 18:12:59.262982 1 log.go:172] http: TLS handshake error from 192.168.28.0:46864: remote error: tls: bad certificate
I0608 18:12:59.272653 1 log.go:172] http: TLS handshake error from 192.168.112.0:46826: remote error: tls: bad certificate
I0608 18:12:59.389657 1 log.go:172] http: TLS handshake error from 192.168.0.1:47340: remote error: tls: bad certificate
I0608 18:12:59.439405 1 log.go:172] http: TLS handshake error from 192.168.0.1:47342: remote error: tls: bad certificate
I0608 18:12:59.492992 1 log.go:172] http: TLS handshake error from 192.168.0.1:47344: remote error: tls: bad certificate
I0608 18:12:59.596377 1 log.go:172] http: TLS handshake error from 192.168.0.1:47346: remote error: tls: bad certificate
I0608 18:13:13.655799 1 log.go:172] http: TLS handshake error from 192.168.0.1:47376: remote error: tls: bad certificate
I0608 18:13:13.762759 1 log.go:172] http: TLS handshake error from 192.168.0.1:47378: remote error: tls: bad certificate
I0608 18:13:14.172989 1 log.go:172] http: TLS handshake error from 192.168.0.1:47384: remote error: tls: bad certificate
I0608 18:13:30.342065 1 log.go:172] http: TLS handshake error from 192.168.0.1:47428: remote error: tls: bad certificate
I0608 18:13:32.291519 1 log.go:172] http: TLS handshake error from 192.168.0.1:47436: remote error: tls: bad certificate
I0608 18:13:37.838536 1 log.go:172] http: TLS handshake error from 192.168.0.1:47444: remote error: tls: bad certificate
I0608 18:13:37.941451 1 log.go:172] http: TLS handshake error from 192.168.0.1:47446: remote error: tls: bad certificate
At the moment we are using this version of the cert-manager:
quay.io/jetstack/cert-manager-controller:v0.10.1
We are planning on upgrading shortly. I tested the installation on Kubernetes 1.17.6 The TLS handshake errors in your cluster don't look right. Are all of you API endpoints reachable? At the moment we are using external dns:
https://github.com/kubernetes-sigs/external-dns
and the cert-manager with designate.
Perfect. Thank you, I got it working with with a fresh installation of cert-manager v0.10.1 with no problem.
Also, I apologize for the confusion as I pasted the wrong error on my first post. The issue I originally had was due to the change in the name of cert-manager crds that happened in v0.11.0 ()I used v0.15.0 in my first attempt:
https://github.com/jetstack/cert-manager/releases/tag/v0.11.0
Renaming our API group from certmanager.k8s.io to cert-manager.io
Bumping the API version from v1alpha1 to v1alpha2
So that was causing the chart installation to fail for me and switching to 0.10.1 which uses the older names worked.
If there are plans to support the newer versions of cert-manager, that would be great.
Support newer versions of cert-manager would be great. 👍
@isantospardo We will offer support for the current versions of the cert-manager shortly.
We just added the new release for cert-manager 0.15.x would be great if you can give it a try.