Brian Grant

I haven't seen this behavior of k8s modifying git. Typically it is as you describe, desired state comes from git and is fed to k8s, k8s then attempts to make that a reality.

The issue is k8s mutates the resources under its own management in ways that conflict with declarative representation in git. Requiring merge on rollout.

I see, yeah, basically "kubectl apply" is required, is not a pure update, but a merge process. The only thing I wish k8s had done differently there would be that spec and status were two different resources. But that's the beauty of hindsight.

K8s itself is a distributed system with bidirectional state mutation (lots of concurrency). It doesn’t take a distributed systems master to anticipate these issues. Ironically, using git as the k8s backend would have at least been functionally correct.

i don't think you really give enough credit to k8s here. k8s is a system that allows mutation, but bidirectional, as you say, is not a core tenet and would be more a flaw in implementation. i think you'd prefer a system based on immutable data, which I too think is compelling

Immutable data is a convient way to skirt concurrency problems in a distributed system. My issue is that k8s claims ownership of the resource version identifier, that it usually leads the versions in VCS, and requires non-trivial merge downstream from git (the gitops master).

Are you talking about mutation in, for example, number of pods deployed? Or something more substantial?

The field or kind doesn’t really matter. Some are more immutable than others but that’s detail. Git + k8s is a multi-master system where the state is mutated in both. Collisions are going to happen.