Spinnaker 1.17 – What’s New

Spinnaker 1.17 was released on 4th Nov 2019. This release bring in a lot of highlights. Here we share the summary of important improvements.

Improved isolation between Kubernetes V2 accounts

Clouddriver will start up significantly faster for users with many Kubernetes V2 accounts as of Spinnaker 1.17. In addition, an error communicating with one account’s cluster will not affect the functionality of other accounts; users will still be able to see resources for and deploy to unaffected accounts. Prior to this release, an error communicating with one account’s cluster would degrade functionality for other Kubernetes V2 accounts.

Kubernetes Deployment Rolling-Restart Support

After years of demand from the Kubernetes community, a command for initiating a rolling restart of Deployment pods landed in kubectl 1.15 with kubectl rollout restart. Spinnaker now provides first-class support for initiating rolling restarts of Deployment pods alongside Deck’s other ad-hoc infrastructure actions.

GCE Regional Server Group Guest Accelerator Support

Google Compute Engine supports adding additional GPUs to VMs, and there is now first-class support in Spinnaker for configuring additional hardware for the instances of a regional server group with multiple zones explicitly selected.

Fixes to GCE Red/Black Deployments

In a GCE red/black, we previously pinned the source server group’s minimum capacity to its desired capacity before executing the rollout. As of 1.17, we will bring the GCE red/black implementation to parity with the AWS implementation and no longer adjust the source server group’s minimum capacity. The potential drawback to this is that during the period when both the source and target server groups are taking traffic, an autoscaler may scale down the source server group as it will only be taking 50% of the traffic: in the case a rollback is necessary, it will need to scale back up. However, as Netflix has experienced, the potential downsides of pinning the source server group are much worse, as there are many unpredictable ways to get into a state where the server group is never unpinned (see Netflix post-mortem here).

Flexible authorization model

Fiat now accepts permissions coming from different sources. The legacy permissions for applications, for example, are stored inside the application itself in front50. However, it is possible now to provide those permissions from multiple sources (the legacy being one of those sources), and to decide how the permissions coming from those different sources are to be resolved.

For detail and a complete list of the updates, check out the 1.17 changelog