Press "Enter" to skip to content

GitOps: Argo Rollouts 1.1 offers integration of notification services

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.

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 RolloutDegraded, RolloutStepCompleted, RolloutPaused or 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.


(map)

Article Source

Disclaimer: This article is generated from the feed and not edited by our team.