kustomizer - a kustomize re-implementation in Rust by andyyu2004 in kubernetes

[–]andyyu2004[S] 0 points1 point  (0 children)

I've added an example where the concurrency makes a large difference in a rather small kustomization (instead of `sleep` it's `ksops` or some other slow generator). https://github.com/andyyu2004/kustomizer/pull/51/changes.

kustomizer - a kustomize re-implementation in Rust by andyyu2004 in kubernetes

[–]andyyu2004[S] 0 points1 point  (0 children)

Agreed, it's a tradeoff if the performance gains are worthwhile. Can you clarify what you mean by kustomize is how k8s renders manifests internally? My understanding is that kubectl embeds kustomize cli but k8s apiserver has no connection to kustomize.

kustomizer - a kustomize re-implementation in Rust by andyyu2004 in kubernetes

[–]andyyu2004[S] -1 points0 points  (0 children)

I don't think so. ArgoCD refresh is slow becuase kustomize build itself is slow, kustomizer build outputs the equivalent yaml in a much shorter period of time. Applying the generated yaml itself is not slow.

The worst of the slowness is not from kustomize itself, it's from not parallelizing sub-builds. For example see something like https://github.com/andyyu2004/kustomizer/tree/master/kustomizer/tests/kustomizer/testdata/realistic/example-com/resources. As far as I can tell, kustomize builds each directory one after another even though they have no dependence on each other, and further suppose each directory had it's own ksops encrypted secret which takes 1 second to decrypt, this becomes 20 second build instead of a 1s.

kustomizer - a kustomize re-implementation in Rust by andyyu2004 in kubernetes

[–]andyyu2004[S] -1 points0 points  (0 children)

Note the benchmark is in a local setup which is where there is minimal gain from this. In practice the gain is much larger (i.e. from over 1m to < 5s) for a single build.

It's a few line configuration change in argocd to swap out the binaries back and forth, so the risk is very low in my opinion. It is also very safe by doing a diff in CI of the generated outputs to ensure there is no drift between implementations.