Argo Rollouts automates Kubernetes release strategies that would otherwise require manually coordinating Deployments and Services. Its controller manages Rollout resources and application replicas; a kubectl plugin lets operators inspect progress, promote revisions, and roll back. Argo CD can apply Rollout configuration through GitOps instead of requiring manual changes in each environment. section 8.1.4 section 8.3
Define a Rollout with a pod template and replica count, much as you would define a Deployment, then add a release strategy. The controller creates and manages the ReplicaSets. For a canary, steps can set a target weight and pause either for a specified duration or until manual promotion. section 8.3.1
Listing 8.11 Argo Rollouts resource definition
apiVersion: argoproj.io/v1alpha1
kind: Rollout #1
metadata:
name: notifications-service-canary
spec:
replicas: 3 #2
strategy:
canary: #3
steps: #4
- setWeight: 25
- pause: {}
- setWeight: 75
- pause: {duration: 10}
revisionHistoryLimit: 2
selector:
matchLabels:
app: notifications-service
template:
metadata:
labels:
app: notifications-service
spec:
containers:
- name: notifications-service
image: salaboy/notifications-service-<HASH>:v1.0.0
env:
- name: KAFKA_URL
value: kafka.default.svc.cluster.local
...
This notifications-service Rollout shows three replicas and canary steps targeting 25%, then 75%, with manual and timed pauses. section 8.3.1
Try a canary release
Apply the canary resources with `kubectl apply -f argo-rollouts/canary-release/`, then check `kubectl get rollouts.argoproj.io` and watch progress with `kubectl argo rollouts get rollout notifications-service-canary --watch`. Updating the container image starts a new revision. Check the service response and ReplicaSets while both versions run, then use `kubectl argo rollouts promote notifications-service-canary` to pass the manual pause. After promotion, the new ReplicaSet has three replicas and the old one has zero. In this example, weights are approximated through replica counts rather than guaranteed percentages of requests. section 8.3.1 section 8.3.4
For blue/green delivery, configure an active Service for production traffic and a preview Service for the new revision. Setting `autoPromotionEnabled: false` leaves promotion to an operator after the preview has been checked. The controller manages Service selectors so they point to the appropriate revision. section 8.3.2
AnalysisTemplate resources add automated gates. They define probes and success conditions; AnalysisRuns execute them against a new revision. A canary can run analysis between steps, while blue/green delivery can gate promotion on a pre-promotion test. For more precise routing than replica counts provide, traffic-routing integrations such as Istio can support percentage splits, header-based routing, and request mirroring. section 8.3.3 section 8.3.4
