# Take ownership of kubectl-managed resources

Use a one-time server-side apply takeover when an existing resource was
applied with `kubectl` and should now be managed by Kix.

This guide uses a Deployment as the example. Back up the live resource first,
and perform the takeover during a normal change window.

## Record the live resource

Save the resource before changing its ownership:

<Command
  commands={[
    "kubectl get deployment legacy-web -n takeover -o yaml --show-managed-fields > legacy-web.before.yaml",
  ]}
/>

Keep any fields your workload relies on, especially immutable selectors,
Service selectors, volume claims, and identity-bearing names. The
`managedFields` section also shows which manager owns each part of the object.

## Make the Kix definition match

Configure the package instance with the live Deployment's selector and the
state you want Kix to manage:

<Snippet {...kubectlManagedWorkload} />

The example retains the existing `app` and `tier` selector. Its desired replica
count is two, while the kubectl-managed fixture has one replica.

Check the cluster before contacting Kubernetes:

<Command {...check} />

Inspect the rendered Deployment:

<Command {...desiredDeployment} />

Compare it with `legacy-web.before.yaml`. Do not continue if the rendered
resource changes an immutable selector or omits a field the workload still
needs. Correct the package configuration first.

## Confirm the ownership conflict

Run an API-server dry run without taking ownership:

<Command expandable {...conflict} />

Kix discovers live state through its management labels, so `kix diff` does not
compare a resource that Kix has not managed before. The deployment dry run
sends the intended manifests to the API server without persisting them.

The API server rejects a change when another field manager owns a field Kix is
trying to change. The error identifies the resource and points to
`--force-conflicts`.

By default, the run stops after the first conflict and ends with `1 failed, 4
cancelled`. The cancelled resources have not been checked. Run the dry run
again with `--on-error continue` to find conflicts on the remaining resources:

<Command
  commands={[
    "kix deploy how-to-adoption-takeover --dry-run -y --on-error continue",
  ]}
  cwd="kix-examples/"
/>

This still skips resources that depend on a failed resource, but continues
checking independent branches of the dependency graph. Review every reported
field against the saved resource before using `--force-conflicts`.

## Take ownership once

When the diff and conflicting fields are expected, deploy with
`--force-conflicts`:

<Command {...takeOwnership} />

The flag tells server-side apply to transfer conflicting fields in the Kix
manifest to the `kix` field manager. Fields that Kix does not specify remain
with their existing managers.

Check the result and save its field ownership:

<Command
  commands={[
    "kix status how-to-adoption-takeover",
    "kubectl get deployment legacy-web -n takeover -o yaml --show-managed-fields > legacy-web.after.yaml",
  ]}
  cwd="kix-examples/"
/>

Use ordinary `kix deploy how-to-adoption-takeover` commands after the takeover.
Do not leave `--force-conflicts` enabled for routine deployments, because a
later conflict may represent another controller making an intentional change.

:::note[Explanation]
See [Server-side apply field ownership and drift](/docs/explanation/server-side-apply-field-ownership-and-drift/)
for how Kix and other field managers can share one Kubernetes object.
:::