Meeting business objectives today necessitates frequent deployments and fast iteration. However, frequent deployments increase the risk of interfering with currently running programs, which may irritate users. Canary deployments address this issue by allowing software updates to be handed out gradually to a small set of users while the effects are closely monitored and any issues are resolved prior to the main rollout.
Argo CD and Istio provide a robust framework for automating canary deployments in a Kubernetes environment. This blog will look at automating canary installations with Argo CD and Istio, describing the key benefits, practical uses, and features of each tool to ensure a smooth operation.
What does it mean to deploy canaries?
A canary deployment is a progressive rollout of an application that splits traffic between an already-deployed version and a new version, rolling it out to a subset of users before rolling out fully. If the updated version runs smoothly, it is sent to the remaining users. or else, the deployment can be suspended and the prior version restored.
Key Benefits of Canary Deployments:
- Reduced Risk: There is a probability that certain users will not experience issues with the latest version.
- Faster Recovery: In case there is a system failure, it can be reversed easily.
- User Experience: Compared to more traditional deployment tactics, rollouts often cause less disturbance for end users.
Why do canary deployments benefit Argo CD and Istio?
The steps to implementing an Argo CD and Istio canary standard are as follows:
- Code commit: The Git repository is updated with the latest version of the application code.
- Argo CD Sync: When Argo CD Sync detects changes to the Git source, it initiates a Kubernetes deployment.
- Istio Traffic Management: Istio allows you to test its performance and behaviour in a production-like environment by gradually routing a small part of traffic to the latest version (canary).
- Monitoring and Metrics: You may use tools like Prometheus and Grafana to track key metrics such as latency and error rates. These can be used to analyse and determine whether to proceed with the deployment or roll back to the prior version.
- Finalize Deployment: Once the canary version is successful, Istio will progressively move all traffic to the new version, thereby ending the deployment.
Here is an easy approach to automate canary deployments with Argo CD and Istio.
Let’s have a look at how to use Argo CD with Istio for canary deployments.
Step 1: Configure the Argo CD
First Install Argo CD in order to handle application deployment in a Kubernetes cluster and then it may be set up to search your Git repository for application manifests after installation.
Prepare an Argo CD application manifest similar to the one below in order to keep an eye on your Kubernetes manifests in Git:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: canary-app
spec:
destination:
namespace: default
server: https://kubernetes.default.svc
source:
repoURL: https://github.com/your-repo/canary-app.git
path: manifests
syncPolicy:
automated:
prune: true
selfHeal: true
Step 2: Set up Istio service mesh
In your Kubernetes cluster, please install Istio to control traffic for canary deployments. Istio allows network traffic intercept and control by installing sidecar proxies inside your application’s pods.
Step 3: Set Up Services and Deployments for Kubernetes
In the Kubernetes deployment manifest, include details about the stable and canary versions of your application.
apiVersion: apps/v1
kind: Deployment
metadata:
name: canary-app
spec:
replicas: 3
template:
metadata:
labels:
app: canary-app
version: stable
spec:
containers:
- name: canary-app
image: canary-app:stable
Create a canary version of the deployment manifest for your application now, and label it with version: canary.
Step 4: Configure Istio VirtualService to Route Canary Traffic
The Istio VirtualService resource lets you configure traffic routing between stable and canary versions. Consider the following configuration: 90% of traffic goes to the stable version, 10% to the canary version.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: canary-app
spec:
hosts:
- canary-app.default.svc.cluster.local
http:
- route:
- destination:
host: canary-app
subset: stable
weight: 90
- destination:
host: canary-app
subset: canary
weight: 10
This configuration allows Istio to progressively divert traffic to the canary version. As the deployment progresses, the traffic percentage can be adjusted based on how well the canary version performs.
Step 5: Track and Examine the Canary Deployment
During the canary deployment, performance metrics like error rates, response times, and resource utilisation can be tracked using monitoring tools such as Prometheus and Grafana.If problems are identified, the traffic can be returned to its stable state by modifying the traffic weights in the VirtualService.
Step 6: Rollback or complete rollout.
If the canary version is functioning successfully, gradually increase the traffic proportion to 100% while turning off the stable version.If problems occur, use the stable version of the traffic while debugging the canary version.
Conclusion
By automating canary installations with Argo CD and Istio, we can produce recovery plans that are more efficient, secure, and transparent. Using the advantages of both, will increase the robustness and dependability of your release process and increase the effectiveness of canary deployments. No matter how big your microservices-based system is or how big the application you’re releasing is, this approach lowers risk and maintains service continuity throughout changes.
About OpsMx
DevOps and DevSecOps teams can ship software faster with OpsMx, all while ensuring the security and 100% compliance of application releases. By building on top of open-source Argo, Spinnaker, and Flux, OpsMx provides innovative solutions and services to SHIP BETTER SOFTWARE FASTER AND SAFER.
0 Comments