Canary Deployments

a canary deployment is a progressive rollout of an application that splits traffic between an already deployed version and a new version, rolling it out to a subset of users before rolling out fully you can choose randomly or a specific group of users and roll back if anything breaks if everything works as intended, you can gradually add more users while monitoring logs, errors, and software health getting started there are five core steps to support a blue green deployment for an existing kubernetes deployment ensure your target (destination) kubernetes cluster(s) have the argo rollouts controller installed (see install deploynow agent https //docs opsverse io/install the deploynow agent for more info) in your manifest/template, replace kind deployment to kind rollout in your manifest/template, replace apiversion apps/v1 to apiversion argoproj io/v1alpha1 in your manifest/template, replace spec strategy with canary and add any specific configurable features https //argoproj github io/argo rollouts/features/canary/#other configurable features you like in your manifest/template, configure the steps for your canary release rollout in spec strategy canary steps example a good sample app to show off this feature is the argo rollouts canary example https //github com/argoproj/rollouts demo/blob/master/examples/canary/canary rollout yaml manifest !!! note this sample app is a simple sample of canary deployments you can further configure this example for more flexibility as required using the argo rollouts docs https //argo rollouts readthedocs io/en/stable/features/canary/ say we have a manifest, canary rollout yaml , like so \# this example demonstrates a rollout using the canary update strategy, which rolls out the new deployment apiversion argoproj io/v1alpha1 kind rollout metadata name canary demo spec replicas 5 revisionhistorylimit 1 selector matchlabels app canary demo template metadata labels app canary demo spec containers \ name canary demo image argoproj/rollouts demo\ blue imagepullpolicy always ports \ name http containerport 8080 protocol tcp resources requests memory 32mi cpu 5m strategy canary steps \ setweight 20 \ pause {duration 30s} \ setweight 40 \ pause {duration 30s} \ setweight 60 \ pause {duration 30s} \ setweight 80 \ pause {duration 30s} you can add a manual approval step as part of the release using pause {} create an argo app which points to this manifest update to a new version of the app now, let's update our git repo to change the version from blue to green when your argo app is next synced, you will see the canary rollout as per the configuration above, first 20% of the traffic will be sent to the blue pods, then the deployment will pause for 30s, then 20% more of the traffic will go to the blue pods (for a total weight of 40%) and so on until 100% traffic split to canary pods is best effort by default for example if you have 3 pods, and set weight of canary to 25%, rounding up will be done and 1 pod will serve the canary release while 2 will serve the stable release for more fine grained control over traffic, you can tie in argo rollouts to your existing routing tools like istio, nginx, aws alb, traefik etc use these docs for more details if you want to configure your canary release to have progressive rollout dependent on passing some preconfigured metrics, you can take a look at the canary deployments with analysis https //docs opsverse io/canary deployments with analysis docs