ingress-nginx: Error: admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: host "xyz" and path "/" is already defined in ingress xxx
I recently upgraded to k8s 1.22.4 and ingress-nginx version 4.0.16 and now its no longer possible to create two different ingress objects with the same host/path pointing to two different services (which need I need for a temporary workaround).
This worked fine in k8s 1.15 with e.g. something like this:
- apiVersion: networking.k8s.io/v1beta1
kind: Ingress
spec:
rules:
- host: my-host.internal
http:
paths:
- backend:
serviceName: my-app-a
servicePort: 8080
path: /
tls:
- hosts:
- my-host.internal
status:
loadBalancer:
ingress:
- {}
- apiVersion: networking.k8s.io/v1beta1
kind: Ingress
spec:
rules:
- host: my-host.internal
http:
paths:
- backend:
serviceName: my-app-b
servicePort: 8080
path: /
tls:
- hosts:
- my-host.internal
status:
loadBalancer:
ingress:
- {}
But in 1.22.4 with:
- apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-app-a
spec:
rules:
- host: my-host.internal
http:
paths:
- backend:
service:
name: my-app-a
port:
number: 8080
path: /
tls:
- hosts:
- my-host.internal
status:
loadBalancer:
ingress:
- {}
- apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-app-b
spec:
rules:
- host: my-host.internal
http:
paths:
- backend:
service:
name: my-app-b
port:
number: 8080
path: /
tls:
- hosts:
- my-host.internal
status:
loadBalancer:
ingress:
- {}
I get the error:
Error: admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: host "xyz" and path "/" is already defined in ingress xxx
Is there some document/changelog describing this specific change or some option I can temporary set to allow for multiple ingresses to be created with same host/paths?
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 4
- Comments: 42 (17 by maintainers)
Whoever comes here from google search disabling admission webhook in controlled didn’t help me, but
kubectl delete -A ValidatingWebhookConfiguration ingress-nginx-admissionhas.We have a genuine use case for this to work. We have two ingress-nginx instances, one for traffic from external sources, and one for traffic from internal sources.
We want to use an internal ingress to route traffic the the internal ingress-nginx, and the external ingress to route traffic to the external-nginx. There is no conflict or ambiguity. The IP routing makes sure that the traffic goes to the correct instance.
But as of the latest ingress-nginx it seems that this working setup is no longer working. As the two ingress objects conflict with each other despite having two different classes.
I consider this a regression and as a result a bug.
This behaviour conflicts with the documentation:
@tobinus note that @dud225 pointed out earlier in the discussion, the currently documented behavior is “If the same path for the same host is defined in more than one Ingress, the oldest rule wins”, so your suggestion of “handle duplicate ingresses in a deterministic manner” is actually already implemented. The situation is already handled gracefully, it’s just prevented from occurring by the admission webhook.
In addition to it being the one already implemented I think, your suggestion of “handle duplicate ingresses in a deterministic manner” is the best option, since it allows for broader use cases than just “rename existing ingresses”, but zero-downtime replacement of ingresses in general. This is useful for helm upgrades, where a template could be modified to change both the naming scheme and the configuration of an ingress at the same time (or different times, which then get compressed into one time by a user jumping multiple versions in a single upgrade).
I understand the reasoning of wanting to avoid potential confusion caused by multiple Ingress objects matching a single route, but to me this is a case of trying to mitigate a surface-level confusing behavior leading to more deeply confusing behavior down the road.
Probably duplicate of #7546. It has been merged and It will probably be fixed in the next release.
Its not in the ingress api spec to implement controllers that can service 2 ingress objects with identical host & path. Imagine the practical consequences of that.
However another person seemed to have faced this same requirement https://kubernetes.slack.com/archives/CANQGM8BA/p1616518953121800
/remove-kind bug
This ticket should be closed by the author
We are also seeing this surprising behaviour from the admission webhook. It’s surprising to us because without the ability to use the existing behaviour, cosmetically re-naming Ingress resources triggers downtime.
Are there no work-arounds other than disabling all webhook validation?
@mesquitamv I have a vague recollection I disabled the admission web hook. It isn’t needed, it just does some sanity checks. Which it appears are a bit broken.
Looking at the helm chart, I think you can disable the hooks by setting
admissionWebhooks.enabledto false.We are now using skipper, that does not have this particular problem.
Unfortunately, since this bug was auto closed, I don’t think we are getting the attention of the developers. Might need to open a new bug report, since we can’t reopen this one. But I would suggest looking for an alternative ingress implementation, maybe one that is better supported.
Also while good somebody posted a link to a workaround, would be good if somebody could paste the gist here, as not everybody is subscribed to that slack channel…
My guess is that the workaround is to disable the webhook, i.e. set controller.admissionWebhooks.enabled=false