How to use GitOps and Progressive Delivery with Flux, Flagger, & Istio
Catch up on another GitOps Days talk with Marco Amador, Anova on the topic of "How to use GitOps and Progressive Delivery with Flux, Flagger, & Istio"
At the recent GitOps Days 2022 conference Marco Amador, Chapter Lead for Data Engineering and SRE at Anova gave a talk on GitOps and Progressive Delivery with Flux, Flagger, & Istio. Marco describes Anova’s journey into progressive delivery with some hands-on demos and explains why they’ve chosen progressive delivery on their multi-cluster and multi-region Kubernetes cluster. Anova is the leading global provider of Industrial Internet of Things (IIoT) solutions to remotely monitor and manage industrial assets.
The Need for Change: Unify Platforms
Anova is only a three-year-old company, but it is the result of a merger of five well-established companies: DataOnline, Wesroc, Wikon, ISA, & Silicon Controls. With that came five different platforms and five different ways to build and release software. This created the need for one unified solution - this solution is called Unify.
The Unify tech stack consists of Kubernetes, Istio / Envoy, Flux, Helm / Kustomize, Flagger, Observability tools (Prometheus / Thanos, Alert Manager, Grafana, Loki, Tempo, Sloth), SOPS, Kyverno / Gatekeeper, Kube-Metrics-Adapter, External-DNS, and Cert-Manager.
There were 5 major considerations for the platform as it was architected:
- Scalability: The platform needs to scale horizontally and the clusters and workloads have to autoscale according to load.
- Multi-geography & Multi-Region: Anova has customers in different geo-locations that need their data segregated accordingly. There are also multi-regions within those geographies mostly for redundancy and data replication.
- Multi-environment: There are multiple environments (sandbox, staging, production) in each of those regions as well.
- Security: Security was top of mind building the platform from scratch, and to enforce security policies regarding infrastructure as code (IaC), workloads, and so on.
- Multi-tenancy: Have multiple teams/products that need to have complete ownership of their releases. Multiple namespaces in K8s for multiple tenants. For example, a tenant would be a product team where they would have their own namespace
GitOps and Progressive Delivery with Flux, Flagger, & Istio
Marco walks through their git repo setup to show how they have a main repository for the platform team where they define environments and their tech stack including their istio service mesh and their observability stack. This is also where they define the product teams as tenants. Each tenant has its own git repository where they declare the manifests for each service for different environments and regions. He highlights that due to the many environments and regions, they use Helm and Kustomize to avoid duplication. Marco then walks through example repositories to show the structure they use.
Marco continues to explain how they use Flux’s image automation feature to manage updates. In a nutshell, they use the Flux image automation controllers to update a Git repository when new container images are available. They specify in their ImagePolicy what versions are allowed to be deployed. If the version requirement is met and the update is made, they will have a new version rolling out in their cluster.
With this Setup, why Would you Want to Use Progressive Delivery?
As Marco mentions, a lot of things can go wrong when you roll out a new version. You could be introducing regressions, errors, incorrect dependencies; the integration tests may not be as good as they should be and even though everything seems okay, latency could be affected. For progressive delivery, they use Flagger, which supports multiple deployment strategies, such as canary, A/B, and Blue/Green. In this video segment Marco explains their canary deployment process including how they use k6, which is an open source load testing tool. He also shows the dashboards they use to monitor the canary during the process.
They also use feature flags to release new versions of a service with a major change. Using this process they can release a new version only to a specific set of users. He explains more on this process and the tools they use as well as showing a detailed explanation. In the demo he shows an example of a canary deployment with a minor version change and then shows what it would look like with dark launch enabled for a major version change.
By using progressive delivery, you are able to ship new code faster, reduce risk, and continuously improve customer experience. We hope this talk helps you springboard your own progressive delivery journey, using Flux & Flagger.
Here’s the video in its entirety if you’d like to watch from start to finish:
Next Steps
Want to chat with us? Invite yourself at https://slack.weave.works and hang out with us at #gitopsdays We’ll be publishing more blog posts along with videos from the event to our GitOps Days 2022 Playlist, so stay tuned for more as they become available. And don’t forget to subscribe to our YouTube channel!
Experience how easy it is to enable GitOps and run your apps in a cluster. Try Weave GitOps Core, it’s free and open source and it’s powered by Flux!
Get StartedTrusted Application Delivery: Achieving Ultimate Security
Join us on July 14 for a live webinar where we discuss to simplify the shifting left of security and accelerate the adoption of DevSecOps practices with GitOps on EKS.
