A command on the Kubernetes node can use a shell proxy while a Pod on that node has no proxy environment. The container's environment is defined by its image and Pod configuration.

For an application supporting these variables, add an env list to its existing container entry:

env:
  - name: HTTP_PROXY
    value: http://proxy.example:8080
  - name: HTTPS_PROXY
    value: http://proxy.example:8080
  - name: NO_PROXY
    value: localhost,127.0.0.1,kubernetes.default.svc,.svc,.cluster.local

In a Deployment, this belongs under the relevant container in spec.template.spec.containers. Update the workload through its normal rollout so new Pods receive it. Supply lowercase names too when the actual client requires them.

The bypass list is a starting illustration, not an inventory of every cluster route. Use the cluster's real DNS suffix and internal destinations. Applications using service IPs may need the actual service ranges in a syntax their client supports.

Init containers have their own container specifications. Add the intended configuration there when they perform an external download. For public HTTP downloads, an endpoint from the HTTP proxy list is a candidate for these container environment values.

Image pulls happen before the application runs and are performed by the node's container runtime. Pod env cannot configure that earlier registry connection.

Finally, HTTP proxy variables only affect clients that consume them. They do not redirect arbitrary database, UDP or other socket traffic from the Pod.

Ũhoro ũhĩtĩte