Problem Statement: Manual Errors in K8s Deployments
Using argocd applications for deployment of microservices to multiple environments ( example dev, qa prod environments) located in multiple clusters becomes cumbersome. Manifests of argocd applications must be maintained for each environment. Promotion from an environment to higher ones involves manual effort, making the process error prone. Argocd also does not have a native approval mechanism (other than manual sync), required by most companies to deploy to production environments. Current solutions involve other tools to address these issues.
Solution: ArgoCD ApplicationSets with Rolling Sync strategy
Use argocd applicationsets with rolling sync strategy, along with kubernetes jobs as quality gates as well as simulate approval, to automate delivery and accommodate manual approval for production environments.
Background: Why use ArgoCD?
Argocd, developed by the vibrant Argo community, is wildly popular with users who deploy to kubernetes clusters. Kubernetes itself spread very fast and organisations have moved away from legacy systems, to take advantage of the abstraction of the underlying infrastructure of machines, virtual or real.
Argocd simplifies deployments using the gitops model and declarative architecture. Argocd application, a custom resource definition (CRD) represented by a yaml file, is the basic unit of argocd architecture. Argocd applications connect repositories containing kubernetes manifest files to kubernetes clusters. Using SyncStatus and HealthStatus of an application, the state of the deployment can be monitored.
Details: More about ApplicationSets and RollingSync
Argo community has come up with a relatively new custom resource definition called applicationset, another CRD. An applicationset generates applications using generators like list generator, git generator and matrix generator among others. Applicationset manifest also includes an application template section that uses placeholders for the fields used by a typical argocd application.
Within applicationsets, a new feature called progressive sync has been introduced. Two deployment strategies were introduced called RollingSync and AllAtOnce. While AllAtOnce deploys all applications at once, RollingSync involves steps in which deployment proceeds. In each step applications that match a particular label are deployed. When the applications in a given step are synced and healthy then applications in the next step are deployed.
Each argocd application has kubernetes manifests in git or helm sources. In the source repositories, by including kubernetes jobs, that can run tests like sanity tests for dev environment, functional tests in qa environment and load tests in performance environment one can control the quality of the software. Only if the jobs succeed, the applications become healthy. Using kubernetes jobs that run tests, along with RollinSync strategy of argocd applicationsets, the whole promotion cycle from dev to prod can be automated.
How can OpsMx help automate Kubernetes promotions
At Opsmx, we created a helm chart with an applicationset template. The design of this chart is such that users can choose the number of stages in which deployments proceed from dev to prod. Users can also choose any combination of clusters, namespaces and environments. They can also choose to deploy to two or more environments simultaneously. A choice of git type repositories that contain either plain yaml files or helm charts is available too.
Some organisations require approval before deploying to production environments. Even though OpsMx has fully automated the promotion, the solution also accommodates manual approval via Argo Workflows, Kubernetes Jobs, Git pull requests (PRs). The solution is flexible enough to accommodate any other method of approval.
Takeaways:
OpsMx’s solution can reduce the manual interventions involved in promoting code from development to production environments. This reduces human errors and streamlines the process. The solution incorporates all kinds of tests so that quality is not compromized. The solution is flexible enough to accommodate most organisations’ requirements. The solution also reduces the number of files that need to be maintained by a factor equal to the number of environments. If the whole organisation uses the same standard of environment and stages, then using matrix generator further reduces the bookkeeping necessary by an order of magnitude.
References:
- https://argo-cd.readthedocs.io/en/latest/operator-manual/applicationset/Progressive-Syncs/
- https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Generators-List/
- https://www.sumologic.com/blog/why-use-kubernetes/
- https://www.opsmx.com/what-is-argocd/
- https://edgedelta.com/company/blog/kubernetes-adoption-statistics
- https://www.cncf.io/blog/2023/11/07/cncf-gitops-microsurvey-learning-on-the-job-as-gitops-goes-mainstream/
About OpsMx
OpsMx helps DevOps teams optimize software delivery, 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