Kubernetes - Adventures - Argo-CD

From Push to Pull: How I Fully Embraced GitOps with Argo CD in My Confdroid developer cloud

After several days of experimentation, I have now fully implemented Argo CD — and the difference in day-to-day operations is night and day.

Here’s a clear before-and-after look at how my Kubernetes workflow has changed.

The Old Way (Push-Based Deployments)

Before Argo CD, my setup looked like this:

A single Git repository containing all raw Kubernetes manifests (YAML files) for both applications and core cluster components.
A CI/CD pipeline that used kubectl to connect to the cluster and (re)deploy everything — from the CNI and storage classes to Longhorn and other infrastructure pieces.
This pipeline acted as a safety net: if the cluster ever got into a bad state, a single pipeline run could restore it to a known-good configuration.
New applications could be added or updated simply by pushing changes to the repo. The pipeline would pick them up and apply them to the cluster.
Troubleshooting and manual adjustments were done directly with kubectl or a UI like the Kubernetes Dashboard, or in my case Headlamp. While convenient, this also opened the door to accidental changes — scaling a deployment and forgetting to update the manifests, for example.

Every git push triggered a push-based deployment. It worked well, but it relied heavily on discipline and perfect execution.

The New Way (Pure GitOps with Argo CD)

The old repository and pipeline still exist and continue to handle all low-level cluster reconfiguration (CNI, storage, base infrastructure, Argo CD configuration itself, including Keycloak integration). That safety net remains untouched. What changed is the introduction of a dedicated second repository dedicated to Argo CD-managed applications. Here’s how it works now:

Application manifests have been moved into the new Git repository.
Argo CD is installed and configured via the original pipeline.
Once running, Argo CD connects to the new repository and continuously synchronizes the cluster state with the desired state defined in Git. This requires one-off registration of the application via UI or CLI.
Synchronization can be triggered from the beautiful Argo CD web UI or via the CLI — the result is identical. Best though is setting auto-sync, which is what this is all about. This can be on done application level as required / desired.
Any drift is automatically corrected. If someone manually scales a deployment with kubectl or changes a ConfigMap in the dashboard, Argo CD will immediately revert it back to match the Git definition.
No more “I scaled it temporarily and forgot to update the YAML” accidents.
All changes — even small tweaks — must now go through Git. This enforces a true pull-based GitOps model. Stability over convenience!

Why This Feels So Much Better

Argo CD brings several powerful advantages:

It operates in a pure pull model, which is inherently more reliable than the previous push approach.
It can manage itself (though I chose not to enable that yet), multiple clusters, projects, and even different environments or stages — all without needing an external database.
The web UI is excellent. For every application, you can see pods, ReplicaSets, Services, ConfigMaps, and more at a glance.
As a massive bonus, it integrates beautifully with the Trivy Operator running in my cluster, displaying up-to-date vulnerability scan results directly in the Argo CD dashboard for each application.

Final Thoughts

Implementing Argo CD took me roughly four hours from start to finish, some fine-tuning pending — time extremely well spent.

Advertisements

The cluster now feels significantly more robust and predictable. By moving to a strict GitOps workflow, I’ve eliminated an entire class of human errors while gaining much better visibility and control.

This setup brings me noticeably closer to my goal of running cloud-native applications the way they were meant to be operated: declaratively, version-controlled, and automatically reconciled.

GitOps isn’t just a nice-to-have anymore — it has become the foundation of how I want to run Kubernetes going forward.

If you’re still managing Kubernetes with direct kubectl applies or traditional CI/CD push pipelines, I highly recommend giving Argo CD a try. The improvement in stability and peace of mind is immediate and very real.

In the next post of this series, I’ll share the exact steps I took to install and configure Argo CD with Keycloak integration, along with my recommended folder structure and best practices. Until then — happy deploying!

Did you find this post helpful? You can support me.