--- title: "GitOps and Kubernetes: CI/CD for Cloud Native applications" url: "https://www.sparkfabrik.com/en/blog/gitops-and-kubernetes/" lang: "en" type: "blog-post" date: "2021-11-11" lastmod: "2021-11-11" author: "SparkFabrik Team" description: "Git as a single source of truth for declarative infrastructure and applications in the Kubernetes context." tags: ["Cloud Native"] schema: "@context": "https://schema.org" "@type": "BlogPosting" "headline": "GitOps and Kubernetes: CI/CD for Cloud Native applications" "description": "Git as a single source of truth for declarative infrastructure and applications in the Kubernetes context." "url": "https://www.sparkfabrik.com/en/blog/gitops-and-kubernetes/" "datePublished": "2021-11-11T00:00:00+00:00" "dateModified": "2021-11-11T00:00:00+00:00" "author": "@type": "Person" "name": "SparkFabrik Team" "image": "https://www.sparkfabrik.com/images/blog/gitops-and-kubernetes/cicd-push-based-deployment.png" "publisher": "@type": "Organization" "name": "SparkFabrik" "url": "https://www.sparkfabrik.com" "logo": "https://www.sparkfabrik.com/images/logo.svg" --- # GitOps and Kubernetes: CI/CD for Cloud Native applications **Author:** SparkFabrik Team **Published:** 11 November 2021 **Tags:** Cloud Native --- GitOps** is a paradigm aimed at implementing Continuous Deployment and/or Continuous Delivery for Cloud Native applications. Through the use of tools that the developer is already familiar with, it focuses on an experience that also sees the developer involved in infrastructure-related activities. We can think of GitOps as **a collection of best practices** for managing the delivery of containerized applications, together with the infrastructure on which they run. GitOps is based on 3**key principles** : * **First principle** : the end-to-end system must be described **declaratively** – precisely why the declarative nature of Kubernetes and the Controller model are ideal for the adoption of GitOps. * **Second principle** : the **desired state** of the system must be versioned **in a Git repository**. If a Git repository contains files which declaratively describe the desired state of the system, then Git becomes both the **single source of truth** for the state of our system, as well as the **single place where all environments run**. * **Third principle** : all **changes** that have been **approved and committed** in a repository **_can_**automatically** be applied to our system. This does not mean that automation is a requirement for GitOps, but that if the context allows it, it is recommended to automate the procedure. So a new actor is needed in order to implement GitOps in Kubernetes: the **GitOps Operator**. THIS MAY INTEREST YOU** : [3 mistakes to avoid when adopting Kubernetes](/en/common-mistakes-kubernetes?hsLang=en) ## So what do I need to adopt GitOps? As we already mentioned, a new actor is needed: the **GitOps operator**. In other words, a Kubernetes operator which follows the loop control pattern of the Kubernetes controller and handles the automation aspect of delivery and monitoring. Several GitOps operators are currently available on the market, the main ones being Flux CD, Argo CD and Jenkins-X. * Developed by Weave Works (who coined the term GitOps), Flux CD is **an application written in Go that installs an operator in the target cluster** , a command-line utility, presumably facilitating its automation. A new version of Flux is currently under development, a complete rewrite based on the GitOps Toolkit project. This new version will introduce interesting new features, including support for multiple repositories. * [**Argo CD**](https://argoproj.github.io/argo-cd/) is part of **Argo Project** , a set of native Kubernetes tools for deploying and executing jobs and applications developed by Inuit, a US enterprise working in the financial software sector. Argo offers an **excellent graphical interface** and includes a command-line tool. It is also quite **flexible** as, thanks to features such as Single Sign On and multi-cluster multi-project centralized management, it can be used on any type of project, from the smallest to enterprise projects. * [**Jenkins-X**](https://jenkins-x.io/) is a CI/CD solution for Kubernetes-based Cloud Native applications. It is not a single product but rather **a package of preconfigured tools, which can be installed automatically or based on the options selected by the user**. The installation is managed from the command line (jx), which allows you to have a complete platform at your disposal in a relatively short time through a wizard. Jenkins-X, therefore, positions itself as an all-in-one solution that can be used for the entire CI/CD process. Jenkins-X is an open-source project with enterprise support offered by CloudBees, and is part of the Continuous Delivery Foundation (CDF). * Moreover, those who already use **GitLab EE** , the _premium_ version of GitLab, will have available – starting from release 13.4 – **the integration of a Kubernetes Agent** , a native tool that will allow you to implement GitOps without having to rely on other products. The project is the result of a collaboration between Argo with Flux and Amazon AWS. So why are we telling you this? It is not uncommon that, after a few releases, some premium features switch over to the free version. So it’s definitely worth **keeping an eye on this GitLab** feature and on how the tool will evolve in its free version. ## The GitOps CI/CD pipeline Before looking at the GitOps CI/CD **pipeline, let’s take a look at a typical Kubernetes CI/CD pipeline** , also known as the **Push Model**. ![CI/CD push-based deployments](/images/blog/gitops-and-kubernetes/cicd-push-based-deployment.png) _Credits:_[_GitOps, Push-Based Deployments_](https://www.gitops.tech/#push-based-deployments) This model follows a pipeline which, as you can see, we can defined **as unilinear and unidirectional** : it starts from the developer, follows all the steps of the CI and, finally, it is the same CI tool that also handles the Continuous Deployment of the application in its target environment. Although not inherently wrong, this process can present some weaknesses: first of all, the need to **provide the target environment credentials** to the CI/CD tool. Second, we see **a CI tool that is unable to detect/alert us of discrepancies** between the desired state and the current one and forces us to install a second tool that is in charge of monitoring the state of the application. ![CI-CD GitOps Push-Based Deployments](/images/blog/gitops-and-kubernetes/CI-CD-GitOps-Push-Based-Deployments.png) _Credits:_[_GitOps, Pull-Based Deployments_](https://www.gitops.tech/#pull-based-deployments) In the **Pull-Based Model** , and likewise in the **CI/CD GitOps pipeline model** , we see a first main difference, namely the presence of _two_ repositories located at the beginning and end of the CI process. In this model, in fact, the CI tool no longer takes care of the deployment. Instead, this task will fall on an operator like those seen previously, installed in the target environment. Listening for any changes made in the registry docker and in the repository environment, the tool will ensure that the current state of the environment coincides with that of the repository environment, in other words, the desired state. So let’s take a look and see how in this model the unidirectional and unilinear nature of the Push-Based model are circumvented, thus **enhancing its security and efficiency**. ## GitOps: benefits and challenges (and how to deal with them) No doubt, GitOps can offer many **benefits**. First, it makes the system **fully observable** , both by you and by an automated tool. It assures you that what you see in the repository environment is perfectly in line with the Kubernetes cluster, independently making the necessary implementations to match the current state of the system with the desired state (consequently also increasing the **verifiability** of the system!). Moreover, GitOps shares an essential benefit with Kubernetes: the declarative model on which the work of the operators is based, thanks to which you can see **an increase in productivity**. Finally, the Pull model **enhances system security** by simplifying the problem of having to expose the Kubernetes APIs to your Continuous Integration. To be absolutely sure that you can take full advantage of these benefits, however, attention must be paid to aspects that can lead to problems if not properly managed**.** Indeed, it is important to leverage the repository environment and pipelines **to prevent, as much as possible, the simultaneous push to the same repository**. If Git found that the remote repository was no longer aligned because, in the meantime, another pipeline pushed on the same repository and on the same branch, it would no longer be able to push the changes. So what are our **recommendations** to avoid these problems? First, if possible, we recommend that you always **use two repositories** , one for your application code and the other as storage for your manifests. Moreover, always remember that you should **never store sensitive data in the repository environment**. It is true that GitHub helps make your system more secure, but it is still a good idea to take this precaution. By following these two simple tips and best practices, you can create modern and Cloud Native applications, enjoying all the various benefits that the GitOps paradigm has to offer and will continue to offer with its ever-growing development. --- ## Frequently Asked Questions ### What is GitOps and what are its key principles? GitOps is a paradigm for implementing Continuous Deployment for Cloud Native applications. It is based on three principles: the system must be described declaratively, the desired state must be versioned in a Git repository (making Git the single source of truth), and approved changes committed to the repository can be automatically applied to the system. ### What is the difference between push-based and pull-based CI/CD pipelines in GitOps? In a push-based model, the CI tool handles both integration and deployment directly. In a pull-based (GitOps) model, two repositories are used and a GitOps operator installed in the target environment handles deployment by monitoring changes in the registry and environment repository, enhancing both security and efficiency. ### What are the main GitOps operators available for Kubernetes? The main GitOps operators include Flux CD (developed by Weave Works, written in Go), Argo CD (part of the Argo Project, offering an excellent graphical interface and multi-cluster management), and Jenkins-X (an all-in-one CI/CD solution for Kubernetes). GitLab EE also offers native Kubernetes Agent integration starting from release 13.4. ### What are the benefits of adopting GitOps with Kubernetes? GitOps makes the system fully observable, ensures the repository environment matches the Kubernetes cluster state, increases productivity through the declarative model, and enhances security by eliminating the need to expose Kubernetes APIs to the CI system through the pull-based deployment model. ### What best practices should be followed when implementing GitOps? Key best practices include always using two separate repositories (one for application code, one for manifests), never storing sensitive data in the environment repository, and leveraging pipelines to prevent simultaneous pushes to the same repository and branch to avoid conflicts. --- ## Related Articles - [Why CTOs choose Drupal: AI, sovereignty, and platform engineering](https://www.sparkfabrik.com/en/blog/why-ctos-choose-drupal-enterprise/) - Modern enterprise architectures require solid foundations to manage critical data and complex … - [Drupal AI 1.3: security, governance, maturity and new tools](https://www.sparkfabrik.com/en/blog/drupal-ai-1-3-security-governance/) - The adoption of LLMs in CMSs requires solid architectures to avoid privacy risks and hallucinations. … - [How to Choose the Right Cloud Provider for Kubernetes](https://www.sparkfabrik.com/en/blog/choosing-kubernetes-cloud-provider/) - A technical comparison of GKE, EKS, and AKS to choose the best Kubernetes cloud provider. Explore … --- *This is a Markdown version of the blog post to facilitate reading by AI and crawlers.* *Visit [https://www.sparkfabrik.com/en/blog/gitops-and-kubernetes/](https://www.sparkfabrik.com/en/blog/gitops-and-kubernetes/) for the full version with images and formatting.*