Hi! I've been running kubenix on my homelab cluster for a while, and my deploy story has been pretty unsophisticated: nix build .#foo gives me a JSON, and a justfile recipe runs kubectl apply --server-side --force-conflicts -f result.
The reason I'm on server-side apply at all is that my kubenix-rendered manifests tend to grow chunky — once you start vendoring Helm charts, into kubenix, the resulting JSON gets big enough that client-side apply hits "metadata.annotations: Too long: must have at most 262144 characters ..." SSA sidesteps that. Ownership lives in metadata.managedFields (not an annotation) and the merge happens server-side against the OpenAPI schema. So I switched, and that's been working fine.
Then yesterday I had a "no healthy upstream" outage on my Forgejo instance. Traced it back to spec.replicas getting silently set to 0. At some point a stray kubectl apply (me poking at something) ran against the same object, and because both my justfile apply and the ad-hoc one used the default field manager ("kubectl"), ownership of replicas got orphaned.
Adding --field-manager=kubenix to my recipes fixed the symptom: kubenix-built manifests now own every field they declare.
So out of curiosity I went looking at the built-in CLI (pkgs/kubenix.sh) that I don't use to see what it does, and noticed:
- It uses client-side apply (
kubectl apply -f - --prune --all), not server-side.
- It doesn't pass --field-manager, so it inherits the default "kubectl" manager.
- There's no config option to inject extra flags; the apply line is hardcoded.
Which means: for anyone with manifests big enough to need SSA in the first place, the built-in CLI isn't really an option. And even if it were, it'd be vulnerable to the same field-ownership-orphaning that bit me.
What do people actually do here?
- Roll your own apply step (justfile / Makefile / shell), like I'm doing?
- Pipe the manifest into Argo CD / Flux / Kluctl?
Would there be interest in either (a) flipping the built-in to server-side + a kubenix field manager by default, or (b) exposing a small config knob (e.g. kubernetes.deploy.extraArgs and .fieldManager) so users can opt into SSA without forking the script? Happy to send a PR if (b) sounds reasonable.
Hi! I've been running kubenix on my homelab cluster for a while, and my deploy story has been pretty unsophisticated:
nix build .#foogives me a JSON, and a justfile recipe runskubectl apply --server-side --force-conflicts -f result.The reason I'm on server-side apply at all is that my kubenix-rendered manifests tend to grow chunky — once you start vendoring Helm charts, into kubenix, the resulting JSON gets big enough that client-side apply hits "metadata.annotations: Too long: must have at most 262144 characters ..." SSA sidesteps that. Ownership lives in metadata.managedFields (not an annotation) and the merge happens server-side against the OpenAPI schema. So I switched, and that's been working fine.
Then yesterday I had a "no healthy upstream" outage on my Forgejo instance. Traced it back to spec.replicas getting silently set to 0. At some point a stray
kubectl apply(me poking at something) ran against the same object, and because both my justfile apply and the ad-hoc one used the default field manager ("kubectl"), ownership of replicas got orphaned.Adding
--field-manager=kubenixto my recipes fixed the symptom: kubenix-built manifests now own every field they declare.So out of curiosity I went looking at the built-in CLI (pkgs/kubenix.sh) that I don't use to see what it does, and noticed:
kubectl apply -f - --prune --all), not server-side.Which means: for anyone with manifests big enough to need SSA in the first place, the built-in CLI isn't really an option. And even if it were, it'd be vulnerable to the same field-ownership-orphaning that bit me.
What do people actually do here?
Would there be interest in either (a) flipping the built-in to server-side + a kubenix field manager by default, or (b) exposing a small config knob (e.g. kubernetes.deploy.extraArgs and .fieldManager) so users can opt into SSA without forking the script? Happy to send a PR if (b) sounds reasonable.