Canary ingress conflict with existing ingress when canary annotation set to "false"

[vorozhko]

NGINX Ingress controller version: v0.43

Kubernetes version (use kubectl version):
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.15-gke.6000", GitCommit:"b02f5ea6726390a4b19d06fa9022981750af2bbc", GitTreeState:"clean", BuildDate:"2020-11-18T09:16:22Z", GoVersion:"go1.13.15b4", Compiler:"gc", Platform:"linux/amd64"}

Environment:

• Cloud provider or hardware configuration: GKE cluster
• OS (e.g. from /etc/os-release): Linux, GKE default CoreOS
• Kernel (e.g. uname -a):
• Install tools:
• Others:

What happened:

Ingress validation webhook don't allow updates to "main" ingress when "canary" ingress annotation set to "false".

Error from server (BadRequest): error when creating "STDIN": admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: host "foo.bar" and path "/" is already defined in ingress test/foo-bar-canary

What you expected to happen:
Even though Canary ingress has nginx.ingress.kubernetes.io/canary: "false" it should be still possible to update main ingress without any problem.

How to reproduce it:

Install minikube/kind

• Minikube https://minikube.sigs.k8s.io/docs/start/
• Kind https://kind.sigs.k8s.io/docs/user/quick-start/

Install the ingress controller

kubectl apply -f https://github.com/kubernetes/ingress-nginx/blob/master/deploy/static/provider/cloud/deploy.yaml

Create an ingress

Create Canary ingress first with canary:false

echo "
  apiVersion: networking.k8s.io/v1beta1
  kind: Ingress
  metadata:
    name: foo-bar-canary
    annotations:
      kubernetes.io/ingress.class: nginx
      nginx.ingress.kubernetes.io/canary: 'false'
  spec:
    rules:
    - host: foo.bar
      http:
        paths:
        - backend:
            serviceName: http-svc
            servicePort: 80
          path: /
" | kubectl apply -f -

Create Main ingress

echo "
  apiVersion: networking.k8s.io/v1beta1
  kind: Ingress
  metadata:
    name: foo-bar-main
    annotations:
      kubernetes.io/ingress.class: nginx
  spec:
    rules:
    - host: foo.bar
      http:
        paths:
        - backend:
            serviceName: http-svc
            servicePort: 80
          path: /
" | kubectl apply -f -

Anything else we need to know:
Canary ingress check is based on a value of canary annotation. As defined here

Checking canary annotation string instead of value will solve this issue.

/kind bug

[aledbf]

@vorozhko by setting canary: 'false' you are creating two ingress definitions for the same host/path. That is not allowed.
Also, by creating a definition with the canary annotation first, it takes precedence to build the configuration.

Not sure exactly what are you expecting here. The error you see is right.

[vorozhko]

How can I disable canary without deleting canary ingress?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[iamNoah1]

Hi @vorozhko do you still consider this being an issue? For me, it looks more like something that maybe needs to be documented in a better way?! What do you think @rikatz? Or a support task?!

[vorozhko]

Hi @iamNoah1, the issue initially affected Flagger fluxcd/flagger#787, but it was resolved few week ago. The workaround was to delete canary ingress instead of setting it false.
So, issue with validation webhook and canary "false" combination didn't go anywhere.

[k8s-triage-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.