When kubectl diff-watch shows a diff, we currently know what changed and when, but not who (or which controller/tool) made the change. Server-Side Apply (SSA) embeds exactly that information in managedFields — each entry carries a manager, operation (Apply/Update), and a time timestamp, scoped to the fields it owns.
Surfacing this attribution alongside a diff would close the "who triggered this?" question without requiring users to separately inspect the object.
SSA's managedFields is a field ownership index:
managedFields:
- manager: kubectl
operation: Apply
apiVersion: apps/v1
time: "2026-07-31T08:00:00Z"
fieldsType: FieldsV1
fieldsV1:
f:spec:
f:template:
f:spec:
f:containers:
k:{"name":"nginx"}:
f:image: {}
f:resources:
f:requests:
f:memory: {}
When a diff fires, it is trivially possible to cross-reference the changed YAML paths against the fieldsV1 entries and emit the responsible manager(s). This is conceptually what knight42/kubectl-blame does — it maps field paths to their SSA manager; and is a natural complement to what diff-watch already does.
References
When
kubectl diff-watchshows a diff, we currently know what changed and when, but not who (or which controller/tool) made the change. Server-Side Apply (SSA) embeds exactly that information inmanagedFields— each entry carries amanager,operation(Apply/Update), and atimetimestamp, scoped to the fields it owns.Surfacing this attribution alongside a diff would close the "who triggered this?" question without requiring users to separately inspect the object.
SSA's
managedFieldsis a field ownership index:When a diff fires, it is trivially possible to cross-reference the changed YAML paths against the
fieldsV1entries and emit the responsible manager(s). This is conceptually what knight42/kubectl-blame does — it maps field paths to their SSA manager; and is a natural complement to whatdiff-watchalready does.References