kubernetes: Kubernetes API Server should not depend on --cloud-provider and --cloud-config

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug

/kind feature

What happened: I was quite surprised to see --cloud-config and --cloud-provider in the api server when reviewing some code around openstack cloud provider. Turned out that this was needed by a single admission controller, namely PersistentVolumeLabel

What you expected to happen:

I expect kube-controller-manager and kubelet to depend on cloud-provider but NOT the api server.

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

[dims@bigbox 14:33] ~ ⟩ hyperkube apiserver --help 2>&1 | grep "cloud"
      --cloud-config string                                     The path to the cloud provider configuration file. Empty string for no configuration file.
      --cloud-provider string                                   The provider for cloud services. Empty string for no provider.

Anything else we need to know?:

Environment:

  • Kubernetes version (use kubectl version):
  • Cloud provider or hardware configuration**:
  • OS (e.g. from /etc/os-release):
  • Kernel (e.g. uname -a):
  • Install tools:
  • Others:

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 1
  • Comments: 48 (41 by maintainers)

Most upvoted comments

The complication is there regardless of whether it is built into the api server or not, and the tunneling built into the api server is opaque, not as robust as dedicated vpn solutions, and has been repeatedly problematic.

@ericchiang Now remember, I was thinking about the node dialer talking to the cloud provider re: installing SSH keys: https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-apiserver/app/server.go#L212-L241

Only provider that implements this AddSSHKeyToAllInstances function in the cloudprovider interface is GCE. I’m asking whether this is actually required anymore or if we can deprecate and remove…

I’d like to see the tunneling feature removed. If a particular deployment topology requires it, I would expect that deployment to set up VPN–style tunneling for specific IP ranges, rather than adding complexity throughout the API server

/triage accepted

@nikopen thanks for following up, this won’t be in for v1.14.