-
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
Probe Envoy without using requests #6829
Comments
/assign |
Are we sure this is a Pro and not a Con?
This is insufficient, you also need to verify that the endpoints referenced aren't empty. |
It is a Pro to not have to deal with Istio Policies and Envoy filters.
It depends, either we want probing to:
We do 2) today, and achieving 1) is tricky. |
FYI - Pilot has an endpoint that tracks envoy configuration rollout - that might be worth experimenting with |
I looked at how We can reuse this, but it is not exactly lightweight and we'll probably run into permission issues. |
This is no possible to do efficiently and easily (see previous comment) |
Describe the feature
Today, Istio Envoy Pods are probed using a special requests (
"K-Network-Probe" == "probe"
).This works well but breaks in the following scenarios:
There is no way to filter policies on header content. Filtering on path is possible and we could
GET
a specific path, e.g./.well-known/knative-probe
, but it is exposing internals to users.One way to achieve this is to fetch the Envoy configuration (
GET /config_dump
) directly and inspect it to find the hash that is inappendHeader
today.Pros:
activator
andqueue-proxy
: cleaner abstractionCons:
/config_dump
output is a lot heavier than checking for HTTP 200, but we probably don't need to parse it, we can simply scan it for the string we want/cc @mattmoor @tcnghia @markusthoemmes @yuzisun
The text was updated successfully, but these errors were encountered: