Currently setting the `--allocate-node-cidrs` flag to true with an
empty cloud provider causes the kube-controller-manager to crash during
startup.
Fix the issue by checking for an empty cloud provider before setting
up route management on the cloud provider. This change introduces a
change in behavior. The kube-controller-manager now supports allocating
pod CIDRs without a cloud provider. This means users must manage routes
through some other mechanism.
The controller manager logs a warning if `--allocate-node-cidrs` is set,
but not a cloud provider:
```
I0725 17:10:41.587888 43185 plugins.go:70] No cloud provider specified.
I0725 17:10:41.588036 43185 nodecontroller.go:114] Sending events to api server.
E0725 17:10:41.588122 43185 controllermanager.go:201] Failed to start service controller: ServiceController should not be run without a cloudprovider.
W0725 17:10:41.588136 43185 controllermanager.go:213] allocate-node-cidrs is set, but no cloud provider specified. Will not manage routes.
E0725 17:10:41.589703 43185 nodecontroller.go:187] Error monitoring node status: Get http://127.0.0.1:8080/api/v1/nodes: dial tcp 127.0.0.1
```
Fixes#11866
This should ensure all load balancers get deleted even if a reordering of
watch events causes us to strand one after its service has been deleted,
because the sync will notice that the service controller's cache has a
service in it that no longer exists in the apiserver.
It could still leak in the case that the controller manager is killed
between when it leaks something and the sync runs, but this should
improve things.
Some versions of docker display image listings like this:
docker.io/golang 1.4 ebd45caf377c 2 weeks ago
The regular expression used to detect presence of images
needs to be updated. It's unfortunate that we're still
screen-scaping here, due to:
https://github.com/docker/docker/issues/8048
We need to find the ID for a named security group, or create a new one.
We do this by listing the security groups, and then doing a create if we
cannot find one. This is a race though; against another thread if the
AWS API were consistent, but generally because the AWS API is actually
eventually consistent.
We wrap it in a retry loop.
When we create a security-group in the AWS API, there is sometimes
a delay before we can tag it (the AWS API is eventually consistent).
So we wrap CreateTags in a simple retry loop.
