kubeadm: Invalid etcd config generated when using DNS discovery approach

Is this a BUG REPORT

Versions

kubeadm version:

&version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0", GitTreeState:"clean", BuildDate:"2019-06-06T01:41:54Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}

Environment:

• Kubernetes version:

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0", GitTreeState:"clean", BuildDate:"2019-06-06T01:44:30Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}

• Cloud provider or hardware configuration: AWS
• OS: Ubuntu 18.04
• Kernel: Linux 4.15.0-1040-aws

What happened?

When using kubeadm init phase etcd local --config=/root/kubeadmcfg.yaml with the config file containing the following extra argument:

    extraArgs:
      discovery-srv: "example.com"

an invalid configuration is generated and etcd fails to start with the following message:

multiple discovery or bootstrap flags are set. Choose one of "initial-cluster", "discovery" or "discovery-srv"

etcd code that test for this scenario

This is due to the fact that kubeadm adds the initial-cluster argument when generating the config

What you expected to happen?

kubeadm might check if discovery-srv is present in the ExtraArgs and not add the initial-cluster argument if so.

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

cat <<EOF >"etcdconfig.yaml"
apiVersion: "kubeadm.k8s.io/v1beta1"
kind: ClusterConfiguration
etcd:
  local:
    extraArgs:
      discovery-srv: "example.com"
EOF

kubeadm init phase etcd local --config=./kubeadmcfg.yaml

Check etcd logs.

Anything else we need to know?

I would be more than happy to contribute with a PR if you think the “expected behavior” is correct.