1. Expose Your Deployment via a LoadBalancer
First, ensure your v1 image is deployed and reachable from the Internet:| Service Name | Type | Cluster IP | External IP | Ports | Age |
|---|---|---|---|---|---|
| kodekloudapp | LoadBalancer | 10.0.112.113 | 20.205.144.237 | 80:30344/TCP | 2m |
| kubernetes | ClusterIP | 10.0.0.1 | <none> | 443/TCP | 2d |
If the
EXTERNAL-IP remains <pending>, wait a minute or check your Azure networking configuration.2. Perform a Rolling Update to v2
To point the existing deployment at yourv2 image in ACR, use:
3. Verify the Updated Version
Once the update completes, refresh your application’s public IP in the browser. You should see the v2 message. To confirm the deployment is using the new image:4. Rolling Back to a Previous Revision
Kubernetes retains a history of deployment revisions by default. If you encounter issues in v2, you can quickly revert to v1. View the rollout history:| Revision | Change Cause |
|---|---|
| 1 | <none> |
| 2 | <none> |
Rolling back in production can affect end users. Consider testing rollbacks in a staging environment first.
Next Steps
You’ve successfully managed upgrades and rollbacks in AKS. Next, explore Azure Kubernetes Fleet Management to coordinate multiple clusters and streamline governance.Links and References
- Azure Kubernetes Service (AKS) Overview
- Azure Container Registry Documentation
- kubectl Cheat Sheet
- Kubernetes Deployments