There are two distinct categories of cluster update.
cluster.yamland/or TLS assets in
credentials/folder are reflected. To enact this type of update. Modifications to CloudFormation or cloud-config userdata templates will not be reflected. In this case, you do not have to re-render:
kube-aws render stack kube-aws render credentials git diff # view changes to rendered assets kube-aws update
The parameter-level update mechanism can be used to rotate in new TLS credentials and access tokens.
More concretely, steps should be taken in order to rotate your certs on nodes are:
credentials/*.encwhich are cached encrypted certs/keys/tokens to prevent unnecessary node replacement when there's actually no update. See #107 and #237 for more context.
Render new credentials using kube-aws render credentials:
kube-aws render credentials
Execute the update command like:
kube-aws update --s3-uri s3://my/own/path
There is no solution for hosting an etcd cluster in a way that is easily updateable in this fashion- so updates are automatically masked for the etcd instances. This means that, after the cluster is created, nothing about the etcd ec2 instances is allowed to be updated.
Fortunately, CoreOS update engine will take care of keeping the members of the etcd cluster up-to-date, but you as the operator will not be able to modify them after creation via the update mechanism.
In the (near) future, etcd will be hosted on Kubernetes and this problem will no longer be relevant. Rather than concocting overly complex band-aid, we've decided to "punt" on this issue of the time being.
Once you have successfully updated your cluster, you are ready to add node pools to your cluster.