While closing the #92913 fixed a problem for structured selectors across k/k api, there is still a great deal of unstructured selectors across different resources as a map[string]string. So a similar problem is present - SSA does not work for modifying these when a multiple source-of-truths attempting to manage this field in parallel.

Say a user and a controller is doing changes to the resource.selector field. If a user changes (appends) a key: value to the map, he completely alters the behavior for the resource. The controller can't do anything with it, as SSO treats the map as granular resource by default. So you have to fall back to a usual get/compare/update for changes like that, or you can't guarantee the declarative behavior for your controller, which is supposed to set and maintain the fields it cares about as it expects it to be looking.

What happened:
Here is a resource:

apiVersion: v1
kind: Service
metadata:
  name: test
  namespace: default
spec:
  ports:
...
  selector:
    test: test

1. User uses kubectl apply --server-side -f svc.yaml, the resource is applied.
2. A controller for this resource reconciles its changes, and applies a patch with

apiVersion: v1
kind: Service
...
  selector:
    my: app

3. The resource contains both values in spec.selector map and fails to do the job with existing infrastructure, as the selector does not match any of the resource labels.

...
  selector:
    my: app
    test: test

What you expected to happen:

Step 2 applies a selector as an atomic value, so the resource in step 3 looks more like

...
  selector:
    my: app

How to reproduce it (as minimally and precisely as possible):

See what happend section

A followup to #92913

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version): 1.20
• Cloud provider or hardware configuration: does not matter