A gitops repo can never be the reflection of the system's actual state. It's a desired state your humans want the system to reach eventually, sometimes defined very loosely. This is the idea since Weaveworks invented the term years ago. Unfortunately I admit it's not very intuitive, especially to engineers who are not super familiar with declarative systems.

This happens a ton when bootstrapping, but in my experience doesn’t really happen that much when modifying existing infrastructure which is typically when you care about it being purely GitOps a bit more. Argo has all sorts of flaws around bootstrapping things that isn’t necessarily Argo’s fault but they manifest themselves (har har) in weird ways. For instance I do a lot of crossplane these days and the fact that Argo doesn’t sync CRD’s and force them to exist before future sync waves is a huge pain point, especially when you start to get to more complex applications that have lots of resources. You find yourself having to manually sync CRD’s because the default ordering logic doesn’t wait for the CRD to exist before creating the downstream resource - even if you’ve specified sync waves!

You may have to use Kargo as well, also by the makers of Argo

Ultimately probably not, under the hood all Argo is doing in its vanilla configuration is pulling stuff from a git repo, calculating a diff, performing some templating to spit out the manifest (helm or kustomize) and then kubectl apply the manifest (or the api equivalent of that).

So unless the API’s it uses to calculate deltas or apply manifests change it’s going to be mostly resilient. The underlying things it might apply though, are often much more sensitive to that kind of api version diff

Interesting. I've used Pulumi but this is the first I've heard of Kusion.

From a quick look, it still requires all of the resource specification to be present in the AppConfiguration, and it's written in their own DSL called KCL. Is there more to the use case that I'm missing?

It seems like if I'm already specifying the details of the entire workload, I'd either use Terraform, where I probably already know the DSL, or Pulumi, where I could skip the DSLs entirely.

Which is funny because ArgoCD is...miserable.

Like it just doesn't do anything other then clone a branch and run a blind kubectl apply - it'll happily wedge your cluster into a state requiring manual intervention.

Last I saw, ArgoCD was heavily reliant on Kubernetes.

Has this changed?

(also, it seems like the site is heavily supporting ArgoCD)

> ArgoCD is the defacto gitops standard now and has the lions share of gitops deployments.

That only covers pull-based GitOps. Push-based GitOps doesn't require Kubernetes, let alone magical Kubernetes operators, only plain old CICD pipelines.

The whole business model of cloud providers is to charge a premium for their ecosystem and to create lock-in by making everything interdependent. A Kubernetes deployment could cost 100k/yr a similar cloud deployment would be ~1m/yr.

It's not a black and white question. For you it doesn't make sense, for others it makes tons of sense.

> Does it really make sense to use Kubernetes in 2026? Especially in the cloud?

I can't tell if your comment is a joke or not.

For me, the key trait that makes gitops valuable is that it is declarative rather than imperative. The state of the git repo is the desired state of the system.

The key point there is that we don't have to worry about the existing state of the system. We don't have to worry that the api call made in your git pipeline actually failed, or that something else changed the system before your api call, and your state has drifted.

You can't replicate that by adding an API client to your git pipeline.

I am not sure how you end up with multiple git ops pipelines; ideally, you shouldn't be having multiple gitops pipelines. You should have a git repo that is defining the state, and then some reconciliation system that is checking the state of the system and the state of the repo, and taking any corrective actions needed to make the system state match the git state.

> With multiple git ops pipelines however, they start to get in the way of progress - especially when they need to be joined in series

Definitely, that's why systems like Zuul exist.

They're esoteric and require a lot of engineering discipline in patience- but in my experience most people who reach for gitops aren't doing it for a sense of "everything as code" (for the audibility and theoretical reproducibility of it) it's because they think it will allow them to go faster; and a tool like Zuul is hard to learn and will intentionally slow you down.

Because slow is smooth, and smooth is fast.

The system should undo state drift even if a run hasn't been prompted by changes to the upstream definitions in the repository

Git is just the repo store.

Everything you are referring to is the CI/CD pipeline. GitHub actions, Gitlab Runners, ArgoCD; they can all do some sort of gitops. Those dependencies existed before gitops anyway, so nothing new is being added.

We use flux for our gitops, and it is easy to bypass if we need to in an emergency.

You can disable reconciliation and then manually apply a change if your git repo is unavailable.

gitlab on internal network works quite well. You can still use K8 / EKS / AKS for runners etc, just run it all on the internal network. Im always surprised at how many orgs use public platforms for their code and ci/cd.

> Current employer actually prohibits this due to frequent outages in the git plant.

Even without knowing what you mean by git plant. I can tell you you're holding it wrong.

I'd like to help, but I can't offer useful suggestions if I have no idea what you're even doing, or prohibiting.

Ummm … github is not git … if you must, keep your git stored locally and simply use webhooks to keep it synced whenever changes are merged via your forge of choice… you can, if necessary, make updates to your locally hosted repo in the event of an outage at the forge, but you’ll need a procedure to “sync back” any changes made during the outage.

Fortunately, the whole thing is git based, so you have all the tools you need to do it.

> frequent outages in the git plant.

What are you talking about. And whatever it is, it’s wrong.

> Serious question: How do organizations deal with having git on the critical path for deployment?

You mean like storing source code? CICD pipeline definitions? Container image specs? IaC manifests? Service configuration files?

I don't think that arbitrarily drawing the line on what package version is being deployed is a rational opinion to have. I mean, look at npm's package.json. Is it ok to specify which dependency versions you bundle with your software, but specifying which version you're deploying is unheard of?

The only drawback I see in GitOps is that CICD pipelines are still lagging way behind on providing adequate visualization strategies to monitor the current state of multi-environment deployments.