Skip to content

Managing Dependent Resource Create/Update and Matching with Server Side Apply #1933

Closed
@csviri

Description

@csviri

The problem:

Currently we are using post/put operations to create and update resources in dependent resources if needed. And we also introduce various way to match if the desired state is the same as the actual state from the server. In theory in some cases would be enough just to compare if the spec (and label and/or annotations) are same on the desired and actual to match the resources. However Kubernetes fills some default values and/or mutation hooks and other controllers can also fill some additional fields in a resources, thus simple compare in those cases won't work, also replacing the spec during the update would remove those (would be again added, but that is not that nice). So we introduced additional enhanced mechanisms, like just check if there were some additions on server side compared to desired state. This works mostly, however it causes a problem when some wants for example delete a list item from a desired resource, in that case it will still match the server since the diff looks like that just values added. Further possibilities were presented to the user, like ignore lists, but those needs to be explicitly configured.

Solution:

For create and update we can use SSA, this will make sure that we update all the target fields we manage / care about. This is basically trivial to implement.

What we can do however is to implement the matching also based on SSA managedFields:
We just compare the desired resource to the resource from the server but only the fields which are managed by us. So if the managed fields (by controller) of the actual resource from server are identical with compared desired fields of a resource, we consider it as a match.

The problem with this matching approach is that it quite hard to prune the actual resource based on the managed field on client side, mainly because k8s lacks documentation of the managed fields structure.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions