Support scanning managedFields metadata (eg. to support server-side applied resources)

[reegnz]

Support scanning managedFields metadata (eg. to support server-side applied resources)

[aslafy-z]

Here is @reegnz's argo-cd issue: argoproj/argo-cd#16813

[reegnz]

Relying on managedFields would also mean inspecting helm releases is not necessary anymore. See helm/helm#9870

[sudermanjr]

This sounds great! I'm not super familiar with managed fields. Do they only get set when you use server-side-apply? My understanding is that it's not the default in many clients currently (for example ArgoCD).

[reegnz]

Only case where managedfields is not usable IMHO is when the client does it's own patch-ing, then it won't definitely be set AFAICT, only if the client is aware about setting it as well.

If a client uses kubectl directly to perform client-side apply, the kubectl client calculates the patch and invokes the patch commands, as well as setting a fieldmanager entry to kubectl-client-side-apply which lines up with whatever is present in the last-applied-configuration annotation.
So using managedFields doesn't strictly need server-side apply, it's a way of communicating who's managing a given set of fields, either with patch or server-side apply.

AFAIK ArgoCD uses kubectl client-side apply semantics by default. Sadly it doesn't seem to set the managedFields so it doesn't fully replicate kubectl behaviour.

I'll propose to the argocd project that argocd replicate what kubectl does and set the kubectl-client-side-apply field manager, or even an argocd-client-side-apply field manager so it's actually lines up with what kubectl is doing.

IMHO it's generally good practice to set a manager even if your client uses patches, so that it's reflected in the managedFields what client is patching a given field. But it seems like not everyone is following that practice yet.

Either way, fully removing inspection of the last-applied-configuration annotation is likely not a good idea at this point, as long as there's some really popular clients that do not utilize managedFields when imitating kubectl apply (in a faulty manner IMHO) using the kubernetes sdk.

tl;dr - utilizing managedFields by k8s clients enables tools like pluto to work regardless of how the manifest is manipulated, but it's the client's responsibility to communicate this info in a standardized manner. That standard is managedFields, and clients that don't create/update it are to be regarded as hidden (even broken IMHO), hurting visibility and observability. Pluto should continue looking at the kubectl annotation for backward-compatibilities sake, but it shouldn't be aware of additional tools that might be managing a given resource. Instead pluto should simply inspect managedFields.

[reegnz]

Checked fluxcd v2 kustomize-controller, it seems to use server-side apply already, so that would be an immediate win:
https://github.com/fluxcd/kustomize-controller/blob/92a078585ef8228f11541ec79da3dd0bc5a25b2a/internal/controller/kustomization_controller.go#L399-L402

[reegnz]

This is still very much an issue.