-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Status prober should track probes work unit based on PodIP+Port instead of PodIP #6269
Comments
That's a change in behavior. You are proposing that probes on all listening ports must succeed. If HTTP and HTTPS are exposed for example and HTTPS is misconfigured, the HTTPS probe will fail forever and IsReady will always be false. Is this what we want? |
@JRBANCEL In Kourier, I believe each Pod has multiple Envoy containers, in which success in one of them doesn't mean config has propagated to the other. However, we may want to wait for Kourier to come to knative/net-kourier before make this more generic. |
Issues go stale after 90 days of inactivity. Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra. /lifecycle stale |
/remove-lifecycle stale |
This will be obsolete once we use Istio VirtualService status instead of probing. |
@JRBANCEL before VirtualService Status is used, I think we will need this to support your migration to using hidden port on |
/assign @JRBANCEL |
We don't cancel the probing of a Pod once a probe succeeds since #8795. We wait for all probes to succeed. Therefore, nothing needs to be done. All the hosts (just one in Istio case) on all the ports will be probed, whether they are on the same Pod or not. |
/close |
@JRBANCEL: Closing this issue. 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. |
In what area(s)?
/area networking
What version of Knative?
HEAD
Expected Behavior
When multiple Envoys are running on a Pod, a successful probe on one port shouldn't cancel the probing on the others.
Actual Behavior
A successful probe on one port cancel probing on the others.
Steps to Reproduce the Problem
The text was updated successfully, but these errors were encountered: