Skip to content
This repository has been archived by the owner on Sep 30, 2020. It is now read-only.

v0.15.0
Compare
Choose a tag to compare
@davidmccormick davidmccormick released this 09 Dec 16:49
· 110 commits to master since this release
v0.15.0
7508322
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

Component versions

Kubernetes: v1.15.6
Etcd: v3.3.17
Calico: v3.9.1

Upgrade notes

Cloud Controller Manager

This release introduces a new external cloud-controller-manager that has been separated out of the controller-manager and performs the integration actions between the Kubernetes cluster and AWS cloud features.

WARNING:

This change is breaking if you make use of PersistentVolumes inside of your cluster, you can read more about the limitations here.

Etcd Upgrade

If upgrading from existing kube-aws clusters you must deploy v0.14.2 or higher before upgrading to this release (otherwise you will see a cloud formation error when you try to apply). This release contains a major etcd upgrade to the v3.3.x branch. The upgrade is performed by spinning up a new etcd cluster and copying across the contents from the existing servers. Should the cluster upgrade fail (at any point) then we will roll-back and revert to using the original servers again.

WARNING: it is possible to lose cluster state changes if they are made after the copy has been performed but before all of the kube-apiservers have been replaced or if the cluster roll fails and rolls back to the original servers; therefore we strongly suggest that you perform the upgrade in a maintenance window with customer deployments disabled if possible.

Plugins

The following features have been updated and migrated into plugins and have been removed from the core kube-aws configuration and code: -

  • Kubernetes Dashboard
  • Kiam
  • Kube2IAM

If you use these features - please note that you now need configure them via the plugins section of your cluster.yaml.

Roll NodePools by AvailabilityZone

In this release we make the nodePoolRollingStrategy AvailabilityZone the default choice. You will need to update your cluster.yaml files if you want to continue to use Parallel or Sequential strategies. Rolling by AvailabilityZone is safer than parallel because all nodePools within the same AZ will role in parallel but nodepools across AZs will be rolled one AZ-at-a-time.

Note: The default MaxBatchSize remains at "1" but we invite you to try setting your MaxBatchSize to the same as your maxSize from time-to-time to test what happens in the event of losing an AZ!

Features

Improvements

Assets 4
Loading