The opening episode of the GitOps series: the fundamental skills you need to master, the tools you must prepare, minimum hardware specifications, and how to verify your entire setup before diving into ArgoCD material.

Welcome to the Learn GitOps with ArgoCD series! In this series we'll build a modern deployment foundation from scratch: starting from understanding why GitOps exists, all the way to operating ArgoCD to manage applications in Kubernetes at a production level.
But before touching ArgoCD, there's one non-negotiable rule: GitOps sits at the intersection of many disciplines — Git, Kubernetes, YAML, containers, and CI/CD. If any one of those foundations is shaky, everything that follows will feel like building a house on sand. That's why episode 0 is dedicated to preparing the entire foundation: the skills you must have, the tools you need to install, hardware specifications, and verification steps so everything is ready as the series continues.
ArgoCD is essentially a Kubernetes operator that reads Git and materializes its contents into the cluster. So the skills below aren't just "nice to have" — they're "mandatory," because they'll be used in almost every episode.
GitOps means "all changes through Git." You should be comfortable with git clone, git add, git commit, git push, git pull, and git checkout. Don't stop there — also understand the concepts of branch and pull request, because in production, environment changes are never pushed directly to the main branch. PRs are the gate for review and audit.
ArgoCD materializes manifests into the cluster, so you need to understand Kubernetes core objects: Pod, Deployment, Service, ConfigMap, Secret, Ingress, and Namespace. Most importantly, understand the concepts of desired state and reconciliation: Kubernetes continuously aligns the actual state with the declared one — exactly the same concept ArgoCD applies.
Most of the GitOps work is writing and reading YAML. Make sure you understand indentation rules (spaces, not tabs), the key: value structure, lists, and how to read multi-document manifests (---). Don't worry about aesthetics — what matters is consistency and validity.
GitOps is part of CD (Continuous Delivery). You need to know the difference between CI (building and testing artifacts) and CD (delivering artifacts to environments). ArgoCD replaces the traditional "deploy stage," not the entire CI pipeline.
ArgoCD doesn't run containers, but the applications it manages are container images. Understand the basics of Dockerfile, how to build and pull images, and the terms registry and tag. Without this, image configuration in manifests will feel like a puzzle.
All demos in this series use the CLI. At minimum you should be comfortable navigating the terminal and reading command output. kubectl is your bridge to the cluster; every command ArgoCD performs can also be verified manually with kubectl.
Understand the fundamental difference between declarative (describing the desired end result) and imperative (writing out the steps to reach the result). GitOps is built entirely on the declarative paradigm. If this concept is still fuzzy, episode 1 will revisit it from its historical roots.
ArgoCD communicates with the cluster and Git repositories over the network. Get familiar with port, DNS, HTTPS, and SSH. That's enough to understand why ArgoCD needs access to a Git repository (HTTPS token or SSH key) and to the cluster API server.
| No | Tool | Function | Level |
|---|---|---|---|
| 1 | Kubernetes cluster (minikube, kind, k3s) | Target where applications are deployed | Required |
| 2 | kubectl | CLI to interact with the cluster | Required |
| 3 | Git client | Interact with repositories | Required |
| 4 | ArgoCD CLI (argocd) | Control ArgoCD from the terminal | Required |
| 5 | Helm | Package manager for Kubernetes | Required |
| 6 | Kustomize | Native Kubernetes configuration management | Required |
| 7 | Text editor / IDE (VS Code) | Write and edit manifests | Required |
| 8 | Docker Desktop | Local development and images | Optional |
| 9 | GitHub / GitLab account | Hosting manifest repositories | Required |
As for the local cluster choice, my recommendation: use kind or minikube because they're the lightest for a lab, and k3s if you want an experience closer to production. All of them are valid — pick whichever is most comfortable for your OS.
GitOps isn't heavy work for your laptop, but a local Kubernetes cluster is quite resource-hungry. Recommendations:
| Component | Minimum | Recommended |
|---|---|---|
| RAM | 8 GB | 16 GB+ |
| Storage | 20 GB free | 40 GB+ |
| CPU | Quad-core | Quad-core + |
| Internet | Stable | Stable |
Tip
A local cluster shares resources with the host OS. If your laptop has trouble with minikube or kind, try lowering the cluster resource allocation (e.g. --cpus 2 --memory 4096), or use a cloud VM for the lab.
After installing all the tools, verify each one with a single command per tool. Make sure there are no errors before moving on to the next episode.
kubectl version --client
kubectl cluster-info
kubectl get nodesIf you don't have a cluster yet, create one first:
kind create cluster --name gitops-lab
kubectl config current-context
kubectl get nodesWarning
Make sure kubectl config current-context points to the correct cluster. A wrong context is the most common cause of "manifests applied successfully but gone" — ArgoCD will deploy to whichever cluster is currently active.
Episode 0 is the gateway to this series. Here's what you must take with you:
In the next episode we dive into the most important part conceptually: the history of application deployment, the birth of GitOps by Weaveworks, the problems it solves, and why the pull model changes how we deploy. Make sure all tools are installed, because the hands-on material is about to begin!