HTTP_PROXY environment variables are unset for kubeadm

[madddi]

What happened:
HTTP_PROXY (and similar) environment variables are not configured for components configured in kubelet manifests.

What you expected to happen:
When configured, the proxy server should also be set for the Kubernetes control plane components.

How to reproduce it (as minimally and precisely as possible):

1. Configure HTTP_PROXY, HTTPS_PROXY, NO_PROXY etc. for a host
2. Deploy
3. Check a kubelet manifest - the variables are missing

Anything else we need to know?:
The variables are explicitly unset in kubeadmin-init.sh and kubeadm-reconfigure.sh. This was changed in #395. Not all variants of http proxy environment variables are unset there, which leads to inconsistent behavior depending on the spelling. When these lines are removed, kubeadm configures proxy servers correctly.

In very restricted environments with no internet access it's necessary to communicate with cloud-provider APIs via a proxy server. This is why we explicitly want to configure the server for all components. A correct no_proxy environment variable excluding all internal resources is of course necessary then.

Environment:

• Pharos version (use pharos --version): 2.0.3+oss
• Cloud provider or hardware configuration: aws

[kke]

Probably relevant:
kubernetes/kubeadm#324
kubernetes/kubernetes#53895 (allow CIDR notation in NO_PROXY)

[kke]

@jakolehm @jnummelin This was deliberately and explicitly done in #395 - should it be reverted?

[kke]

(can confirm that currently for example NO_PROXY and FTP_PROXY end up in the manifest.)

[jakolehm]

@madddi @kke #395 included this change because in most (all?) cases we want to have direct communication between different kubernetes components. It has a side-effect that kubernetes components won't get configured proxy for external service either... which is a bug. Not sure if we can generate NO_PROXY automatically if user has not configured it?

[jakolehm]

Or maybe we shouldn't unset if NO_PROXY is set?

[kke]

In any case, the kubeadm-*.sh should probably either unset all _proxy envs or leave all of them untouched (maybe when NO_PROXY is set).

Now it will persist NO_PROXY and FTP_PROXY, FOOBAR_PROXY or any other env that ends with _proxy (case insensitive) except the explicitly unset http_proxy, HTTP_PROXY and HTTPS_PROXY, which is inconsistent.

[jakolehm]

Yeah, we should unset all.

[kke]

It could be made optional if necessary, but let's start with unsetting all.

[madddi]

The Kubernetes components should of course communicate directly with each other. As described, we actually need the variables set for kubeadm:

In very restricted environments with no internet access it's necessary to communicate with cloud-provider APIs via a proxy server. This is why we explicitly want to configure the server for all components. A correct no_proxy environment variable excluding all internal resources is of course necessary then.

In a scenario where this is necessary I'd leave the correct NO_PROXY configuration to the user. So as a user I think making the unset optional would be fine. If the user then explicitly enables HTTP_PROXY for kubeadm she or he should also be able to configure the NO_PROXY list correctly.

[kke]

#862 Made the unsetting optional via control_plane: { use_proxy: true }