Announcing Flagger 1.0
We're happy to announce the first release candidate of Flagger 1.0! Version 1.0 comes with the promise of a stable API. The canary resource is no longer alpha and the API has been extended to facilitate integrations with external monitoring systems and alerting platforms.
We're happy to announce the first release candidate of Flagger 1.0! Version 1.0 comes with the promise of a stable API. The canary resource is no longer alpha and the API has been extended to facilitate integrations with external monitoring systems and alerting platforms.
A bit of history
The project started in 2018 with the goal of creating a declarative model for decoupling the deployment of apps on Kubernetes from the release process. To make production releases safer, Flagger would control the traffic routing and expose the new app version to a percentage of the users while measuring service level objectives (SLOs) like availability, error rate percentage and average response time. If a drop in performance is noticed during the SLOs analysis, the release will be automatically rolled back with minimum impact to end-users.
To automate the release process, Flagger was built on top of Istio as a Kubernetes operator that instructs the service mesh to progressively route traffic between app versions. In 2019 Linkerd gained traffic split capabilities via SMI and Amazon released AWS App Mesh, a service mesh based on Envoy. In order to integrate with App Mesh and Linkerd, Flagger was refactored to allow different routing solutions to be plugged-in.
Not all organizations are ready to adopt a service mesh solution, so Flagger also added support for Kubernetes ingress controllers. Due to its popularity, NGINX was the first ingress supported by Flagger followed by Gloo and Contour, two modern ingress controllers based on Envoy.
Progressive traffic shifting is not suitable for all types of apps, as a result, Flagger was refactored once more to support A/B Testing for front-end apps that require session affinity and Blue/Green mirroring for backend apps.
With Flagger getting more traction, users asked for ways to run integration and conformance tests as part of the release process. To make the analysis extensible, web hooks were introduced as a way to trigger external systems that would run the tests against the canary version and report the results back to Flagger.
What's new in 1.0
Flagger 1.0 comes with many improvements and changes to the API. If you're upgrading from 0.x please follow this guide.
Metric Templates
In the previous version, using custom metrics was limited to Prometheus and the query had to be inlined in the analysis spec. To overcome these limitations, Flagger 1.0 introduces a new API resource called metric template. Metric templates allow you to target external monitoring systems, the queries can be parameterized, and shared across namespaces and canary objects. As of RC.1, Flagger supports Prometheus, Datadog and Amazon CloudWatch as metric providers with more to come.
Alerting
In the previous version, configuring alerting was done globally which has several limitations, it wasn't possible to specify different channels or to configure the verbosity on a per canary basis. Flagger 1.0 introduces a new API resource called alert provider. To make the alerting more flexible, the analysis can be extended with a list of alerts that reference an alert provider. As of RC.1, Flagger supports Slack, Microsoft Teams, Discord and Rocket.
Istio improvements
Flagger 1.0 can be used in multi-cluster environments by installing it on each cluster and by connecting all instances to the Istio shared control plane. Customising the Istio traffic policy, CORS, retries and header operations are now fully supported. When upgrading to Istio 1.5, due to breaking changes in Istio telemetry v2, you'll need to make some adjustments to the analysis metrics. A guide on using Flagger with Istio telemetry v2 is available here.
I would like to thank everyone who contributed to this release with code, tests and feedback. Thank you very much!
What's next
We're going to do a GA release in the following days if we don't discover any issues with the release candidate.
As for Flagger's 2020 roadmap, we plan to:
- add support for Kubernetes Ingress v2
- extend support for other service meshes that implement SMI
- add more metric providers like Stackdriver and InfluxDB
Contributing
I'm very happy to announce that Takeshi Yoneda has joined me as a maintainer of Flagger. Takeshi works for DMM.com, a japanese company that uses Flagger extensively in production for web applications and ML workloads. He’s made valuable contributions implementing DaemonSet support, Datadog and CloudWatch analysis, canary weighted mirroring and so much more.
If you're looking for an open source project to contribute to, please consider Flagger. We've made available a development guide to help you get started. If you have any questions about Flagger or progressive delivery, invite yourself to the Weave community slack and join the #flagger channel.
If you're using Flagger at work, please add your organization to the user list here.
Want to ask Stefan some Flagger questions?
Join the DX team and Stefan Prodan on April 7th for a special WOUG on Flagger 1.0.
Title: What's New In Flagger v1.0 with Stefan Prodan
Time: 10:00 - 11:00 PT / 18:00 - 19:00 UK Time
--------------------------------------------------------------
Speaker: Stefan Prodan, Developer Experience Engineer, Weaveworks
Host: Tamao Nakahara, Head of Developer Experience, Weaveworks
In this session, Stefan will talk about how Flagger was born and how the project evolved since its first alpha release in late 2018. He will give an overview of Flagger's main features and highlight the API changes in version 1.0. We will discuss the 2020 roadmap as well as future plans for an integration with Kubernetes Ingress v2.
To learn about future talks from the Weave Online User Group (WOUG) sign up here.
