High CPU consumption nginx-ingress-controller if the ingress object has a non-existent service specified.

[anvpetrov]

When setup nginx ingress controller(latest version) with --enable-ssl-passthrough flag , and create ingress object with annotations:

    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    nginx.ingress.kubernetes.io/ssl-passthrough: 'true'

and specify fake service name (we will specify a service that does not exist).
It is enough to call ingress once via curl and the nginx-ingress-controller processes will dramatically increase PROCESSOR consumption.

kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    nginx.ingress.kubernetes.io/ssl-passthrough: 'true'
  name: test
  namespace: test
spec:
  ingressClassName: test
  tls:
    - hosts:
        - test.com
  rules:
    - host: test.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: fake-svc
                port:
                  number: 443

curl -vk --resolve test.com:443:INGRESS_IP https://test.com/

in the network dump, we see thousands of requests per second to 127.0.0.1:443

[k8s-ci-robot]

This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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-sigs/prow repository.

[longwuyuan]

/remove-kind bug
/kind support

Using this annotation

    nginx.ingress.kubernetes.io/backend-protocol: HTTPS

with ssl-passthrough, is INVALID because the termination of TLS is in the backend pod so there is no "backend-protocol" to configure.

Also you have to use the annotation "force-ssl-redirect", when you use ssl-passthrough. And you have to enable ssl-passthrough flag .

[anvpetrov]

the problem is reproduced with the two annotations that you suggested.

nginx.ingress.kubernetes.io/ssl-passthrough: 'true'
nginx.ingress.kubernetes.io/force-ssl-redirect: 'true'

[anvpetrov]

Easy to reproduce on minikube

minikube start --kubernetes-version 1.27.15 --driver=docker
minikube addons enable ingress
Add flag to ingress --enable-ssl-passthrough
kubectl create -f ingress.yaml
curl -k --resolve "test.com:443:$( minikube ip )" -i https://test.com

[longwuyuan]

@anvpetrov thanks for the update.

I am missing something here. So please explain why this project should allocate resources to a use case where you create a ingress resource but the ingress backend configured is not existing in the namespace. We don't support this use-case in the code and there are no e2e tests to cover this use case.

Personally I think the admission controller will block creating the ingress if the backend is not existing but that is a different topci completely.

Or am I not understandng the problem at all ?

[anvpetrov]

The problem is also reproduced if the service was created and later deleted.
It's easy to delete a service without making sure it's not being used somewhere in ingress.

Ingress controller is very often used by several teams, and it is likely that the service may be deleted without ingress being cleaned up.
As a result, nginx-ingess-controller will be heavily utilized and will have an impact on other teams. Diagnosing this issue will be extremely difficult for teams that are not aware of the bug.

[longwuyuan]

The project does not have resources like developer time. So we have announced that we will focus on the core Ingress-API feature and Security.

Hence it is expected that if service/workload is deleted then its related ingress also is deleted. Not deleting ingress but deleting the service/workload configured in the ingress, can not be a VALID use case for the project to do research and development on. So this is not a bug. In case you want to discuss more, you can start a thread in the slack dev channel for the controller. You can also join the monthly community meeting.

Wait for comments from others.

I think that your use may be really a practical use-case . But the project has to choose what is directly related to K8S Ingress-API and what is a special feature. This is because there is lack of developers to work on such features and maintain/support such features.