✅ Deploy Preview for kubernetes-ingress-nginx canceled.

Welcome @Fsero!

It looks like this is your first PR to kubernetes/ingress-nginx 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/ingress-nginx has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

Hi @Fsero. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

From the K8S official resources, it will be useful to add a link here that covers the specs and KEP for any ingress-controller, to deal with duplicate routing rule factors like identical hostname and identical path.

I'm not sure about adding footguns like this to the configuration.

With that said, we can add it but disable it as default, so the cluster admin has to choose to allow it consciously.

It may be in the check overlap function, but can you ensure this dumps out a warning in the admission logs?

Can you add an e2e test about this with it enabled and disabled?

/kind feature

@strongjz @cpanato @rikatz just rebased in top of main this PR, waiting for approvals.

Is there something else I can do to merge this one?

Thanks a lot

Hi, is there an update on this? We're running into this exact issue and merging this PR would solve it.

Moving ingress objects between namespaces without downtime

I believe that this use case has practical significance.

Please resolve the conflicts.

done @tao12345666333

@strongjz @rikatz @cpanato is there something else I can do to merge this one?

Thanks a lot

lets wait a bit more on this, i will discuss that with @rikatz when we both have a time

We can add it to the list for our next community meeting. @strongjz

We can add it to the list for our next community meeting. @strongjz

hey! any news on this?

thanks so much

What's the hesitation on this? It seems super valuable to me -- happy to provide more feedback about why if that'd be helpful!

@strongjz @rikatz @cpanato sometime has passed and this one it's still open, do you need something else that I can do?

Thanks!

resurfacing this again @strongjz @rikatz @cpanato do you need me to do something else? do you want me to join the community meeting to explain I think this is useful (we are using this internally in our fork)

Thanks a lot

Sorry for the long delay.

As I replied before, I think this case has practical significance.
#10943 (comment)

@Fsero @airhorns You can join the community meeting next time or post details here.
We want to know more about the background and the value of this use case.

My use case is described here: #10820 -- in order to make that change, we needed to manually remove the validating webhook in k8s which felt quite risky, make the change, then add it back after removing the duplicates. I can confirm the actual controller was fine with the duplicate resources.

I had an ingress resource that had multiple host names, which locked me in to using the same set of ingress-nginx annotations for each. I wanted to start customizing some annotations for various hostnames, like turning on consistent hashing for a subset of customer domains, or adjusting the rate limit for big tenants up, but I couldn't split the ingress into one ingress resource per hostname without this flag. Can I provide any more info?

This would be so incredibly useful.

let's see if i can explain an use case, imagine you have a company with several teams deploying microservices, there is a good amount of traffic in the service and in the ingress, and due to an internal change you want to transfer the service from team foo to team bar.

Original microservice offered two endpoints /apple and /banana and team bar will get ownership of /banana while /apple will remain managed by foo.

you can setup this scenario in a local kind (I actually created one with make dev-env) and try to apply the following manifest

apiVersion: v1
kind: Namespace
metadata:
  labels:
    kubernetes.io/metadata.name: foo
  name: foo
spec:
  finalizers:
  - kubernetes
---
apiVersion: v1
kind: Namespace
metadata:
  labels:
    kubernetes.io/metadata.name: bar
  name: bar
spec:
  finalizers:
  - kubernetes
---
kind: Pod
apiVersion: v1
metadata:
  name: banana-app
  namespace: foo
  labels:
    app: banana
spec:
  containers:
    - name: banana-app
      image: hashicorp/http-echo
      args:
        - "-text=banana"
---
kind: Service
apiVersion: v1
metadata:
  name: banana-service
  namespace: foo
spec:
  selector:
    app: banana
  ports:
    - port: 5678 # Default port for image
---
kind: Pod
apiVersion: v1
metadata:
  name: apple-app
  namespace: bar
  labels:
    app: apple
spec:
  containers:
    - name: apple-app
      image: hashicorp/http-echo
      args:
        - "-text=apple"
---

kind: Service
apiVersion: v1
metadata:
  name: apple-service
  namespace: bar
spec:
  selector:
    app: apple
  ports:
    - port: 5678 # Default port for image
    
---


apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: one-ingress
  namespace: foo
  annotations:
    ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: foo.bar.io
    http:
      paths:
        - path: /apple
          pathType: Prefix
          backend:
            service:
               name: apple-service
               port: 
                 number: 5678
        - path: /banana
          pathType: Prefix
          backend:
            service:
                name: banana-service
                port:
                  number: 5678
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: another-ingress
  namespace: bar
  annotations:
    ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: foo.bar.io
    http:
      paths:
        - path: /banana
          pathType: Prefix
          backend:
            service:
                name: banana-service
                port:
                  number: 5678

bar team members have read this part of the documentation of ingress nginx and thought that would be very neat to create an ingress and deploy the service for some local test and allow the original service to handle the traffic so when everything is ready foo team just need to edit one-ingress object and remove the /banana path and team bar will start receiving traffic with 0 downtime.

but when someone in bar tries to apply the manifest it finds the following error

ingress.networking.k8s.io/one-ingress unchanged
Error from server (BadRequest): error when creating "manifest.yaml": admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: host "foo.bar.io" and path "/banana" is already defined in ingress foo/one-ingress

for most cases that might be a valid protection but when you want to achieve zero downtime traffic migrations between ingress objects is counterproductive.

This is the purpose of this PR give an opt-in flag that allows maintainers to bypass this and only this validation without disabling the rest of admission validations that are still useful.

cc @tao12345666333 @strongjz @rikatz