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)
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
Removing this flag is reliant on completion of https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190226-network-proxy.md
@nikopen thanks for following up, this won’t be in for v1.14.