-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scaling/design of default-http-backend Deployment #25590
Comments
based on kubernetes/ingress-nginx#3196 it looks like you could also rely on the nginx pods themselves |
Details on what will be implemented: Provide a configuration method for RKE provisioned clusters where the default backend service isn't passed.
Should remove the This is a breaking change in behavior and should be an option. When the next version of Kubernetes ships we should make it the default. This should take the same approach as upstream: kubernetes/ingress-nginx#3196 This is also captured in #25590 |
@nickgerace once this is reviewed/merged can you make a docs issue and PR for this. |
@cbron not a problem |
rancher/rancher:v2.5.4-rc3
@nickgerace: |
They should both be disabled by default.
We were originally going back and forth with the default behavior, but decided to land on maintaining RKE behavior. There's a ticket to track when Kubernetes 1.20 becomes the default version, and then we will "flip" the behavior in both the UI and API. |
What kind of request is this (question/bug/enhancement/feature request): enhancement
Steps to reproduce (least amount of steps as possible): In environments where a high volume of requests to ingress-nginx are performed where there is no matching
Ingress
rule for the requests, increased load is placed on thedefault-http-backend
Pod to handle these requests. Metric collection could also be influencing resource usage during this load.Result: The default
default-http-backend
deployment configuration (1 replica, and CPU/memory resource limits) can introduce a performance and stability issue, with bursty response times and OOM kill of the container.Maintaining this configuration would benefit from scaling the
default-http-backend
Deployment by default, with a minimum of 2 replicas and anti-affinity. The default resource limits may need reviewing to apply to a wider use case.Other details that may be helpful:
As ingress-nginx and the
default-http-backend
share areas of concern, and mutual dependencies, it may make sense to tightly couple these containers in the ingress-nginx DaemonSet.edit: The
/healthz
endpoint traffic measured was from the kubelet readiness/liveness probes - not external healthcheck requests, ingress-nginx handles these locally, previous mention of/healthz
and healthchecks can be ignored.gz#10803
gz#10926
gz#11108
The text was updated successfully, but these errors were encountered: