Kubeadm: Kubeadm use deprecated controller-manager and scheduller flags

[yuripastushenko]

Is this a BUG REPORT or FEATURE REQUEST?

BUG REPORT

Versions

kubeadm version v1.12.2

What happened?

When I run kubeadm init without any parameters - one of steps is generating manifests for kube-scheduller (/etc/kubernetes/manifests/kube-scheduler.yaml) and kube-controller-manager (/etc/kubernetes/manifests/kube-controller-manager.yaml).
In both manifests, one of the flags that is given at startup to application is:
--address=127.0.0.1.

This flag is deprecated for kube scheduler - see https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/#options .
And this flag is absent in options of kube-controller-manager - see https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options.

But those flags at this moment are still working.

What you expected to happen?

I expected to see flag:
--bind-address=127.0.0.1 in both manifests (kube-controller-manager and kube-scheduler) instead of --address=127.0.0.1

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

run:
kubeadm init --dry-run
and see those flags in output, in sections:
[dryrun] Would write file "/etc/kubernetes/manifests/kube-controller-manager.yaml" with content: [dryrun] Would write file "/etc/kubernetes/manifests/kube-scheduler.yaml" with content:

[neolit123]

marking this is a good first issue.

a change has to be made here:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/controlplane/manifests.go#L254
and here:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/controlplane/manifests.go#L298

and in the file with the unit tests too:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/controlplane/manifests_test.go

[yuripastushenko]

imho - those flags need to be removed at all.
I described my opinion in next issue - https://github.com/kubernetes/kubeadm/issues/1235

[neolit123]

@kubernetes/sig-cluster-lifecycle

[yagonobre]

I can work on it

[neolit123]

/assign @yagonobre
/lifecycle active

i wanted to see comments about these address fields as we have them in the kubeadm design document as 127.0.0.1.
0 or :: means default network interface, so i don't think we should remove them.
cc @luxas @kad

[arslanbekov]

Hello!
We have the same issue like #1235.
Any suggestions guys?

[timothysc]

We are out of time, punt to 1.14

[neolit123]

xref:
https://github.com/kubernetes/kubeadm/issues/1285
cc @luxas

[luxas]

@yagonobre any progress?

[yagonobre]

@luxas I'll send a pr tomorrow.

[yuripastushenko]

Like i told in https://github.com/kubernetes/kubeadm/issues/1235 - i think we should by default exclude this flag at all, because the default value of --bind-address is driven by kubeadm and is 0.0.0.0.
The users should have the ability to leave the default behaviour of kubeadm for this flag.

[yagonobre]

/unassign

[rosti]

/lifecycle active
Due to pending PR by @MalloZup

[MalloZup]

/assign

[k8s-ci-robot]

@MalloZup: GitHub didn't allow me to assign the following users: MalloZup.

Note that only kubernetes members and repo collaborators can be assigned.
For more information please see the contributor guide

In response to this:

/assign

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[MalloZup]

todos:

• [x] adress this https://github.com/kubernetes/kubernetes/pull/71973#issuecomment-449031692

[dannyk81]

Hello,

Was just got hit by this issue, we are deploying K8s 1.13.2 with Kubespray and set bind-address for both scheduler and controller-manager to 0.0.0.0, however the deprecated --address is still being added to the manifest and seems to take precedence.

I noticed that this was released as part of 1.14 alpha release, but looks like it didn't make it to 1.12 or 1.13 yet.

Is it possible to add this fix on these releases too?

/cc @neolit123