The Argo development team has released version 1.1 of Argo Rollouts. The tool, designed as a delivery operator for Kubernetes, serves as a supplement to the continuous deployment tool Argo CD for the implementation of deployment strategies such as canary releases, A / B tests and blue / green deployments. Although formally only designated as a minor release, Argo Rollouts 1.1 offers a whole range of new functions and improvements – including comprehensive integration with notification services.
Anbindung an Slack, GitHub, Teams & Co.
The notification engine and library, detached from Argo CD and available as a separate operator, now enables Argo rollouts to be directly linked to numerous notification services. In addition to Slack, GitHub, Grafana or Microsoft Teams, email or webhooks can be used for message communication. For every Kubernetes event that is broadcast via a rollout – for example
AnalysisRunFailed – Argo Rollout can be configured in such a way that a notification is sent on the basis of ready-made templates or with individually adapted metadata.
In the new version, the tool can now be configured in such a way that a rollout that does not show any progress within a specified period of time is automatically canceled. In the previous versions this was only done in the course of an examination
AnalysisRun possible. In addition, the Argo team has eliminated a problem that has apparently been a nuisance to many users: When a rollout was aborted, it was not possible to control when or whether a canary or preview stack should be reduced. In addition, there were unintended differences in the behavior of the various update strategies. As of version 1.1, these inconsistencies can be checked using the new field
abortScaleDownDelaySeconds control and define exactly how long a canary or preview stack should remain active after it has been canceled.
With the introduction of the new flag
dynamicStableScale the Argo team has created a way to scale the stable ReplicaSet depending on the traffic. This is intended to remedy an apparently limiting factor for some users that can be traced back to the approach of the ingress or mesh-integrated canary releases. In the course of a canary rollout, the number of running replicas could have doubled – similar to blue / green updates.
Among the other innovations in the release is the option to use the dashboard introduced in version 1.0 from the
kubectl-argo-rollouts-Plug-in can now also be used as an independent service in Kubernetes. However, the Argo team strongly advises against doing this in production environments as there is no authentication possible. An overview of all the improvements in Argo Rollouts 1.1 provides the blog post. Release notes for the updated tools Argo Events and Argo Workflows can be found in the respective GitHub repos.