aks-store-demo-manifests VS flagger

The dev-app Kustomization deploys the GitRepository resource which points to the flux-k8s-ext branch in my AKS Store Demo Manifests repo, and Kustomization resource to deploy the AKS Store Demo application

The great thing about Flux is that it can be bootstrapped using GitOps. So we'll point to a branch in my AKS Store Demo Manifests repo which has everything we need to get the cluster setup quickly.

# navigate to the home directory or wherever you want to clone the repo cd ~ # login to GitHub gh auth login --scopes repo,workflow # fork and clone the repo to your local machine gh repo fork https://github.com/pauldotyu/aks-store-demo-manifests.git --clone # make sure you are in the aks-store-demo-manifests directory cd aks-store-demo-manifests # since we are in a forked repo, we need to set the default to be our fork gh repo set-default # merge the "kustomize" branch into "main" git merge origin/kustomize # push the change up to your fork git push # set the repo url export GITHUB_REPO_URL=$(gh repo view --json url | jq .url -r) # set your GitHub username export GITHUB_USER= # set your GitHub personal access token export GITHUB_TOKEN=

gh repo fork https://github.com/pauldotyu/aks-store-demo-manifests.git --clone # change into the repo directory cd aks-store-demo-manifests

Flagger

Where appropriate, canary releases are an excellent option, as the percentage of traffic exposed to the canary is highly controlled. The trade-off is that the system must have good monitoring in place to be able to quickly identify an issue and roll back if necessary (which can be automated). This guide shows you how to use Apache APISIX and Flagger to quickly implement a canary release solution.

What is Flagger? Flagger is a Progressive Delivery tool that automates the release process for applications running on Kubernetes. Under the hood, both tools are built on top of a modular GitOps toolkit. It is the main reason why Flagger compliments Flux.

flagger: Automated canary using istio/linkerd

I would suggest trying a-b deployment in this case using flagger. It will spin up a new instance and gradually rotate out old ones. Maybe that can be helpful in this weird situation :)

ArgoRollouts offers Canary and BlueGreen deployment strategies for Kubernetes Pods. It's a drop-in replacement for the v1.Deployment object. Flagger is similar what it offers, extending Kubernetes to support Canary and BlueGreen deployment strategies.

Check https://argoproj.github.io/argo-rollouts/ and https://flagger.app/