[feature]: Add Patch functionality for CRD update

[vvitkovsky]

Is your feature request related to a problem? Please describe.

Hi all,

Unfortunately, Patch is not available in current KubeOps version, so if you have a big CRD, you need to send it full to Kubernetes API server even if you update only one field.

Best regards,
Victor

Describe the solution you would like

Currently KubeOps.KubernetesClient use Replace method to update content of CRD object, but there is also Patch that can be used to do this.

Additional Context

No response

[buehler]

Hey Victor,

You are totally right :-) Right now, there are no immediate plans to implement this feature.

[erin-allison]

What benefit would you be seeking from this?

In order for a patch function to be usable, we would have to calculate a diff from the previous version. This would either be done at run-time, and would involve querying for the existing CRD & doing the work in .NET or at compile-time, and would be restrictive in the number of different CRDs which would be tracked/supported.

How big of a CRD are you talking where this is an issue, especially if you're running in-cluster, where bandwidth to the control-plane is often a non-issue?

[vvitkovsky]

Hi Erin and Christoph,

First of all I'd like to say that you guys did a really huge work to implement all Kubernetes Controllers API in .net, I would say that KubeOps nowadays is the richest available open source project for .net that handles communication with Kubernetes API server, more richest is only original Go project, but not all people are coding on Go ).

In general you are definitely right - Kubernetes API service and clients are running in cloud in the same cluster, but in our project we need to have a client outside of the cluster, that's why I made a bug #558. We plan to use KubeOps on client side, that will work with our special HW in intranet and communicate with the cloud (and Kubernetes API server).

For Patch you also correct - it has some cons and pros, like having a deep copy of incoming object, creating Patch between original and modified objects etc. but for our case we definitely will need that to reduce amount of data in communication between client and Kubernetes API server. In general, those objects shouldn't be too big, but unfortunately it is always a compromise what to select - split one big object for several instances and handle each object type separately or to handle all similar data in one controller. Plus our data will have user-defined data as well, it can be really big.

Anyway, this is up to you to decide would you like to add this Patch functionality to KubeOps or not, I can do this in our project by myself, thanks that you have opened IKubernetesClient and also original IKubernetes interfaces, so I can build this on top of that, there are already some Json libraries that can be used for that like this: https://www.nuget.org/packages/JsonDiffPatch.Net

Or I can even contribute and extend IKubernetesClient and make pull request to KubeOps if you do not mind )

Thank you for your great work!

Best regards,
Victor

[SGStino]

A patch in the underlying ApiClient is easy enough as an extension method: Especially a (strategic) merge or apply patch:

        public static Task<V1Deployment> ApplyDeployment(thisIKubernetes client, V1Deployment deployment, string fieldManager, CancellationToken cancellationToken = default) {
            var @namespace = deployment.Namespace();
            var patch = new V1Patch(deployment, V1Patch.PatchType.ApplyPatch);
            var name = deployment.Name();
            return client.AppsV1.PatchNamespacedDeploymentAsync(patch, name, @namespace, fieldManager: fieldManager, cancellationToken: cancellationToken);
        }

For a magic client-side apply, it would involve a lot of specific custom logic to generate the patch, as you just don't want to automatically generate destructive patches to remove the kubernetes properties like ownerReference or UID and such.

But a server side apply instead of replace would be nice to have in the IKubernetesClient.