GitOps: Episode Two — Setting Up a GitOps-Ready Kubernetes Cluster

Learn how to prepare your Kubernetes cluster for GitOps. We’ll install tools, structure the repo, and get ready to deploy with FluxCD.

GitOps: Episode Two — Setting Up a GitOps-Ready Kubernetes Cluster
Photo by Tracy Adams / Unsplash

Now that we understand what GitOps is and how it differs from traditional CI/CD, it’s time to get practical.

In this post, we’ll set up a GitOps-ready Kubernetes cluster — the foundation for everything we’ll do in the rest of the series. Our goal is to prepare an environment where a GitOps controller (FluxCD, in our case) can run, watch a Git repo, and continuously sync changes.

Whether you’re running Kubernetes locally with tools like kind or minikube, or working with a managed service like GKE, EKS, or AKS, the core setup process remains the same.

Let’s dive in.

1. What Makes a Cluster “GitOps-Ready”?

Before we start installing tools, it’s important to define what we actually need.

A GitOps-ready cluster is:

  • Accessible via kubectl
  • Configured with basic role-based access control (RBAC)
  • Capable of running a GitOps controller like Flux or Argo CD
  • Connected to a Git repository where configurations live

In short, it’s a Kubernetes cluster that’s prepared to follow instructions from Git — automatically and continuously.

Think of it like hiring a new team member (your GitOps agent). Before they can work, they need a desk (cluster access), a job description (your Git repo), and permission to do things (RBAC).

2. Tooling: What You’ll Need

Here are the main tools we’ll use:

  • kubectl: The CLI tool for interacting with Kubernetes
  • flux: The FluxCD CLI, which we’ll use to bootstrap GitOps
  • Helm (optional): For managing applications and dependencies
  • A GitHub (or GitLab) repository: Where your config files will live
  • A running Kubernetes cluster: Local or cloud

If you don’t already have a cluster running, kind (Kubernetes in Docker) is a great way to get started locally. Here’s a quick command to spin up a kind cluster:

kind create cluster --name gitops-demo

Once it’s ready, verify access with:

kubectl get nodes

3. Installing FluxCD

Flux is the tool we’ll use throughout this series to bring GitOps into action. It runs in the cluster, watches your Git repo, and applies changes as needed.

We’ll start by installing the Flux CLI:

brew install fluxcd/tap/flux

Now let’s check if it’s installed:

flux --version

Once that’s done, you can use Flux to bootstrap your cluster and connect it to a Git repository.

4. Bootstrap Your Cluster with Flux

The simplest way to set up GitOps with Flux is using the flux bootstrap command. This initializes your cluster with Flux components and connects it to your Git repository.

Here’s a basic example using GitHub:

flux bootstrap github \
    --owner=your-github-username \
    --repository=your-repo-name \
    --branch=main \
    --path=clusters/my-cluster \
    --personal

What this does:

  • Installs Flux controllers in your cluster
  • Creates a directory structure in your Git repo
  • Starts syncing the cluster with the contents of that repo

You’ll need a GitHub personal access token for this step. Make sure it has repo and workflow permissions.

Once the bootstrap is complete, you can confirm that Flux is running:

5. Directory Structure for GitOps Repos

Flux uses a specific folder layout in your repo to determine what to apply and where. A common structure looks like this:

your-repo/
└── clusters/
    └── my-cluster/
        ├── apps/
        ├── infra/
        └── kustomization.yaml

This structure separates your infrastructure, applications, and environments, making it easier to manage and scale over time.

Don’t worry if this seems abstract — we’ll build it up in future posts with real examples.

6. What’s Next

Congratulations! You now have a Kubernetes cluster with FluxCD installed and connected to a Git repo. This is the core of GitOps — the ability for your infrastructure to stay in sync with code stored in Git.

In the next post, we’ll:

  • Create real configuration files
  • Deploy a sample application
  • Watch GitOps in action as changes are automatically applied

This is where it starts getting fun — and real.

See you in Episode Three!


Previous Posts in the Series


Want to keep learning GitOps with me? Subscribe to get future posts delivered as soon as they go live!