Skip to content
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

Closed
tcnghia opened this issue Dec 20, 2019 · 10 comments
Closed
Assignees
Labels
area/networking kind/bug Categorizes issue or PR as related to a bug.
Milestone

Comments

@tcnghia
Copy link
Contributor

tcnghia commented Dec 20, 2019

In what area(s)?

/area networking

/area test-and-release

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

@tcnghia tcnghia added the kind/bug Categorizes issue or PR as related to a bug. label Dec 20, 2019
@JRBANCEL
Copy link
Contributor

JRBANCEL commented Jan 3, 2020

That's a change in behavior.
Currently, we only validate that the Envoy runs the expected config by probing all known listening ports and considering one successful probe (no matter which port/protocol) a success for that Envoy pod. We do not validate that the config is correct.

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?

@tcnghia
Copy link
Contributor Author

tcnghia commented Mar 5, 2020

@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.

@tcnghia tcnghia added this to the Ice Box milestone Mar 5, 2020
@knative-housekeeping-robot

Issues go stale after 90 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle stale.
Stale issues rot after an additional 30 days of inactivity and eventually close.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle stale

@knative-prow-robot knative-prow-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 3, 2020
@vagababov
Copy link
Contributor

/remove-lifecycle stale

@knative-prow-robot knative-prow-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 3, 2020
@JRBANCEL
Copy link
Contributor

JRBANCEL commented Jun 3, 2020

This will be obsolete once we use Istio VirtualService status instead of probing.

@tcnghia
Copy link
Contributor Author

tcnghia commented Aug 22, 2020

@JRBANCEL before VirtualService Status is used, I think we will need this to support your migration to using hidden port on istio-ingressgateway for cluster local traffic?

@tcnghia tcnghia modified the milestones: Ice Box, 0.18.x Aug 25, 2020
@tcnghia
Copy link
Contributor Author

tcnghia commented Aug 25, 2020

/assign @JRBANCEL

@JRBANCEL
Copy link
Contributor

JRBANCEL commented Sep 2, 2020

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.

@JRBANCEL
Copy link
Contributor

JRBANCEL commented Sep 2, 2020

/close

@knative-prow-robot
Copy link
Contributor

@JRBANCEL: Closing this issue.

In response to this:

/close

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/networking kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

No branches or pull requests

5 participants