GitOps On Kubernetes In Just 15 Minutes

This blog aims to highlight the adoption of Flux as a prime tool for Continuous Deployment. It embraces the concept of GitOps, offloads the responsibility of triggering Kubernetes deployments on Flux Operator(s).
The conceptual details followed by a step-by-step implementation are given below:

#GitOps

Table of Contents

• Introduction
  - What is GitOps?
  - What is Flux? — one of the many ways. Reduces time to 15min. Link Flux doc.
  - Components of Flux
• Benefits of using Flux
• System Requirements
  - Setup development cluster using KIND (Kubernetes in docker)
  - Install & Configure Flux in Kubernetes Cluster
• GitOps In Action
  - Setup Git repository “app-flux-infra”
  - Apply Kubernetes manifests (YAMLs)
  - Bootstrap Git repository in flux
  - Create an Nginx deployment under cluster/dev
  - Observe the deployments rolling on Git push and Query Flux to view the currently deployed revision
  - Trace applied revision to match with Git SHA
  - Apply Helm Chart
  - Create a Helm Chart “ms-template”
  - Package Helm Chart
  - How to convert GitHub repo into Helm repository?
  - Configure Helm Repository in Flux
  - Create Helm Release in Flux
  - Update the Helm Chart
  - Observe the helm update rolling
• Conclusion
• References

Introduction

What is GitOps?

• The term GitOps was coined in August, 2017 in a series of blogs by Alexis Richardson, Co-founder and CEO of Weaveworks.
• GitOps is a bunch of strategies that utilize the force of Git to give both modification and change control inside the Kubernetes stage.
• GitOps brings the center advantages of Infrastructure as Code and permanent framework to the arrangement, observing, and life-cycle the executives of Kubernetes applications in an instinctive, open way.
• A developer-centric experience for overseeing applications, with completely mechanized pipelines/work processes utilizing Git for improvement and operations.
• Utilization of the Git amendment control framework to follow and endorse changes to the foundation and run-time climate of uses.

Reference from the book GitOps and Kubernetes — Continuous Deployment with Argo CD, Jenkins X, and Flux By Billy Yuen, Alexander Matyushentsev, Todd Ekenstam, and Jesse Suen https://www.manning.com/books/gitops-and-kubernetes

• The GitOps release workflow starts with creating a branch of the repository containing changes to the definition of the system’s desired state.

What is Flux?

• Command-line utility for assembling Kubernetes CD pipelines the GitOps way.
• The undertaking began in 2016 at Weaveworks and joined the CNCF Sandbox three years after the fact.
• Flux doesn’t present any extra layers on top of Kubernetes, for example, applications or its own access control framework.
• A single Flux instance oversees one Kubernetes cluster and requires the client to keep one Git repository that addresses the cluster state.
• Flux typically runs inside of the managed cluster and relies on Kubernetes RBAC. This approach significantly simplifies the Flux configuration and helps flatten the learning curve.
• In the multitenant climate, each team can install an instance of Flux with restricted admittance and use it to deal with a solitary Namespace. That completely engages the team to oversee assets in Namespace's application as yet 100% secure because Flux access is overseen by Kubernetes RBAC.

Components of Flux:

• The Flux daemon
• The key-value store Memcached (open-source, high-performance, distributed memory object caching system).

Benefits of using Flux

• Off-load the hassle of securely managing “kubeconfigs” in CI tools/Vault/buckets, etc.
• The deployment and release process is completely version-controlled.
• The implicit audit provided by Git.
• Roll-out production release on PR approval.
• No need to open a firewall between the CI tool and Kubernetes cluster. Promotes secure CI/CD.
• Increases confidence in Zero-Trust network implementation.
• Zero pipeline failures due to network disruption or node failures.
• Environments achieve their absolute state, as soon as Kubernetes cluster recovers from any disaster.
• Can be combined with Flagger for the automation of promoting canary deployments using Service Mesh like Istio.
• Extends support with GitHub, GitLab, Harbor, etc. with in-built webhooks.
• Can publish post-release alerts on Slack, MS Teams or SMTP.

System Requirements

To achieve this, we need KIND and Flux.

1. Setup development cluster using KIND (Kubernetes in docker)

Click on this link to install KIND on Linux, Mac or Windows.

• https://kind.sigs.k8s.io/docs/user/quick-start/#installation

2. Install & Configure Flux in Kubernetes Cluster

Click on the link for installing Flux operator on Kubernetes cluster.

• https://fluxcd.io/docs/installation/

GitOps in Action

• The GitOps implementation is categorized into the deployment of manifests and helm charts.
• Following is the step-by-step process to scaffold the Flux CD project:

1. Setup Git repository “app-flux-infra”

https://github.com/rajat965ng/app-flux-infra.git

2. Apply Kubernetes manifests (YAMLs)

2. a. Bootstrap Git repository in flux

flux bootstrap git app-flux-infra — url=https://github.com/rajat965ng/app-flux-infra.git -u <GIT_USERNAME> -p <GIT_PAT> — token-auth=true — path=./cluster/dev/

2. b. Create an Nginx deployment under cluster/dev

2.c. Observe the deployments rolling on git push and Query Flux to view the currently deployed revision

flux get all

2.d. Trace applied revision to match it with Git SHA

3. Apply Helm Chart

3.a. Create a Helm Chart “ms-template”

• mkdir helm-chart
• cd helm-chart
• helm create ms-template

3.b. Package Helm Chart

• To avoid bot crawling on my repository, add the following robots.txt file:
  echo -e “User-Agent: *\nDisallow: /” > robots.txt
• Lint the helm chart
  helm lint helm-chart/*
• Package helm chart
  cd helm-chart/ && helm package ms-template/
• Create index.yaml for ms-template
  helm repo index --url=https://rajat965ng.github.io/app-flux-infra/helm-chart/ .

3.c. How to convert GitHub repo into Helm repository?

• Click on Git repository “Settings”
• Scroll down options to choose “Pages”
• Select “Branch” -> “main” from dropDown and click “save”

3.d. Configure Helm Repository in Flux

• flux create source helm ms-template --interval=1m -n ms-template --url=https://rajat965ng.github.io/app-flux-infra/helm-chart/

3.e. Create Helm Release in Flux

• flux create hr app --source=HelmRepository/ms-template --chart=ms-template --interval=1m -n ms-template
• kubectl get po -n ms-template

3.f. Update the Helm Chart

• Update image tag from “1.16.0” — to → “1.20.0” in values.yaml and version “0.1.0” — to → “0.1.1” in Chart.yaml.

Package helm chart and update ‘index.yaml’

• git commit and push

3.g. Observe the Helm update rolling

• Release “0.1.1” is successfully rolled out with updated image tag “v1.20.0”

Conclusions

• The deployment of YAML manifests is successfully done and can be observed by matching Git SHA.
• The deployment of Helm Chart is successfully done and can be observed by matching chart version.
• Managed to set up GitOps with Flux in just 15 minutes.

References

• GitOps and Kubernetes — Continuous Deployment with Argo CD, Jenkins X, and Flux By Billy Yuen, Alexander Matyushentsev, Todd Ekenstam, and Jesse Suen [https://www.manning.com/books/gitops-and-kubernetes]
• KIND [https://kind.sigs.k8s.io/]
• Flux [https://fluxcd.io/]
• Source Code [https://github.com/rajat965ng/app-flux-infra]