In this lesson we’ll convert an existing Kubernetes Deployment into an Argo Rollout so the Argo Rollouts controller can manage lifecycle and rollout strategy (for example, blue/green or canary). This approach lets you adopt an existing Deployment without rewriting the pod template by using workloadRef.Documentation Index
Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
Use this file to discover all available pages before exploring further.

- Replace the Deployment kind with an argoproj.io/v1alpha1 Rollout so Argo Rollouts manages the resource.
- Use spec.workloadRef to point the Rollout to an existing Deployment (no pod-template rewrite needed).
- Configure spec.workloadRef.scaleDown to control what happens to the original Deployment after the Rollout succeeds.
- Choose a rollout strategy; this example uses blueGreen and requires activeService (previewService is optional).
| Field | Purpose | Example / Notes |
|---|---|---|
| apiVersion / kind | Instructs Kubernetes to treat this as an Argo Rollout managed resource | argoproj.io/v1alpha1 / Rollout |
| spec.replicas | Number of desired replicas for the Rollout | Same concept as Deployment |
| spec.workloadRef | Adopts an existing Deployment so the Rollout uses the same pod template | apiVersion: apps/v1, kind: Deployment, name: <deployment-name> |
| spec.workloadRef.scaleDown | Policy to control scaling behavior of the original Deployment after successful rollout | onSuccess, never, progressive (see table below) |
| spec.strategy.blueGreen | Blue/green rollout configuration; activeService is required, previewService optional | Provides traffic promotion and internal preview testing |
| Option | Behavior |
|---|---|
| onSuccess | Controller scales the original Deployment to zero after the Rollout becomes healthy. |
| never | Controller does not scale down the original Deployment. Use when you want both to run. |
| progressive | Controller gradually scales down the original Deployment alongside the Rollout. |
- This manifest adopts an existing Deployment named
highway-animation-1and performs a blue/green rollout usingactiveServiceandpreviewService.
- The Rollout resource takes control of the specified Deployment (it “adopts” it).
- The Rollout controller will create new ReplicaSets/Pods for the rollout while the original Deployment pods remain until scaleDown policy executes.
- With
scaleDown: onSuccess, when the Rollout becomes healthy the controller scales the original Deployment to zero, leaving the Rollout-managed pods servicing traffic.
- Initial state (plain Deployment running four replicas):
- Apply the Rollout manifest (example uses a public gist). This creates the Rollout and the blue/green services:
- After applying, new Rollout-managed pods will be created while the original Deployment pods continue running until the rollout completes:
- When the Rollout becomes healthy, Rollout pods will reach Running and the original Deployment pods are terminated according to the scaleDown policy:
Note: Using workloadRef allows you to convert an existing Deployment to be managed by Argo Rollouts without rewriting the pod template. Review the available scaleDown options (onSuccess, never, progressive) to choose the behavior that suits your release workflow.
- Argo Rollouts documentation: https://argoproj.github.io/argo-rollouts/
- Kubernetes Deployments: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
- Example manifest used in this demo: https://gist.github.com/sidd-harth/5dedab96d94373e4f1f1317f33d3781f