Live data from Hacker News

OpenGitOps

opengitops.dev

31–40 of 51 posts

Re: OpenGitOps

#31
post #27

Does it really make sense to use Kubernetes in 2026? Especially in the cloud? I think it’s just adding unnecessary layers, increasing operational debt, and complicating the developer experience.

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

Re: OpenGitOps

#32
post #27

Does it really make sense to use Kubernetes in 2026? Especially in the cloud? I think it’s just adding unnecessary layers, increasing operational debt, and complicating the developer experience.

> 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.

Re: OpenGitOps

#33

Earlier quoted context omitted.

> The whole premise of opengitops is heavily reliant on kubernetes. There's indeed a fair degree of short-sightedness in some GitOps proponents, who conflate their own personal implementation with the one true GitOps. Back in the real world, the bulk of cloud infrastructure covers resources that go well beyond applying changes to pre-baked Kubernetes cluster. Any service running on the likes of AWS/Google Cloud/Azure…

> and Kubernetes operators neither cover those nor are a reasonable approach to the problem domain. I mean Crossplane is a pretty popular k8s operator that does exactly that, create cloud infrastructure from K8s objects.

> I mean Crossplane is a pretty popular k8s operator that does exactly that, create cloud infrastructure from K8s objects.

If your only tool is a hammer then every problem looks like a nail. It's absurd how anyone would think it's a good idea to implement their IaC infrastructure, the one think you want and need to be bootstrapable, to require a full blown K8s cluster already up-and-running with custom operators perfectly configured and working flawlessly. Madness.

Re: OpenGitOps

#34
post #30
post #26

Earlier quoted context omitted.

Would you mind elaborating on this more, describing the differences and how tools like Zuul introduce degrees of friction that result in smooth operation and pipelines? I know my phrasing may come off wrong, I apologize for that. But I'm asking genuinely; I've only ever seen Zuul in the wild in the Red Hat and OpenStack ecosystems.

Right, so Zuul is properly interesting if you're dealing with multi-repo setups and want to test changes across them before they merge; that's the key bit that something like GitLab CI doesn't really do. The main thing with Zuul is speculative execution. Say you've got a queue of patches waiting to merge across different repos. Zuul will optimistically test each patch as if all the patches ahead of it in the queue ha…

> Right, so Zuul is properly interesting if you're dealing with multi-repo setups and want to test changes across them before they merge; that's the key bit that something like GitLab CI doesn't really do.

I'm not sure about that. Even when we ignore plain old commits pushed by pipeline jobs, GitLab does support multi-project pipelines.

https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#m...

Re: OpenGitOps

#35
I’m less positive about GitOps. GitOps is a lie. I’ve never seen software that actually manages to adhere to the ‘repo is the state’ principle. Inevitably you push something, it doesn’t work, now you have to do something out of band or revert to get it working again. Sometimes you revert and it’s still not fixed…

Looking at you Argo CD.

Re: OpenGitOps

#37

Earlier quoted context omitted.

> and Kubernetes operators neither cover those nor are a reasonable approach to the problem domain. I mean Crossplane is a pretty popular k8s operator that does exactly that, create cloud infrastructure from K8s objects.

> I mean Crossplane is a pretty popular k8s operator that does exactly that, create cloud infrastructure from K8s objects. If your only tool is a hammer then every problem looks like a nail. It's absurd how anyone would think it's a good idea to implement their IaC infrastructure, the one think you want and need to be bootstrapable, to require a full blown K8s cluster already up-and-running with custom operators perf…

I hope someone somewhere has managed to run a K8s cluster on a bunch of EC2 instances that are themselves described as objects in that K8s cluster. Maybe the VPC is also an object in the cluster.

Re: OpenGitOps

#38

Earlier quoted context omitted.

> and Kubernetes operators neither cover those nor are a reasonable approach to the problem domain. I mean Crossplane is a pretty popular k8s operator that does exactly that, create cloud infrastructure from K8s objects.

> I mean Crossplane is a pretty popular k8s operator that does exactly that, create cloud infrastructure from K8s objects. If your only tool is a hammer then every problem looks like a nail. It's absurd how anyone would think it's a good idea to implement their IaC infrastructure, the one think you want and need to be bootstrapable, to require a full blown K8s cluster already up-and-running with custom operators perf…

Its more of a usecase for large platform teams that want to automate and enable hundreds of teams with thousands of disparate cloud resources.

You can have a small bit of terraform for crossplane then crossplane for the 99% of the other resources

Re: OpenGitOps

#39
post #27

Does it really make sense to use Kubernetes in 2026? Especially in the cloud? I think it’s just adding unnecessary layers, increasing operational debt, and complicating the developer experience.

> 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.

That in itself is an answer :D

Re: OpenGitOps

#40
Both FluxCD and ArgoCD, which use CRDs in Gitops, have a serious flaw: will these tools fail when your Kubernetes needs an update? I've encountered incompatibility issues even with simple Helm (which failed due to changes in the HPA API), let alone OPSs that forcibly depend on CRDs. GitLab CI + Pulumi/Kusion is the most stable solution.
Post reply on HN