Nowadays, it's very common to deploy applications using Docker containers orchestrated on Kubernetes. This has greatly facilitated the deployment of all types of environments, helping with their management and visualization. However, it's also true that, due to the rapid growth of the industry, the tools provided by this platform may not cover as many facets as we would like.
One of the main challenges is achieving efficient and secure deployments. It's not enough for it to work properly in a controlled environment; once deployed, the new version carries with it a series of associated risks. These risks can affect not only the program itself, but also the clients who use it. To solve this problem, there is the Argo Rollouts controller, whose features we discuss below.
Main features
Secure deployment
Argo Rollouts is a tool that allows you to follow two specific error detection techniques to help containers deliver new versions progressively. This means that data traffic will be controlled so that it doesn't affect the application, allowing you to decide the best state for production use.
Detection techniques
Canary strategy
This strategy takes its name from the canaries that were once used in mines to warn miners of the presence of dangerous gases. Similarly, the "canary" strategy allows for early detection of errors during deployment.
What this strategy does is gradually roll out the new version of the application to a limited number of users, gradually increasing traffic to the new version while reducing traffic to the previous version, until reaching 100% functional traffic on the new version.
The idea behind this is to be able to stop the deployment of the new version if it doesn't properly support traffic. This can be done at any stage of the gradual rollout, helping to mitigate the impact by reducing the number of users and requests affected in the event of a failure.
Now we'll use Argo Rollouts with some test containers to demonstrate how this strategy works. First, we need to update the image we want to test with the following command:
kubectl argo rollouts set image
Where
Once this is done, we can automatically execute the strategy with kubectl argo rollouts promote
Pods receive traffic as they go through review
If the application is not working as expected, you can run kubectl argo rollout abort to stop the update process.
Additionally, we have the option of updating the file that defines the strategy to be used by Argo Rollouts (in this example, rollout.yaml ) and further customize its operation. For example, we can specify an indefinite pause when gradually updating the application. This way, we'll advance with each promote command as much as we've specified, not automatically.
Basic Canary Strategy File Example
And not only that, but we can also configure an Ingress resource in Kubernetes to easily specify how our application's traffic should be routed, exposing it without having to worry about the process. From this configuration, Argo Rollouts will handle the same deployment management tasks, by simply specifying the Ingress we plan to use, based on the stableIngress parameter in the rollout specification.
Blue-green strategy
This strategy has the same function as the aforementioned Canary, but implements the deployment with some differences. In this case, instead of moving application traffic from the old version to the new one, two environments are created: one containing the stable application in its production version (blue) and another containing the new one to be deployed (green).
Once both exist, the green environment's capacity is tested to verify its fault tolerance. Once tested, all traffic is shifted to the green environment, and the blue environment becomes obsolete . This makes it a more immediate strategy , but also more resource-intensive, as it requires twice the infrastructure to operate.
Once we have the production environment up and running, the new one will be automatically started by Argo Rollouts when the strategy is executed when a new image is added:
This is what both environments would look like in Argo Rollouts
The update and cancellation processes will be the same as in Canary , and we will also be able to edit the file where the strategy is stored to customize it.
How does Argo Rollouts work?
Argo Rollouts vs Pod Disruption Budgets
Kubernetes Pod Disruption Budgets (or PDBs) are a resource used to limit the number of pods in a replicated application that can be voluntarily interrupted, thus ensuring a certain number of pods running in the application.
This functionality, while similar to what Argo Rollouts performs, has different goals and limitations. For starters, PDB isn't focused on releasing a new version of the application, but rather on ensuring its stability throughout its operation. Furthermore, while it allows basic control over pod creation and deletion, it isn't sufficient to replicate the advanced deployment strategies that Argo Rollouts is capable of.
This makes PDB a complementary option to Argo Rollouts, another way to protect your production environment from a different angle. Both tools can be implemented to ensure the highest possible stability and security .
Conclusions
We have seen the usefulness of implementing this tool alongside Kubernetes deployments, and we have also seen how easily we can adapt it to our project.
Argo Rollouts is simple and highly customizable, allowing you to introduce checks and analytics with a single YAML file that simplify and facilitate new deployments of your cloud applications. This makes Argo Rollouts a key tool for managing efficient and secure deployments.
Want to know more about Hunters?
Being a Hunter means accepting the challenge of testing new solutions that deliver differentiated results. Join the Hunters program and become part of a cross-functional group capable of generating and transferring knowledge.
Get ahead of the digital solutions that will drive our growth. Find more information about Hunters on the website.
Rubén Gadea
Software Technician
Altia
