Add kubernetes.apply operation for server-side apply with field manager support

[Cali0707]

Motivation

When writing eval tasks that test SSA (server-side apply) behaviors, we need to set up resources with specific field ownership. The current kubernetes.create operation uses a standard create, which doesn't establish SSA field manager ownership. This makes it impossible to write evals that verify SSA-specific scenarios (e.g., field abandonment across sequential tool calls).

Concrete use case: containers/kubernetes-mcp-server#1164 — we need an eval that sets up a deployment with resource limits owned by a specific field manager, then verifies those fields survive a subsequent partial apply from an MCP tool.

Proposed API

Add a kubernetes.apply operation that performs server-side apply with configurable field manager:

- kubernetes.apply:
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: payment-service
      namespace: ssa-test
      labels:
        app: payment-service
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: payment-service
      template:
        metadata:
          labels:
            app: payment-service
        spec:
          containers:
          - name: payment
            image: nginx:latest
            resources:
              requests:
                cpu: 100m
                memory: 128Mi
              limits:
                cpu: 500m
                memory: 512Mi
    # Operation options (not part of the resource manifest)
    fieldManager: "kubernetes-mcp-server"  # optional, defaults to "mcpchecker"
    force: true                            # optional, defaults to false

Parameters

Parameter	Type	Required	Default	Description
apiVersion	string	yes	—	Resource apiVersion
kind	string	yes	—	Resource kind
metadata	object	yes	—	Resource metadata (name, namespace, labels, etc.)
spec / other fields	object	no	—	Resource spec and any other standard fields
fieldManager	string	no	"mcpchecker"	SSA field manager name for ownership tracking
force	boolean	no	false	Force apply, taking ownership of conflicting fields

Returns

Same shape as kubernetes.create:

• name: Resource name
• namespace: Resource namespace
• uid: Resource UID
• resourceVersion: Resource version

Design notes

• The API mirrors kubernetes.create for consistency — the resource manifest is inline at the top level, with operation options (fieldManager, force) alongside it. These don't conflict with standard Kubernetes resource fields.
• Under the hood, this uses the dynamic client's Apply() method with metav1.ApplyOptions.
• This is an upsert operation (create if not exists, update if exists), matching Kubernetes SSA semantics.
• The force option is important for taking ownership of fields managed by other controllers during test setup.

Example eval usage

kind: Task
apiVersion: mcpchecker/v1alpha2
metadata:
  name: ssa-field-preservation
spec:
  requires:
    - extension: kubernetes

  setup:
    - kubernetes.delete:
        apiVersion: v1
        kind: Namespace
        metadata:
          name: ssa-test
        ignoreNotFound: true

    - kubernetes.create:
        apiVersion: v1
        kind: Namespace
        metadata:
          name: ssa-test

    # Simulate a prior MCP tool call that set resource limits
    - kubernetes.apply:
        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: payment-service
          namespace: ssa-test
        spec:
          # ...
        fieldManager: "kubernetes-mcp-server"
        force: true

    - kubernetes.wait:
        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: payment-service
          namespace: ssa-test
        condition: Available
        timeout: 120s