Skip to content

Release notes for kops 1.15 series

Breaking changes

The kops apiGroup is changing from kops to, which means that downgrading to kops 1.14 after upgrading to kops 1.15 will not recognize the newer objects. (In general it's better not to mix kops versions, but it is more visible here.) Please back up your manifest files using kops get <clustername> -oyaml before upgrading, if the need arises these can later be restored with kops 1.14 with kops replace -f.

It should also be possibe to rewrite the apiGroup fom kops to on a yaml backup using sed or a similar tool, but taking a precautionary backup is safer.

Significant changes

  • kops now supports running with objects as CRDs, stored in a kubernetes apiserver.
  • The apiGroup for kops objects has changed from kops to, to support CRDs. You can continue to provide either apiGroup as input (but you should ideally move to, but the output will always be of the form.
  • Rolling updates are much faster by default. A lot of the time-padding that was in previous versions has been replaced with reliance on validation. The --cloudonly case is much faster than previously, which we believe to be correct because we expect this is normally for disaster-recovery scenarios, but you may want to specify longer timings via flags if you are relying on time-based delays.

Required Actions

  • If checking the output as a string (yaml or json), please note that the apiGroup will now be, not kops. If performing strict string comparison you will need to update your expected values.

  • Kubernetes 1.9 users will need to enable the PodPriority feature gate. This is required for newer versions of kOps.

To enable the Pod priority feature, follow these steps:

kops edit cluster
# Add the following section
      PodPriority: "true"

Full change list since 1.14.0 release

kops 1.14.0-beta.2 to 1.15.0-alpha.1

kops 1.15.0-alpha.1 to 1.15.0-beta.1

1.15.0-beta.1 to 1.15.0

1.15.0 to 1.15.1

1.15.1 to 1.15.2

1.15.2 to 1.15.3