kubeadm should support proxy configuration via parameters

[deknos]

What keywords did you search in kubeadm issues before filing this one?

proxy

Is this a BUG REPORT or FEATURE REQUEST?

Feature Request

I want that following environment parameters can be alternatively defined as parameters to kubeadm:

• http_proxy
• https_proxy
• no_proxy

since http and https may be different proxies, it should be different parameters. and no_proxy shall support ip ranges.

Versions

kubeadm version (use kubeadm version):
kubeadm version: &version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.1", GitCommit:"b1b29978270dc22fecc592ac55d903350454310a", GitTreeState:"clean", BuildDate:"2018-07-17T18:50:16Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Environment:

• Kubernetes version (use kubectl version):
  Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.1", GitCommit:"b1b29978270dc22fecc592ac55d903350454310a", GitTreeState:"clean", BuildDate:"2018-07-17T18:53:20Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
  Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.2", GitCommit:"bb9ffb1654d4a729bb4cec18ff088eacc153c239", GitTreeState:"clean", BuildDate:"2018-08-07T23:08:19Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
• Cloud provider or hardware configuration:
  Debian 9, OpenTelekom Cloud, Elastic Computing Instance.
• OS (e.g. from /etc/os-release):
  root@debian9kub01:/home/linux# cat /etc/os-release
  PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
  NAME="Debian GNU/Linux"
  VERSION_ID="9"
  VERSION="9 (stretch)"
  ID=debian
  HOME_URL="https://www.debian.org/"
  SUPPORT_URL="https://www.debian.org/support"
  BUG_REPORT_URL="https://bugs.debian.org/"
• Kernel (e.g. uname -a):
  Linux debian9kub01 4.9.0-7-amd64 kubeadm join on slave node fails preflight checks #1 SMP Debian 4.9.110-3+deb9u1 (2018-08-03) x86_64 GNU/Linux

What happened?

Proxies can only be defined with Environment variables. This is inconvienent and problematic when you rollout with kubeadm via scripts and configuration management tools.

What you expected to happen?

Parameters for kubeadm (and documentation for that) for defining http/https proxies and ranges where no proxy should be used.

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

try to rollout kubernetes via kubeadm and internet access only with http proxies and do not use environment variables

[neolit123]

some explanations of how the current code in kubeadm works:
#324

I want that following environment parameters can be alternatively defined as parameters to kubeadm:

so right now i'm pretty sure you can do this on Linux:

http_proxy='...' https_proxy='...' no_proxy='...' sh -c 'kubeadm init ...'

(single quotes are important)

Proxies can only be defined with Environment variables. This is inconvienent and problematic when you rollout with kubeadm via scripts and configuration management tools.

try the above solution. but i'd agree that env variables are inconvenient in general. for the *_proxy case we are dealing with a Unix-ism here.

[deknos]

while that may be right, this may create problems for kubeadm AND kubectl.

I run kubeadm and kubectl calls from ansible, and with initialization AND kubectl calls i have to wrap bash -c calls around my kube* calls since the shell module does not execute a "real" bash, which results in really nasty wrappers.

example:

• name: initialize kubernetes via kubeadm
  shell: |
  bash -c 'source /opt/kubernetes/proxies.sh ;
  kubeadm init
  --token "{{ token }}"
  --token-ttl "{{ token_duration }}"
  --pod-network-cidr "{{ pod_network_cidr }}"'
• name: Deploy kubernetes network
  shell: |
  bash -c 'source /opt/kubernetes/proxies.sh ;
  kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.10.0/Documentation/kube-flannel.yml'

My Expectation would be:

• kubeadm gets http/s/no_proxy definition via command line
• and writes that to a config file
• kubectl uses that proxy definition.

[deknos]

let's say it another way. sadly we cannot expect that environment variables are easy to set or respected in configuration management tools, or your shell does not respect them.

[neolit123]

any reason to not use environment for your ansible task?

You might also want to simply specify the environment for a single task

https://docs.ansible.com/ansible/2.6/user_guide/playbooks_environment.html

[deknos]

In that specific point: It does not work.

But the more general issue is (imo), that the execution environment may be an extremely sanitized version. I COULD hack around shell/command deficiences, but that is (imo) not a good architecture style AND it can create problems/insecurities.

[deknos]

Example with kubectl (indentation is broken here):

• name: show all infos
  environment:
  KUBECONFIG: '/etc/kubernetes/admin.conf'
  command: 'kubectl get all --all-namespaces -o wide'

This Task will not work. neither with the command nor with the shell module. Is it a bug? Yes. But there i could do --kubeconfig=/etc/kubernetes/admin.conf. And there may be other environments out there which do not support environments as well for whatever reason :-)

[neolit123]

how about a test hello world app that fetches env variables - does that work with environment under ansible?
https://gobyexample.com/environment-variables

[deknos]

this is not a ansible problem. that will be every time a problem, when a executed command does not support more environment variables. neither via export nor via shell variable. this should be a global parameter, which

• can be set
• perhaps set even persistently, so that after the first init, it is written into the config.

[neolit123]

if you are not using ansible this works fine:

http_proxy='...' https_proxy='...' no_proxy='...' sh -c 'kubeadm init ...'

if you are using ansible and the environment field does not work, then this is a ansible bug.

AFAIK, this is the first time someone requests this feature.
but it has to be moved to the backlog because it's relatively low priority.

contributions are always welcome too!

[timothysc]

I'm going to close this one, b/c behavior exists today that allows folks todo what is being asked for. If you have a proposed PR we'd happily review.