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.
This is to permit users to add tags to the ASG.
The long-term fix is to allow specification of additional tags at the
cluster level; the canonical use-case is for the AWS billing tags.
Issue #241
This means it only needs to be specified during `kops create`. We
remove the option from `kops update` for consistency.
This will shortly be manageable using the secrets functionality.
Fix#221
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`
We currently don't do discovery of existing resources when running with
Terraform output, but when using a shared VPC this is wrong - we need to
reuse the existing gateway.
Directly discover the existing gateway. We might need to do full
discovery later, but for now this is sufficient.
Fix#181
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
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.
Justin Santa Barbara