Automatic merge from submit-queue.
Add --subnets and --utility-subnets to kops create cluster
This change adds two new options to `kops create cluster`
When specifying `--vpc`, `--subnets` can be specified as an unordered array of subnet ids. Kops will then look up the zones of the subnets to find which zone to add the subnet id to.
If `--topology private` is also specified, `--utility-subnets` can similarly be specified.
~If a zone was specified but a subnet wasn't given that matches the zone, then the subnet will be allocated a CIDR with the current behaviour.~ This case fails validation here 7bd0a6a703/pkg/apis/kops/validation/validation.go (L151)
I can add unit tests and docs changes if required, but I am keen to get feedback before I proceed much further.
I have only added support for AWS.
I have tested this by running a command similar to this:
```bash
kops create cluster \
--zones=us-east-1a,us-east-1b,us-east-1c \
--topology private \
--master-zones=us-east-1a,us-east-1b,us-east-1c \
--vpc $vpc_id \
--subnets subnet-111111,subnet-222222,subnet-333333 \
--utility-subnets subnet-444444,subnet-555555,subnet-666666 \
$cluster_hosted_zone_name
```
And the cluster spec was as expected.
Automatic merge from submit-queue.
Add additionalNetworkCIDRs to support VPCs with multiple CIDRs in AWS
Add additionalNetworkCIDRs to support VPCs with multiple CIDRs in AWS.
@justinsb I cannot find anywhere that does a check on an existing VPC to see if the networkCIDR matches what is on the VPC defined, I was looking for that so I can add a similar check for this. Am I missing something or is there really no check like that?
One commit from the always incredible @kris-nova was incorporated here, it was to
check for tags in `kutil/delete_cluster.go`. She was a major driver and instrumental in getting
this to where we aere now!
We separate out the `create cluster` operation from the `update cluster`
operation. Now create cluster only creates the spec (unless you pass
--yes), and is only for new clusters.
`update cluster` works on new or existing clusters, and should be called
to apply changes.
`update` is not the best name, because it means something different in
kubectl, but I think it's a good start.