ingress-nginx: [v1] jettech/kube-webhook-certgen is not compatible with 1.22+
NGINX Ingress controller version: v1.0.0-beta.1
Kubernetes version (use kubectl version): 1.22+ server (usernetes v20210708.0)
Environment: Bare metal usernetes
- Cloud provider or hardware configuration: bare metal
- OS (e.g. from /etc/os-release): Fedora 34
- Kernel (e.g.
uname -a): 5.13.6-200.fc34.x86_64 - Install tools: usernetes, helm
- Others:
What happened:
The 1.0.0-beta.1 chart and baremetal/deploy.yaml use jettech/kube-webhook-certgen:v1.5.1 as an admission hook to patch in certs. This image attempts to use admissionregistration/v1beta1 which disappeared in API 1.22. The main repository has an outstanding issue (https://github.com/jet/kube-webhook-certgen/issues/30) to update to using v1 of this API but it hasn’t been worked on AFAICT.
This manifests in the following error when attempting to set up an ingress-nginx on a 1.22+ server with the default chart values or example manifest YAMLs:
$ kubectl logs -n ingress-nginx pod/ingress-nginx-admission-patch--1-xpr9f
W0803 02:54:40.519953 1 client_config.go:608] Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work.
{"level":"info","msg":"patching webhook configurations 'ingress-nginx-admission' mutating=false, validating=true, failurePolicy=Fail","source":"k8s/k8s.go:39","time":"2021-08-03T02:54:40Z"}
{"err":"the server could not find the requested resource","level":"fatal","msg":"failed getting validating webhook","source":"k8s/k8s.go:48","time":"2021-08-03T02:54:40Z"}
What you expected to happen:
How to reproduce it:
-
Run a 1.22+ server I used usernetes v20210708.0 - the latest release from https://github.com/rootless-containers/usernetes/releases/latest
-
Install ingress-nginx with helm using a values file to set the v1.0.0-beta.1 tag and hash
sh-5.1$ cat ingress-nginx.values.yaml
controller:
image:
tag: "v1.0.0-beta.1"
digest: "sha256:f058f3fdc940095957695829745956c6acddcaef839907360965e27fd3348e2e"
sh-5.1$ helm install test-ingress ./charts/ingress-nginx/ --values ingress-nginx.values.yaml
^C # Waited for a while here, it gets stuck
sh-5.1$ kubectl get all -A
NAMESPACE NAME READY STATUS RESTARTS AGE
default pod/test-ingress-ingress-nginx-admission-patch--1-nfp8h 0/1 Error 2 (22s ago) 23s
default pod/test-ingress-ingress-nginx-controller-98f5696c9-m8k84 1/1 Running 0 23s
kube-system pod/coredns-6cff99dc8c-bpv9g 1/1 Running 0 28m
kube-system pod/coredns-6cff99dc8c-nv7gj 1/1 Running 0 28m
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default service/kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 84s
default service/test-ingress-ingress-nginx-controller LoadBalancer 10.0.0.133 <pending> 80:32264/TCP,443:32554/TCP 23s
default service/test-ingress-ingress-nginx-controller-admission ClusterIP 10.0.0.210 <none> 443/TCP 23s
kube-system service/kube-dns ClusterIP 10.0.0.53 <none> 53/UDP,53/TCP,9153/TCP 6d2h
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
default deployment.apps/test-ingress-ingress-nginx-controller 1/1 1 1 23s
kube-system deployment.apps/coredns 2/2 2 2 6d2h
NAMESPACE NAME DESIRED CURRENT READY AGE
default replicaset.apps/test-ingress-ingress-nginx-controller-98f5696c9 1 1 1 23s
kube-system replicaset.apps/coredns-6cff99dc8c 2 2 2 6d2h
NAMESPACE NAME COMPLETIONS DURATION AGE
default job.batch/test-ingress-ingress-nginx-admission-patch 0/1 23s 23s
sh-5.1$ kubectl logs pod/test-ingress-ingress-nginx-admission-patch--1-nfp8h
W0803 03:16:06.529542 1 client_config.go:608] Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work.
{"level":"info","msg":"patching webhook configurations 'test-ingress-ingress-nginx-admission' mutating=false, validating=true, failurePolicy=Fail","source":"k8s/k8s.go:39","time":"2021-08-03T03:16:06Z"}
{"err":"the server could not find the requested resource","level":"fatal","msg":"failed getting validating webhook","source":"k8s/k8s.go:48","time":"2021-08-03T03:16:06Z"}
- Attempt reinstall with patch hook disabled It works if you do this.
$ helm uninstall test-ingress
$ kubectl delete -n default job --all
sh-5.1$ cat ingress-nginx.values.yaml
controller:
image:
tag: "v1.0.0-beta.1"
digest: "sha256:f058f3fdc940095957695829745956c6acddcaef839907360965e27fd3348e2e"
admissionWebhooks:
patch:
enabled: false
sh-5.1$ helm install test-ingress ./charts/ingress-nginx/ --values ingress-nginx.values.yaml
NAME: test-ingress
LAST DEPLOYED: Tue Aug 3 13:17:48 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The ingress-nginx controller has been installed.
It may take a few minutes for the LoadBalancer IP to be available.
You can watch the status by running 'kubectl --namespace default get services -o wide -w test-ingress-ingress-nginx-controller'
An example Ingress that makes use of the controller:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class:
name: example
namespace: foo
spec:
rules:
- host: www.example.com
http:
paths:
- backend:
serviceName: exampleService
servicePort: 80
path: /
# This section is only required if TLS is to be enabled for the Ingress
tls:
- hosts:
- www.example.com
secretName: example-tls
If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided:
apiVersion: v1
kind: Secret
metadata:
name: example-tls
namespace: foo
data:
tls.crt: <base64 encoded cert>
tls.key: <base64 encoded key>
type: kubernetes.io/tls
sh-5.1$ kubectl get all -A
NAMESPACE NAME READY STATUS RESTARTS AGE
default pod/test-ingress-ingress-nginx-controller-98f5696c9-z8xnb 0/1 Running 0 5s
kube-system pod/coredns-6cff99dc8c-bpv9g 1/1 Running 0 29m
kube-system pod/coredns-6cff99dc8c-nv7gj 1/1 Running 0 29m
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default service/kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 3m5s
default service/test-ingress-ingress-nginx-controller LoadBalancer 10.0.0.103 <pending> 80:31922/TCP,443:31545/TCP 5s
default service/test-ingress-ingress-nginx-controller-admission ClusterIP 10.0.0.10 <none> 443/TCP 5s
kube-system service/kube-dns ClusterIP 10.0.0.53 <none> 53/UDP,53/TCP,9153/TCP 6d2h
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
default deployment.apps/test-ingress-ingress-nginx-controller 0/1 1 0 5s
kube-system deployment.apps/coredns 2/2 2 2 6d2h
NAMESPACE NAME DESIRED CURRENT READY AGE
default replicaset.apps/test-ingress-ingress-nginx-controller-98f5696c9 1 1 0 5s
kube-system replicaset.apps/coredns-6cff99dc8c 2 2 2 6d2h
Anything else we need to know:
/kind bug
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 10
- Comments: 29 (15 by maintainers)
Commits related to this issue
- try again without admissionWebhook for patch https://github.com/kubernetes/ingress-nginx/issues/7418 — committed to kingdonb/old-fleet-infra by kingdonb 3 years ago
Tested helm chart 4.0.0-beta.1 with webhooks enabled
and works perfectly, can create new ingress resources without problem.
Thanks.
/priority critical-urgent /assign Cc @tao12345666333 @strongjz before the v1 release this also should be fixed
I actually hit some further issues late yesterday with the
admissionWebhooks.patch.enabled: falsevalue applied. I have to sanitise this output slightly since it’s an internal deployment, the main difference being that it is an ingress backed by an actual service and using a rewrite rule. Hopefully I haven’t missed any other subtleties.Applying a templatised YAML for one of my charts:
That kind of makes sense I guess, since it’s likely that without the patching admission webhook, there might be some stubbed TLS certificate rather than the one which should have been minted. I may have to run through this stuff again to see if I’ve made some mistake.
@freshteapot
The chart’s changelog doesn’t appear to have been updated yet. Check the
Chart.yamlinstead. I usehelm pull ingress-nginx/ingress-nginx --version <exact_version>and it pulls the one I asked for.hello @maybe-sybr @kingdonb @fracarvic ,
We have released a new beta
This contains a new image for the certgen k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.0@sha256:f3b6b39a6062328c095337b4cadcefd1612348fdd5190b1dcbcb9b9e90bd8068
We are hoping you can test this beta.2 and provide feedback. Thanks, ; Long
Just tested helm chart 4.0.0-beta.2 with all of my customizations removed, with the included image and with re-enabled admission webhooks. It’s working for me. 👍
That
helm installcommand appears to work fine for me, @rikatz. Output from the controller pod serving from a simple static landing page service for your reference:Thanks for chasing this up!
Folks, can you please test the webhook with image:
rpkatz/kube-webhook-certgen:v1.5.2
And check if the problem persists? If this is solved, I’m going to submit a PR to the original project
In my case ValidatingWebhookConfiguration stayed installed from previous helm installation. I deleted mine with
and install 4.0.0 helm chart with
controller.admissionWebhooks.enabled: falseand can create new ingress resources without errors.