Proxy setting best practices
Learn about best practices for using environment variables to propagate proxy settings.
In Kubernetes, proxy settings can be propagated to pods through the use of environment variables in pod-specific configurations or through ConfigMaps or Secrets that are mounted as volumes within pods. This allows the proxy settings to be passed down to individual containers within the pods. However, it is important to note that not all applications may automatically inherit these settings, and some may require additional configuration within the container image or application code to properly utilize the proxy settings.
It is important to note that the use of no_proxy
or
NO_PROXY
environment variables to bypass proxy settings may not be
consistently respected by all third-party libraries or applications. While some libraries or
applications may automatically honor these settings, others may not.
Many popular libraries and frameworks in various programming languages, such as
Python, Java and Node.js, have their own way of handling proxy settings, which may not
necessarily rely on the no_proxy
or NO_PROXY
environment
variables. These libraries may have their own configuration files or internal settings that
dictate how they handle proxy configurations, and these settings may not always align with the
no_proxy
or NO_PROXY
environment variables set at the system
or project level.
As a result, it is important to be aware that relying solely on no_proxy
or
NO_PROXY
environment variables may not provide consistent results across
all libraries or applications used in a project. In some cases, it may be necessary to clear
out the http_proxy
, https_proxy
, no_proxy
,
or NO_PROXY
environment variables in your project's environment variables or
configuration files to ensure that the third-party libraries or applications do not attempt to
apply proxy settings at all.
To ensure that proxy settings are consistently respected across all libraries and applications used in a project, you must review the documentation and configuration options of each library or application, and configure them accordingly.
However, if you ever have to manage a stack written in multiple languages, you might need to consider some best practices for setting HTTP proxy configurations:
http_proxy
and https_proxy
:- Use lowercase form.
HTTP_PROXY
is not always supported or recommended. - If you absolutely must use the uppercase form as well, be sure both versions share the same value.
no_proxy
:- Use lowercase form.
- Use comma-separated
hostname:port
values. - IP addresses are acceptable, but hostnames are never resolved.
- Suffixes are always matched (for example,
example.com
will matchtest.example.com
). - If top-level domains need to be matched, avoid using a leading dot (.).
- Avoid using CIDR matching since only the Go and Ruby languages support that.
PIP installations with Proxy
When using pip
to install packages from external sources via a proxy, perform
this installation in a separate session (project session), utilizing the existing proxy
rules. Proxy settings, including proxy server addresses, usernames, passwords, and other
configurations, are typically environment-specific. By using a separate session, you can
ensure that the appropriate proxy settings are used for the specific installation task. This
helps to avoid conflicts or misconfigurations with your main session's proxy settings, which
may be required for other tasks or applications.
To resolve Python communication issues between pods with proxy setup, in HTTP_PROXY
,
http_proxy
, HTTPS_PROXY
, https_proxy
) set to
empty values. This will allow Python to run and use kubedns
and
kubeproxy
properly.
- HTTP_PROXY
- http_proxy
- HTTPS_PROXY
- https_proxy
- NO_PROXY
- no_proxy
- ALL_PROXY
The workaround of adding these environment variables in the project session helps resolve the
proxy issue. Since Python does not support CIDR blocks for no_proxy
, the
request automatically gets directed to http_proxy
or
htpps_proxy
, which causes the failure and prevents jobs from completing.