More

    GitOps for Kubernetes – DZone Refcardz

    Thanks to the DevOps movement, the focus on and responsibilities of developers has increased, and the focus has shifted rightly so to improving the developer experience. In the last few years, the number of tools and systems needed to manage version control, configuration management, Infrastructure as Code, CI/CD, and observability have drastically increased. This puts an additional burden on the developer as they now must oversee more and more components of the application.

    Ideally, the developer focuses mainly on delivering business value via code. Thus, to improve developer experience, GitOps emerged where infrastructure and application configuration changes revolve around Git, i.e., the version control ecosystem. The focus is entirely on keeping Git as a single source of truth for infrastructure and application configuration changes. In an ideal world, this approach allows the developer to focus on working and pushing code to Git, and then further deployment and tweaks would be taken care of by an automated mechanism. 

    Since Kubernetes and many other cloud-native technologies are almost entirely declarative, infrastructure definitions can be kept alongside application code in Git. Keeping your entire system in Git means that your development team uses familiar Git-based workflows and pull requests to deploy both application and infrastructure changes to Kubernetes. 

    With the entire state of your cluster kept under source control, diff tools and synchronization agents can compare what’s running in production with what’s under source control — and when a divergence is detected between the two, an alert can be sent, effectively creating a feedback and control loop for managing your cluster.    

    Principles of GitOps 

    GitOps is based on several core tenets:

    Declarative Description

    Thanks to modern Infrastructure as Code (IaC) and configuration management tools like Terraform, you can define, configure, and spin up your entire application declaratively via code. These declarative configurations will be stored ideally in your version control systems (VCS) like Git, GitLab, or GitHub. 

    Single Source of Truth 

    In the GitOps world, version control systems (VCS) like Git should be the only source of truth. Whatever changes one wants to perform in the system should be declared and always committed first in Git or the GitLab repo alone. This helps to identify configuration drift as well as implement auditing to determine any possible changes or misconfigurations conducted outside VCS (i.e., Git) and restore back to normal if needed. 

    Canonically Versioned Desired System State 

    Now, by being able to declaratively store your desired system state in Git, you can easily apply versioning — as one does to application code packages — to your system configuration state, i.e., infra config code present in Git.  This makes rollbacks easier in case your desired state in Git results in system instability for your actual state present in the cluster. For example, let’s say you have stored your current system state with version number 1.0.0 (semantic versioning) in Git. Now you want to apply a minor patch to your system state, i.e., application configuration. So you can commit that change to Git with version number 1.0.1 and push those changes. In case 1.0.1 does not bring the expected results, then you can just use “Git revert” to rollback those changes from Git. Then your actual state from the cluster will also get changed back to 1.0.0 as it was previously. 

    Automatically Approved Changes 

    Once you have the declared state kept in Git, the next step is to have the ability to automatically apply any state changes to your system. What’s significant about this is that you don’t need specific cluster credentials to make a change to your system. With GitOps, there is a segregated environment, and the state definition lives outside of it. This allows your team to separate what they actually do from how they are going to do it.

    Configuration Drift Detection 

    A GitOps approach suggests that your declarative configuration files and application code should be stored together in the Git repository. This is what we call the “desired state of your system”. Once you deploy all of this into the cluster and set up your application ecosystem, we call it an “actual state of your system”.  The “Configuration drift” is a term that commonly describes the gradual changes that we unknowingly and unnoticeably bring to the actual state of the system, which brings inconsistency and unpredictability between the actual and desired state. Our GitOps system of choice should ideally be able to detect, notify, and possibly auto-correct the actual state to make it consistent and match the desired state again.      

    Benefits of GitOps for Kubernetes 

    Kubernetes, also known as K8s, is an open-source system for automating the deployment, scaling, and management of containerized applications. From 2013 to 2014, a revolution in software infrastructure emerged with tools such as Docker that demonstrated the capabilities of containers, thus exposing a new way of packaging and isolating application services.

    This led to the birth of designing distributed systems. Containers took the world by storm and introduced new ways to orchestrate applications. When Google open-sourced Kubernetes in 2014, it grabbed the attention of developers and quickly became the de facto standard by 2016 — thanks to the many open-source communities that made it what it is today. 

    Kubernetes brings much-needed container orchestration capabilities like:

    This list continues to grow with every release. Let’s now explore the key benefits GitOps brings to Kubernetes.

    Increased Speed and Productivity 

    Continuous deployment automation with integrated feedback and control loops speeds up your deployment frequency. Declarative definitions kept in Git allow developers to use familiar workflows, reducing the time it takes to spin up new development, test environments, or deploy new features to a cluster. Teams can ship more changes per day, and this translates into a faster turnaround for new features and functionality for the customer.

    Self-Service 

    With the existing CI/CD approach, the development team remains dependent on the operations team to deploy new changes in production. GitOps empowers teams to become more efficient and strategic. It enables development teams to be more self-service in nature as they would be less dependent on platform and operations teams to deploy and handle their code and configuration changes in production. All they have to do now is commit their changes to the Git repo and merge PR —the rest will be taken care of by GitOps tools. 

    Declarative Approach 

    Kubernetes itself is declarative in nature. A declarative approach suggests that you should only declare what you want to achieve vs. how it should be achieved, and then the automated system should take care of it ahead of time. The opposite of declarative is an imperative approach where you try to define the sequence of steps, which unfortunately is an additional overhead on the operator. GitOps promotes a declarative approach. Every object you use in GitOps can be coded and declared in your Git repo; then your GitOps system will create those for you. 

    Observability 

    Observability from a GitOps perspective is the ability to constantly have access to monitoring the actual state present in the cluster and the ability to compare it to what was desired. GitOps helps to measure and monitor what’s running on the cluster and notify teams if it`s desirable or undesirable. Every GitOps tool nowadays comes up with the ability to monitor and notify us in this way. 

    Compliance and Auditing Capabilities

    GitOps helps to follow the compliance and auditing capabilities as needed and regulated in different domains. In GitOps, whatever is stored in Git is the only source of truth. So, this makes the audit process simple: The auditor can analyze the desired state by observing and focusing on the source code repository. They can also determine the current state of the system by reviewing the underlying infrastructure provider as well as the Kubernetes cluster state.  

    Multi-Cluster Configuration Management 

    Being declarative in nature, Kubernetes helps most larger and enterprise organizations use multiple clusters for different business and team needs. Managing these clusters and keeping configuration and organizational security and other policies consistent across these clusters is a big ask for the Ops team. GitOps takes this burden away by letting the GitOps agent running across these clusters handle everything on your behalf, and so, it is a great fit from a multi-cluster configuration management perspective.

    Infrastructure as Code 

    In the Kubernetes world, GitOps is getting used to overall automate the process of infrastructure provisionings like creating deployments, services, and every possible Kubernetes object. DevOps and SRE teams are adopting GitOps so that you can store all your infrastructure configuration files as code. GitOps innately has Infrastructure as code as one of its characteristics.  

    Stronger Security Guarantees 

    Git’s firm correctness and security guarantees — backed by the strong cryptography used to track and manage changes, as well as the ability to sign the changes to prove authorship and origin — are key to a correct and secure definition of the cluster’s desired state. If a security breach does occur, the immutable and auditable source of truth can be used to recreate a new system independent of the compromised one, reducing downtime and allowing for better incident response.

    Also, separating responsibility between packaging software and releasing it to a production environment embodies the security principle of least privilege, reducing the impact of compromise and providing a smaller attack surface.

    Disaster Recovery 

    Disaster recovery (DR) is a practice that every organization must have in place to recover from an event that negatively affects business operations. The goal of DR methods is to enable the organization to regain the use of critical systems and IT infrastructure as soon as possible after a disaster occurs.

    Now how does GitOps help achieve the same? Well, it helps in the recovery of infrastructure environments as the entire environment and components we would have present are declaratively defined in our Git repository. So disaster recovery in case of such events becomes as easy as simply reapplying the configuration field present in Git to quickly restore your ecosystem.

    This content was originally published here.

    Latest articles

    spot_imgspot_img

    Related articles

    Leave a reply

    Please enter your comment!
    Please enter your name here

    spot_imgspot_img