Disable kubeproxy when creating a kube-router cluster

[rifelpet]

kube-router e2e jobs have been failing for a while: https://prow.k8s.io/view/gcs/kubernetes-jenkins/logs/e2e-kops-aws-cni-kuberouter/1270539617296191488

Completed cluster failed validation: spec.spec.kubeProxy.enabled: Forbidden: kube-router requires kubeProxy to be disabled
172
2020/06/10 02:15:10 process.go:155: Step '/tmp/kops502689941/kops create cluster --name e2e-kops-aws-cni-kuberouter.test-cncf-aws.k8s.io --ssh-public-key /workspace/.ssh/kube_aws_rsa.pub --node-count 4 --node-volume-size 48 --master-volume-size 48 --master-count 1 --zones eu-west-1b --master-size c5.large --kubernetes-version https://storage.googleapis.com/kubernetes-release/release/v1.18.3 --admin-access 35.238.143.128/32 --cloud aws --networking=kube-router --override cluster.spec.nodePortAccess=0.0.0.0/0' finished in 2.563231933s

This should fix the validation error. Existing clusters aren't affected, though they'd also fail validation if they are enabling kubeproxy.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rifelpet

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [rifelpet]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[hakman]

/lgtm

[hakman]

/retest

[olemarkus]

Perhaps it is time to get this one merged #8928
That would be the correct way of fixing this, I think.

[rifelpet]

#8928 would require that someone pass cluster.spec.kubeProxy.enabled=false in their create cluster command right? given that it would be a requirement to have a functional kube-router cluster, wouldnt it make more sense to have that set automatically? But I agree we should get that PR in :) perhaps if no one else has any thoughts on the cli flag or SetClusterFields keys, then we should proceed.

[olemarkus]

Maybe I looked at this incorrectly. You implicitly passing cluster.spec.kubeProxy.enabled=false aren't you? So the spec is correct afterwards. If so, I think maybe just a log line saying that you are implicitly disabling kube-proxy is enough here. Could be that some of the cilium stuff could do the same thing actually.

[rifelpet]

kubeproxy is enabled by default:

https://github.com/kubernetes/kops/blob/master/nodeup/pkg/model/kube_proxy.go#L47-L50

so yes, if create cluster is changing the default behavior, maybe adding a log line here would be a good idea.