This article discusses different approaches and solutions around GitOps application delivery for Kubernetes and our path towards the adoption of Flux.
The daily mood
I requested access to our LucidCharts. Wit this I expect to be able to review any existing chart of our delivery process, and finally be able to create new ones.
In the mean time I am looking for available industry solutions and practices around Continous Delivery in Kubernetes. Hereby I found the Manning book GitOps and Kubernetes of a great source of understanding and inspiration.
GitOps implementation
Basically GitOp supports both Pull- and Push-based approach, provided that configuration changes happens either in Git via InfraCode, or on the cluster via new image tags, rather than through the action of a human operator. GitOps can be implemented using existing technology or new emerging tools, thus with some slight differences in the approach, structure and infrastructure support.
Poc
Our team already ran a first evaluation of Flux, beside ArgoCD one of the 2 main open-source solutions claiming to implement GitOps. The hypothesis was to reduce the operational gap between dev and production, while simplifying configuration, deployment and upgrades in multiple-environments.
In terms of result the expectation was generally met, but Flux requires to replicate a lot of infrastructure code (DRY), and user-experience is not smooth for non-operational teams (ex. development, qa).
Flux
Flux is a CNCF project maintained by Weaveworks and integrated in Weave Cloud service offering. With Flux each instance of the operator is able to watch one Docker registry, update one Git repository (Helm support available) and keep one Kubernetes cluster up-to-date (using kubediff/kysnc tools). Support for rolling-updates (cf. Manning book Kubernetes in action Chapter 9. Deployments: updating applications declaratively) and automatic rollbacks makes it a reliable choice, but the free version does not offer any UI.
ArgoCD
ArgoCD is an open-source project maintained by Intuit. ArgoCD is more mature/enterprise-ready, in which multiple Git repositories and Kubernetes namespaces can be accessed by one single operator, fine grained security (SSO, RBAC) and synchronization level options are available out-of-the-box both via Argo-UI and Argo-CLI. But it doesn't seem to connect to a registry, support Helm (focus on Kustomize instead) and write environment state back to Git.
Flux + Argo = Argo Flux
In Nov. 19 Weaveworks and Intuit annouced that they are partnering together on a new open-source project called Argo Flux, a best-of-breed solution to drive GitOps application delivery for Kubernetes. However for some reason, both projects still didn't merged as of today.
See also
- Git repository structure recommendations from DZone
- Example of Use-Case from Metrosystems SRE using Flux
Other interesting products
- Jenkins X, TektonCD, Knative and (IBM) Razee are cloud native pipeline tools.
- (Google) Skaffold is a client-side only delivery tool for K8s.
- KubeStack, Harness and Heroku are infrastructure agnostic i.e. they may introduce some more abstraction to K8s e.g. via (Hashicorp) Terraform.
Conclusion
GitOps gains industry acceptance but is still a young mantra with a number of possible directions. For an organisation like the company I am working at, it is hard to make a long-term decision on the right deployment process. The battle happening on the software provider side also reflects that uncertainity.
Source: harness.io
Comments
Post a Comment