Hands-on Lab·Kubernetes and Cloud Native Associate
Progressive Delivery and Automated Rollback
A Deployment gives you one rollout strategy and no opinion about whether the new version is any good. Replace it with a Rollout that shifts 20% of traffic, asks Prometheus whether to continue, and reverses itself when the new image cannot run.
Delivery and GitOps Guide 46 of 46 Intermediate
- Kubernetes1.36.4
- Argo Rollouts1.9.1
- Prometheus3.14.0 (kube-prometheus-stack)
- TimeAbout 20 min
- Reviewed22 August 2026
Written against the versions above. Argo Rollouts is a CNCF incubating project and its CRDs are still v1alpha1. The step and analysis fields used here have been stable across 1.x.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE03 | 192.168.0.178 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
Before you start
- A working Prometheus in the monitoring namespace, for the analysis step.
- The rolling-update guide, since the whole point here is what a Deployment cannot do.
-
Install the controller, and meet the first surprise
-
Twenty percent first
-
The gate asks Prometheus
-
Promote, and what one promote actually does
-
A version that cannot run