The old upgrade command (which was only called as part of a kube-up ->
kops upgrade) is now `kops toolbox convert-imported`. The docs are
updated, but this is only normally called once per import so this should
not be high impact.
The upgrade command now looks for things that need upgrading. Currently
only `upgrade cluster` is implemented; it currently only checks the
KubernetesVersion. If KubernetesVersion is out of date, it will be
printed, and if --yes is specified the cluster spec will be set to the
next value.
This is the only remaining "magic" setting, which changes externally
- when new versions of k8s are released. (The AMIs are locked in the
instance groups)
We now record the current version of KubernetesVersion in the cluster
spec. It can still easily be changed if needed, but this also means we
don't need to make "fake" changes.
The master is now registered as a Node. It is marked as Unschedulable,
so normal pods will not run on it. But Daemonsets will, and it is
surprising that they don't work unless hostNetwork=true.
The default is now what seems to be expected:
* we allocate the master a real CIDR on the pod network
* kube-proxy runs on the master, so it can talk to pods
* we run kubelet on the master with enable-debugging-handlers, so
kubectl logs etc works
To get the old behaviour, edit the cluster spec and set
`isolateMasters: true`
By reusing the subnet & security groups, we are able to skip the ELB
steps of the upgrade procedure. The new cluster also has the same
identity as the old cluster for security groups, so we don't need to
reconfigure ELB etc.
Fixes#175Fixes#174
Justin Santa Barbara