DEV Community

Cover image for Kubernetes GitOps: A Beginner's Guide with a Hands-On Tutorial
Pavan Belagatti
Pavan Belagatti

Posted on

Kubernetes GitOps: A Beginner's Guide with a Hands-On Tutorial

Kubernetes has become the talk of the town for many years now.
It has revolutionized the orchestration of containers and has become a leader in this field. Many developers love working with Kubernetes. While organizations prefer deploying applications on Kubernetes to cope with the scale and demanding resources, a new approach is trending regarding Kubernetes-related deployments - GitOps.

Yes, GitOps provides a smooth way and a set of practices to leverage simple tools like Git to manage infrastructure and application deployments. By combining Kubernetes and GitOps, organizations can reap the enormous benefits of flexibility, agility, scale, performance, efficiency and faster feature delivery.

In this guide to Kubernetes and GitOps, I have a step-by-step beginner-level tutorial to start implementing GitOps with Kubernetes. It is time to take your application deployment to the next level. Let's get started!

Simple GitOps Workflow

GitOps basically works on the principle of making Git the source of truth, including moving everything to code and storing and maintaining everything in Git. When it comes to deployment, make use of an operator to deploy what is configured in Git and Yaml in a declarative fashion. Since all the developers are primarily friendly with Git, GitOps simplifies their complex workflow.

gitops workflow

So when it comes to Kubernetes, the app code, container images, and all related manifest files will be stored in Git, and any changes are made through Git as a single source of truth.

Note: The above content is taken from my other GitOps article written on the Dev community. Read!

Today, we will show you how to get started with the GitOps approach for your application in the below tutorial.


  • In this tutorial, we will use a continuous delivery tool such as Harness to do GitOps. Hence, create a free Harness account. It uses Argo CD-as-a-Service.
  • GitHub account and a sample repo to experiment with. I have a sample repo you can fork it and use.


Signup to Harness account, verify your email and sign back in again to set up the GitOps pipeline.

You will be presented with the below deployment options - Kubernetes and Kubernetes with GitOps.

Select 'Kubernetes with GitOps' and continue.
Kubernetes with GitOps

You don't have to worry about any set up and installation. Harness takes care of everything. It connects to Harness by provisioning hosted agent.
hosted agent

You can click 'provision' and wait for some time to get green checkbox for your agent.

Once the agent gets installed successfully, get to the next configuration.

This is where we provide simple details like source, authentication and Git details.

Select Git and own source code from the options. Add our Git repo link -

Note: Above shown is my GitHub repo link, you should add your repo link, the one you forked at the beginning of this tutorial.

Once you add these details, make sure to add 'Anonymous' to authenticate your details. [BTW, its a public repo and hence no authentication is needed with username and password]

Make sure the authentication is successful.
authentication is successful

Next, let's add the other required Git details as shown below.
git details add

Select Target revision as 'master' and Path as 'helm-guestbook'
git repo details

Next, select 'Harness Hosted' to test the GitOps workflow. You can choose self-managed too. But for this tutorial, we will select 'Harness Hosted'.
harness hosted

Click the 'Connect to Cluster' button and make sure the connection is successful.
connect to cluster

Next, you will see the last step where we are all set to deploy the application.
deploy app

Click on 'Create and Sync Application'.

This is the GitOps dashboard you will enter where all your GitOps details will be present.
gitops dashboard

You will see the 'Sync' status running.
sync status

In a minute or two, we can see the successful message.
sync successful

You can check each tab starting from the 'Resource View'
resource view

These are the 'App Details' tab features shown below.
app details

In the same tab, you can see the sync policy, it is set as 'manual', change it to 'Automated'.


This means, when any changes happen to your GitHub repo, the GitOps agent will pick those changes automatically and syncing will happen in an automated fashion.

The next tab shows the sync status of the application.
sync status

The manifest tab shows the manifest details of the application.
manifest details

In the main dashboard, go to the 'GitOps' tab is the entry to your GitOps workflows.
gitops workflow

Once you click on the 'GitOps' tab, you should see the overview of your GitOps dashboard.
gitops dashboard new

If you click on the application, you should see our application.
application tab

You click on it and go to the Resource view. You will see 4 replicas running as mentioned in our values.yaml file.
values file

This is our values.yaml file from the example repo.

# Default values for helm-guestbook.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 4

  tag: 0.1
  pullPolicy: IfNotPresent

  type: ClusterIP
  port: 80

  enabled: false
  annotations: {}
    # nginx
    # "true"
  path: /
    - chart-example.local
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local

resources: {}
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
  # limits:
  #  cpu: 100m
  #  memory: 128Mi
  # requests:
  #  cpu: 100m
  #  memory: 128Mi

nodeSelector: {}

tolerations: []

affinity: {}
Enter fullscreen mode Exit fullscreen mode

Now, change the replicaCount: 4 from 4 to 5.
replicas changed

You should see that the GitOps agent will see this difference and picks it up. Suddenly the application configuration goes out of sync. Takes some time to match up and gets back to the healthy and successful sync state.
app config

You can see the second deployment as 'Automated' since we changed the sync policy to automated.
automated sync

Well, after some time, the application configuration state shows a healthy and successful sync state.
healthy and success

In the above resource view, you can see that the replicas have been matched to 5 as we wanted 5 replicas.

As GitOps uses Git as the source of truth, it keeps a record of who committed what code and if someone changed something in the repository. You can see this from our GitOps dashboard.
git chanaged

Once you click on that id number shown in red box above, you can see what changed.
replica count changed

This is how intuitive and simple it is to deploy applications via the GitOps way using Harness CD.

Kubernetes GitOps is a fantastic approach to handling complex cloud-native application deployments. Since it uses a simple tool like Git that developers already know, it becomes easy to learn and streamline your application deployment approach. Make your applications more stable, agile and efficient with Kubernetes GitOps. Get started with GitOps today!

Top comments (9)

anurag_vishwakarma profile image
Anurag Vishwakarma

Detailed Article 📚. Keep it up...

pavanbelagatti profile image
Pavan Belagatti


denniskahlerlon profile image

super hands on. thx!

pavanbelagatti profile image
Pavan Belagatti

Glad you liked it. Thanks:)

shoksuno profile image
Gianni Carafa

Interesting. The concept is very similar to Kubero, an open-source Heroku alternative for Kubernetes I developed over the last year.

The only pity is that the GUI is not open source (or I was not able to find it) and needs to run on thirdparty infrastructure.

bcouetil profile image
Benoit COUETIL 💫

What would you say to someone like me, which is deploying using traditional optimized pipelines less than 5 minutes, to make me move to GitOps ? What is the main reason ?

pavanbelagatti profile image
Pavan Belagatti

Simplicity is the main reason. Easy tracking of changes as Git is the main tool used for all the references. And also, all your manifest files are stored as one place i.e, Git. So ya, why not use it when the software delivery can be so easy with GitOps?
One more point is the less learning curve with this approach.

bcouetil profile image
Benoit COUETIL 💫

OK, I understand that the difference is not GitOps, I already do GitOps.

But I use "push" approach (my pipelines deploy to the cluster), and you are using a "pull" approach (ArgoCD in the cluster pulls from the Git repo).

What are the benefit of your approach over mine ?

Thread Thread
pavanbelagatti profile image
Pavan Belagatti

The main benefit is without having to manually deploy. Git commits by developers do everything, from code commit to deployments. That's the easiest answer I can say.