Closed theintz closed 1 year ago
@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 https://github.com/kubernetes-sigs/aws-load-balancer-controller/issues/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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
This is still problematic as it can disrupt a whole environment's service. Are you planning to make any changes related to this? If not, what's the reasoning behind it? I don't see why the controller cannot keep reconciling the valid Ingresses while ignoring the invalid ones.
Thanks!
/reopen
@ivanfoo: You can't reopen an issue/PR unless you authored it or you are a collaborator.
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