{"id":26242118,"url":"https://github.com/kostis-codefresh/rollouts-autoscaling-example","last_synced_at":"2025-08-20T06:40:23.819Z","repository":{"id":279241961,"uuid":"938170628","full_name":"kostis-codefresh/rollouts-autoscaling-example","owner":"kostis-codefresh","description":"Example for using Argo Rollouts with autoscaling ","archived":false,"fork":false,"pushed_at":"2025-03-07T07:36:08.000Z","size":4784,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-03-13T09:43:10.274Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/kostis-codefresh.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2025-02-24T14:32:21.000Z","updated_at":"2025-03-07T07:36:11.000Z","dependencies_parsed_at":null,"dependency_job_id":"e89bb48b-0dac-453f-a562-4d10a2447d55","html_url":"https://github.com/kostis-codefresh/rollouts-autoscaling-example","commit_stats":null,"previous_names":["kostis-codefresh/rollouts-autoscaling-example"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/kostis-codefresh/rollouts-autoscaling-example","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kostis-codefresh%2Frollouts-autoscaling-example","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kostis-codefresh%2Frollouts-autoscaling-example/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kostis-codefresh%2Frollouts-autoscaling-example/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kostis-codefresh%2Frollouts-autoscaling-example/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/kostis-codefresh","download_url":"https://codeload.github.com/kostis-codefresh/rollouts-autoscaling-example/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kostis-codefresh%2Frollouts-autoscaling-example/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":271279376,"owners_count":24731901,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-08-20T02:00:09.606Z","response_time":69,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-03-13T09:43:20.913Z","updated_at":"2025-08-20T06:40:23.791Z","avatar_url":"https://github.com/kostis-codefresh.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Common Autoscaling scenarios with Argo Rollouts\n\nThe default behavior of [Argo Rollouts](https://argoproj.github.io/rollouts/) is to launch the same number of pods as the stable version \nfor Blue/green deployments or the relative number of pods for canaries as with the current traffic switch.\n\nThis simple behavior can affect the cost of the infrastructure especially in the case of Kubernetes clusters that reside in Cloud providers.\n\nIn this repository we show several approaches of minimizing the cost of Progressive Delivery.\n\n## The example application\n\nFor all examples we use a [simple GoLang application](source-code). This application\nhas the following behavior\n\n* Every time a call is made to `/` it reserves 1MB of memory\n* If you call `/clear` it releases all memory reserved so far\n\nYou can use this technique to trigger [the autoscaler](https://argo-rollouts.readthedocs.io/en/stable/features/hpa-support/) in all examples that use [HPA](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)\nby simulating a pod that requires additional memory.\n\n## Table of contents\n\n1. [Prerequisites](#prerequisites)\n1. [Example 01 - Base case for Blue/Green](#example-01---base-case-for-bluegreen)\n1. [Example 02 - Custom number for pods for preview version](#example-02---custom-number-for-pods-for-preview-version)\n1. [Example 03 - Blue/Green with autoscaling](#example-03---bluegreen-with-autoscaling)\n1. [Example 04 - Blue/Green with autoscaling and custom number of pods](#example-04---bluegreen-with-autoscaling-and-custom-number-of-pods)\n1. [Example 05 - Base case for Canary](#example-05---base-case-for-canary)\n1. [Example 06 - Canary without Traffic manager](#example-06---canary-without-traffic-manager)\n1. [Example 07 - Canary with dynamic scaling](#example-07---canary-with-dynamic-scaling)\n1. [Example 08 - Canary with decoupled traffic split](#example-08---canary-with-decoupled-traffic-split)\n1. [Example 09 - Canary with autoscaling](#example-09---canary-with-autoscaling)\n1. [Example 10 - Canary with autoscaling and decoupled traffic split](#example-10---canary-with-autoscaling-and-decoupled-traffic-split)\n\n\n## Prerequisites\n\nGet access to a local cluster such as k3s, docker-for-desktop, k3d etc\n\n[Install Argo Rollouts](https://argo-rollouts.readthedocs.io/en/stable/installation/):\n\n```\nkubectl create namespace argo-rollouts\nkubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml\n```\n\nInstall the CLI\n\n```\ncurl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64\nchmod +x ./kubectl-argo-rollouts-linux-amd64\nsudo mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts\n```\n\n\nIf your local cluster doesn't have metrics then install [the Metrics Server](https://github.com/kubernetes-sigs/metrics-server) for all HPA examples:\n\n```\ncd metrics-072\nkubectl apply -f components.yaml\n(Wait 2 minutes)\nkubectl top nodes\n```\n\nThe last command should show you metrics for your nodes.\n\nInstall Traefik 2.x for the all the canary examples. If your local cluster already has Traefik 2.x pre-installed you can skip this step.\n\n```\nhelm repo add traefik https://traefik.github.io/charts\nhelm repo update\nhelm install traefik traefik/traefik --version 27.0.2\n```\n\nInstall a load testing tool such as [siege](https://github.com/JoeDog/siege), [hey](https://github.com/rakyll/hey), [bombardier](https://github.com/codesenberg/bombardier), [k6s](https://github.com/grafana/k6), [locust](https://locust.io/), [gatling](https://gatling.io/) etc.\n\nYou can also use your browser to increase the memory of the example in order to trigger the autoscaler.\n\n\n### Inspecting the rollouts\n\nYou can use the Argo Rollouts CLI to inspect your rollouts or run\n\n```\nkubectl argo rollouts dashboard\n```\n\nAnd then visit `http://localhost:3100/rollouts` to see the Argo Rollouts dashboard.\n\n## Example 01 - Base case for Blue/Green\n\nThis shows a Blue/Green example with default options\n\n```\ncd 01-baseline-bg\nkubectl apply -f .\n```\n\nWait for all pods to be healthy\n\n```\nkubectl argo rollouts get rollout 01-baseline-bg\n```\n\nStart a new color\n\n```\nkubectl argo rollouts set image 01-baseline-bg cost-demo=ghcr.io/kostis-codefresh/rollouts-autoscaling-example:v2\n```\n\nIf you visit the Argo Rollouts dashboard you will see the following\n\n![double cost for blue/green](pictures/double-cost.png)\n\nNotice that now we have double the number of pods. Even though the stable version has 10 pods we also launch 10 more pods for the preview version. **So we pay 2x costs while we are testing the new version**.\n\nPromote the new version with:\n\n```\nkubectl argo rollouts promote 01-baseline-bg\n```\n\nAll old pods are destroyed and we are back to 1x cost.\n\nClean up with\n\n```\nkubectl delete -f .\n```\n\n\n\n## Example 02 - Custom number for pods for preview version\n\nWe can use the `previewReplicaCount` property to change the number of pods that are used for the preview version. Take a look at [02-custom-preview-bg/rollout.yaml#L11](02-custom-preview-bg/rollout.yaml#L11).\n\nWe have defined `previewReplicaCount: 5` to use only 5 pods while testing the new version.\n\n\n```\ncd 02-custom-preview-bg\nkubectl apply -f .\n```\n\nWait for all pods to be healthy\n\n```\nkubectl argo rollouts get rollout 02-custom-preview-bg\n```\n\nStart a new color\n\n```\nkubectl argo rollouts set image 02-custom-preview-bg cost-demo=ghcr.io/kostis-codefresh/rollouts-autoscaling-example:v2\n```\n\nIf you visit the Argo Rollouts dashboard you will see the following\n\n![Custom blue green](pictures/custom-blue-green.png)\n\n\nNotice that now we have only 5 pods for preview version instead of 10. **So we cut down our costs for 50% while we are testing the new version**.\n\nPromote the new version with:\n\n```\nkubectl argo rollouts promote 02-custom-preview-bg\n```\n\nNotice that Argo Rollouts correctly launches all 10 pods for the new version after promotion.\n\nClean up with\n\n```\nkubectl delete -f .\n```\n\n## Example 03 - Blue/Green with autoscaling\n\nIn this example we have an [autoscaler](03-hpa-bg/hpa.yaml) for our Rollout. It defines minimum pods as 1 and maximum as 10. It monitors memory usage for our pods.\n\n```\ncd 03-hpa-bg\nkubectl apply -f .\n```\n\nWait for all pods to be healthy\n\n```\nkubectl argo rollouts get rollout 03-hpa-bg\n```\n\nNotice that we only have 1 pod. \n\nWait for autoscaler to be ready. Run `kubectl describe hpa` and wait until you see `ScalingActive   True` \n\nPort forward with:\n\n```\nkubectl port-forward svc/argo-rollouts-stable-service 8000:80\n```\n\nAnd then visit `http://localhost:8000` multiple times to reserve more memory.\n\nWait until the autoscaler creates more pods.\n\nStart a new color\n\n```\nkubectl argo rollouts set image 03-hpa-bg cost-demo=ghcr.io/kostis-codefresh/rollouts-autoscaling-example:v2\n```\n\nIf you visit the Argo Rollouts dashboard you will see the following\n\n![Blue/Green with autoscaling](pictures/blue-green-as.png)\n\n\nNotice that the new version has as many pods as the autoscaler had when we started the deployment. **So if a Blue/Green deployment starts under heavy traffic the preview pods will be able to handle the load that was present at that point in time**.\n\nAlso if you continue reserving memory, Argo Rollouts will launch more pods for both the preview and stable replicasets.\n\n![Blue/Green with autoscaling 2](pictures/blue-green-as-2.png)\n\nPromote the new version with:\n\n```\nkubectl argo rollouts promote 03-hpa-bg\n```\n\nClean up with\n\n```\nkubectl delete -f .\n```\n\n## Example 04 - Blue/Green with autoscaling and custom number of pods\n\nIn this example we have an [autoscaler](03-hpa-bg-custom/hpa.yaml) for our Rollout. It defines minimum pods as 1 and maximum as 10. It monitors memory usage for our pods. \n\nWe have also defined `previewReplicaCount: 3` to use only 3 pods while testing the new version.\n\n\n```\ncd 04-hpa-bg-custom\nkubectl apply -f .\n```\n\nWait for all pods to be healthy\n\n```\nkubectl argo rollouts get rollout 04-hpa-bg-custom\n```\n\nNotice that we only have 1 pod. \nWait for autoscaler to be ready. Run `kubectl describe hpa` and wait until you see `ScalingActive   True` \n\nPort forward with:\n\n```\nkubectl port-forward svc/argo-rollouts-stable-service 8000:80\n```\n\nAnd then visit `http://localhost:8000` multiple times to reserve more memory.\nWait until the autoscaler creates more pods (for example 8).\n\nStart a new color\n\n```\nkubectl argo rollouts set image 04-hpa-bg-custom cost-demo=ghcr.io/kostis-codefresh/rollouts-autoscaling-example:v2\n```\n\nIf you visit the Argo Rollouts dashboard you will see the following \n\n![Blue/Green with autoscaling and custom replicas](pictures/blue-green-as-custom.png)\n\nNotice that the new version has only 3 pods as we defined in `previewReplicaCount`. **So previewReplicaCount always overrides the current autoscaling decision**.\n\nAlso if you continue the load testing, Argo Rollouts will launch more pods only for the stable version. The preview version will always have 3 pods. \n\n![Blue/Green with autoscaling and custom replicas 2](pictures/blue-green-as-custom-2.png)\n\n**Use previewReplicaCount with caution as it will always take effect regardless of the current load and what the autoscaler does**.\n\nPromote the new version with:\n\n```\nkubectl argo rollouts promote 04-hpa-bg-custom\n```\n\nClean up with\n\n```\nkubectl delete -f .\n```\n\n## Example 05 - Base case for Canary\n\nThis shows a Canary example with default options\n\n```\ncd 05-baseline-canary\nkubectl apply -f .\n```\n\nWait for all pods to be healthy\n\n```\nkubectl argo rollouts get rollout 05-baseline-canary\n```\n\nStart a new canary deployment:\n\n```\nkubectl argo rollouts set image 05-baseline-canary cost-demo=ghcr.io/kostis-codefresh/rollouts-autoscaling-example:v2\n```\n\nIf you visit the Argo Rollouts dashboard you will see the following\n\n![20 percent](pictures/20-percent.png).\n\nThe canary pods are always the same ratio as current traffic.\nPromote the rollout multiple times with \n\n```\nkubectl argo rollouts promote 05-baseline-canary\n```\n\n![70 percent](pictures/70-percent.png).\n\nYou can see that at all stages we pay for the stable version of pods PLUS the canary ones.  **So when the canary is at 80%-90%-100% we pay almost 2x the costs to test the new version.**\n\n![100 percent](pictures/100-percent.png).\n\n\nAfter promotion has finished the old pods are destroyed and we are back to 1x cost.\n\nClean up with\n\n```\nkubectl delete -f .\n```\n\n## Example 06 - Canary without Traffic manager.\n\n\nIf you don't use a traffic manager Argo Rollouts will use the pod count\nto split traffic between preview version and stable version. This means\nthat as the traffic advances the number of preview pods go up and the number\nof stable pods go down.\n\n```\ncd 06-canary-wtm\nkubectl apply -f .\n```\n\nWait for all pods to be healthy\n\n```\nkubectl argo rollouts get rollout 06-canary-wtm\n```\n\nStart a new canary deployment:\n\n```\nkubectl argo rollouts set image 06-canary-wtm cost-demo=ghcr.io/kostis-codefresh/rollouts-autoscaling-example:v2\n```\n\nIf you visit the Argo Rollouts dashboard you will see the following in the different phases of the canary.\n\n![Without traffic manager](pictures/wtm.png).\n\nThe canary pods increase with traffic while stable pods decrease with the inverse ration. The number of pods is always constant.\n\nPromote the canary multiple times with:\n\n```\nkubectl argo rollouts promote 06-canary-wtm\n```\n\nAfter promotion has finished the old pods are destroyed and only the new pods remain.\n\nClean up with\n\n```\nkubectl delete -f .\n```\n\n**While this method matches expected user behavior it has several disadvantages**. Apart from missing all the advanced features of a traffic manager, it is a bit more risky in the case of an abort as stable pods are less in number and will need to be scaled back up again.\n\nSee the next example on how to replicate this behavior and still use a traffic manager.\n\n## Example 07 - Canary with dynamic scaling\n\nIf you use a traffic manager and like the scaling behavior of the previous example\nwhere stable pods are reduced when preview pods are increased then this can be done \nwith the `dynamicStableScale` property available to canaries.\n\n```\ncd 07-dynamic-canary\nkubectl apply -f .\n```\n\nWait for all pods to be healthy\n\n```\nkubectl argo rollouts get rollout 07-dynamic-canary\n```\n\nStart a new canary deployment\n\n```\nkubectl argo rollouts set image 07-dynamic-canary cost-demo=ghcr.io/kostis-codefresh/rollouts-autoscaling-example:v2\n```\n\nIf you visit the Argo Rollouts dashboard you will see again a constant number of pods. When new canary pods are launched the same the following in the different phases of the canary.\n\n![Dynamic](pictures/dynamic-canary.png).\n\nThe canary pods increase with traffic while stable pods decrease with the inverse ration. The number of pods is always constant.\n\nPromote the canary multiple times with:\n\n```\nkubectl argo rollouts promote 07-dynamic-canary\n```\n\nAfter promotion has finished the old pods are destroyed and only the new pods remain.\n\nClean up with\n\n```\nkubectl delete -f .\n```\n\n**This means you can keep a constant cost for your cluster even when using a canary with a traffic manager**.\n\n## Example 08 - Canary with decoupled traffic split\n\nThe big advantage of using a traffic provider is that you can decouple completely the number of preview pods with the amount of traffic they get. \n\nTake a look at [the decoupled rollout](08-decoupled-canary/rollout.yaml) for an example. Here we define arbitrary traffic percentages.\n\n```yaml\nsteps:\n- setWeight: 20\n- setCanaryScale: \n    replicas: 1\n- pause: {}\n- setWeight: 50\n- setCanaryScale: \n    replicas: 3\n- pause: {}\n- setWeight: 90\n- setCanaryScale: \n    replicas: 5\n- pause: {}\n- setWeight: 100\n- setCanaryScale:        \n    replicas: 8\n```\n\nThe first pod will get 20% of traffic (instead of the default 10%). Then 3 preview pods will get 50% of traffic (instead of the default 30%). This way you can do any possible combination between the number of pods and their traffic.\n\nYou can always switch back to the default behavior by using the `matchTrafficWeight: true` property. \n\n```\ncd 08-decoupled-canary\nkubectl apply -f .\n```\n\nWait for all pods to be healthy\n\n```\nkubectl argo rollouts get rollout 08-decoupled-canary\n```\n\nStart a new canary deployment\n\n```\nkubectl argo rollouts set image 08-decoupled-canary cost-demo=ghcr.io/kostis-codefresh/rollouts-autoscaling-example:v2\n```\n\nIf you visit the Argo Rollouts dashboard you will see again a constant number of pods. When new canary pods are launched the same the following in the different phases of the canary.\n\n![Decoupled canary](pictures/decoupled-canary.png)\n\nWhen we reach 100% of traffic we use 5 pods instead of 10. **This cuts our costs by 50% compared to not using a traffic provider**.\n\nPromote the canary multiple times with:\n\n```\nkubectl argo rollouts promote 08-decoupled-canary\n```\n\nAfter promotion has finished the old pods are destroyed and only the new pods remain.\n\nClean up with\n\n```\nkubectl delete -f .\n```\n\n**Using a traffic manager is the most flexible option as it allows to define exactly the costs for your preview pods**.\n\n\n## Example 09 - Canary with autoscaling\n\nIn this example we have an [autoscaler](09-hpa-canary/hpa.yaml) for our Rollout. It defines minimum pods as 1 and maximum as 10. It monitors memory usage for our pods.\n\n```\ncd 09-hpa-canary\nkubectl apply -f .\n```\n\nWait for all pods to be healthy\n\n```\nkubectl argo rollouts get rollout 09-hpa-canary\n```\n\nNotice that we only have 1 pod. \n\nWait for autoscaler to be ready. Run `kubectl describe hpa` and wait until you see `ScalingActive   True` \n\nPort forward with:\n\n```\nkubectl port-forward svc/rollout-canary-preview 8000:80\n```\n\nVisit `http://localhost:8000` in your browser and click the \"refresh\"\nbutton until used memory shows about 50MB. \n\nWait until the autoscaler creates more pods. You can monitor HPA with\n`watch kubectl describe hpa`. At some point you will have 4 pods in your application.\n\nStart a new canary deployment\n\n```\nkubectl argo rollouts set image 09-hpa-canary cost-demo=ghcr.io/kostis-codefresh/rollouts-autoscaling-example:v2\n```\n\nIf you visit the Argo Rollouts dashboard you will see the following\n\n![Canary autoscaling start](pictures/canary-as-start.png)\n\nA single pod has been launched and gets 20% of the traffic. Promote the canary once\nwith \n\n```\nkubectl argo rollouts promote 09-hpa-canary\n```\n\nNow the canary is at 50%. You will see that Argo Rollouts will now launch 2 canary pods since the stable version has 4.\n\n![Start with 50 per cent](pictures/instant-50.png)\n\nNow you can keep increasing memory and see that Argo Rollouts constantly launches new\npods in order to keep the canary traffic always at 50%.\n\n- Increase memory gradually to 80MB. You should have 8 stable pods and 4 canary pods\n- Increase memory gradually to 120MB. You should have 10 stable pods and 5 canary pods\n\n![Canary follows scaling](pictures/canary-as2.png)\n\n**So if an autoscaler is active Argo Rollouts will constantly change the preview pods to match the required canary percentage as the stable pods go up or down.**.\n\nPromote the canary multiple times with:\n\n```\nkubectl argo rollouts promote 09-hpa-canary\n```\n\nAfter promotion has finished the old pods are destroyed and only the new pods remain.\n\nClean up with\n\n```\nkubectl delete -f .\n```\n\n## Example 10 - Canary with autoscaling and decoupled traffic split\n\nIn this example we use both an autoscaler and a specific number of pods\nin each canary step (instead of the default weight-based percentage).\n\n```\ncd 10-hpa-canary-decoupled\nkubectl apply -f .\n```\n\nWait for all pods to be healthy\n\n```\nkubectl argo rollouts get rollout 10-hpa-canary-decoupled\n```\n\nNotice that we only have 1 pod. \n\nWait for autoscaler to be ready. Run `kubectl describe hpa` and wait until you see `ScalingActive   True` \n\nPort forward with:\n\n```\nkubectl port-forward svc/rollout-canary-preview 8000:80\n```\n\n\n\nWait until the autoscaler creates more pods. You can monitor HPA with\n`watch kubectl describe hpa`. \n\nStart a new canary deployment\n\n```\nkubectl argo rollouts set image 10-hpa-canary-decoupled cost-demo=ghcr.io/kostis-codefresh/rollouts-autoscaling-example:v2\n```\n\nIf you visit the Argo Rollouts dashboard you will see the following\n\n![Canary full start](pictures/full-20.png)\n\nA single pod has been launched and gets 20% of the traffic. Promote the canary once\nwith \n\n```\nkubectl argo rollouts promote 10-hpa-canary-decoupled\n```\n\nNow the canary is at 50%. Canary pods will be exactly 3 because this is what you defined in the Rollout spec.\n\nVisit `http://localhost:8000` in your browser and click the \"refresh\"\nbutton to consume more memory. \n\nNow you can keep increasing memory and see that only the stable pods increase. \nThe canary pods are in the exact number that you defined in the Rollout Specification.\nNotice however that the autoscaler looks into both canary and stable pods in order to take a decision.\n\n- Increase memory gradually to 80MB. You should have 4 stable pods and 3 canary pods\n- Increase memory gradually to 100MB. You should have 8 stable pods and 3 canary pods\n- Increase memory gradually to 120MB. You should have 10 stable pods and 3 canary pods\n\n![Autoscaler only tampers with stable pods](pictures/full-canary-as.png)\n\n**So if an autoscaler is active Argo Rollouts and you have defined explicitly the number of canary pods, the autoscaler will only tamper with stable pods**.\n\nPromote the canary multiple times with:\n\n```\nkubectl argo rollouts promote 10-hpa-canary-decoupled\n```\n\nAfter promotion has finished the old pods are destroyed and only the new pods remain.\n\nClean up with\n\n```\nkubectl delete -f .\n```\n\n## Final notes\n\n* If you use the `dynamicStableScale: true` property in a Canary with an autoscaler, the property will take precedence and kill your stable pods as the canary progresses. This is probably not what you want.","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkostis-codefresh%2Frollouts-autoscaling-example","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fkostis-codefresh%2Frollouts-autoscaling-example","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkostis-codefresh%2Frollouts-autoscaling-example/lists"}