grpc-ecosystem / grpc-health-probe

A command-line tool to perform health-checks for gRPC applications in Kubernetes and elsewhere
Apache License 2.0
1.44k stars 188 forks source link

Health Probe with -addr=:50051 Does Not Respect no_proxy Environment Variable #153

Closed dSchaexn closed 9 months ago

dSchaexn commented 1 year ago

When using the health probe with the address configuration -addr=:50051, it appears that the probe does not respect the no_proxy environment variable. This is likely because no explicit host is specified, and localhost/127.0.0.1 is implicit.

Steps to Reproduce: Set the http_proxy and no_proxy="localhost,127.0.0.1" environment variables. Run the health probe with the configuration -addr=:50051. Observe that the probe does not respect the no_proxy setting and attempts to use the proxy for the health check.

Expected Behavior: The health probe should respect the no_proxy environment variable, especially when targeting the local host.

Actual Behavior: The health probe attempts to use the proxy even when targeting the local host, ignoring the no_proxy setting.

Possible Solution: Ensure that the health probe checks the no_proxy environment variable and handles implicit localhost addresses correctly.

ahmetb commented 1 year ago

I'm not familiar with no_proxy environment variable. Is this a standard? If so, where is it documented/guaranteed?

dSchaexn commented 1 year ago

Hi Ahmetb,

thank's for your response.

The no_proxy environment variable is indeed a standard used in Unix and Linux systems. It specifies a list of IP addresses, domains, or hostnames that should be accessed directly, bypassing the proxy specified in the http_proxy or https_proxy environment variables.

The no_proxy variable is commonly used in conjunction with the http_proxy and https_proxy variables to define exceptions for hosts that should not be accessed via the proxy. For instance, when accessing local resources within an intranet, it's often necessary to bypass the external proxy. This is where the no_proxy variable comes into play.

You can find documentation on this in various places, including:

man pages: If you check the man page for wget or curl, you'll find references to the no_proxy variable. GNU Wget documentation: Link to Wget documentation cURL documentation: Link to cURL documentation Given its widespread use and the fact that many tools and libraries respect this variable, it would be beneficial for the health probe to also recognize and adhere to the no_proxy settings.

I hope this provides clarity on the significance of the no_proxy environment variable. Let me know if you need any further information or references.

ahmetb commented 11 months ago

@dSchaexn

This is likely because no explicit host is specified, and localhost/127.0.0.1 is implicit.

Correct. According to Go's default transport docs/code, it should be excluding localhost, 127.0.0.1, or ::1 from proxies by deafult, per https://pkg.go.dev/net/http#ProxyFromEnvironment and https://cs.opensource.google/go/x/net/+/refs/tags/v0.19.0:http/httpproxy/proxy.go and it should be still respecting no_proxy env var if specified.

Possible Solution: Ensure that the health probe checks the no_proxy environment variable and handles implicit localhost addresses correctly.

This is likely a wontfix because as the user, you can specify localhost explicitly.

sushain97 commented 7 months ago

@ahmetb 👋 I don't quite think that works. I haven't chased down why yet. But, here's my setup:

image

That is, no_proxy=localhost,127.0.0.1,::1,.service.skc.name,.local.skc.name,.cluster.local,127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16.

Regardless, health checks crash loop:

image

image

This is in registry.k8s.io/nfd/node-feature-discovery:v0.14.2 that runs as part of the nvidia gpu-operator.