-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Controller doesn't process request if stuck elsewhere (OIDC annotation missing secret) #2669
Comments
@theintz, in case of errors, controller will not reconcile the ingress or the group further. If you use ingress group feature, fatal errors encountered during processing of one ingress affects the entire group. Other ingresses not part of the group should still continue to work as expected. Controller tolerates certain errors, for example if backend service doesn't exist, it configures a 404 response but doesn't block the reconciliation. |
Is there a more general solution/roadmap in this area to allow valid ingresses within the same group to reconcile if 1 or more are in an error state? Seems somewhat similar to #2042 |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
@kishorj Thanks for the explanation and sorry for the late reply. I don't understand the motivation behind this behavior. Even if a number of ingresses share the same group, why would the reconciliation be blocked if one of them fails? Shouldn't the controller try to reconcile as many ingresses as possible? |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
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. |
Describe the bug
When an ingress change request can't be fulfilled by the controller, it logs the error and then stops processing all other requests, even those that could be fulfilled.
Steps to reproduce
Create two deployments with ingresses, one that will deploy without errors, another one that doesn't (for example by requiring external resources such as a secret that aren't available). If the faulty one is requested first, the controller will fail to deploy it and log errors repeatedly. When the second request is issued, it will not be processed, even though it is not connected to the faulty request and could be fulfilled.
More concretely, we are using the
alb.ingress.kubernetes.io/auth-idp-oidc
annotation, to set up the LB to do auth over OIDC. It requires passing a parameter calledsecretName
containing the name of the k8s secret that holds theclientSecret
as required by the Oauth2 standard. If this secret does not exist, the controller exhibits the mentioned behavior.Expected outcome
Valid ingress change requests are processed, even if the controller is stuck on a faulty request elsewhere.
Environment
1.3.2
1.20
yes, most current
The text was updated successfully, but these errors were encountered: