Skip to content
Latchkey

Flux Kustomization server-side apply / field manager conflict in CI

kustomize-controller uses server-side apply and hit a field ownership conflict. Another field manager (a controller, a webhook, or a manual kubectl edit) already owns a field that Flux is trying to set, so the apply is rejected.

What this error means

A Kustomization reports "False" with "reconciliation failed" and a server-side apply conflict naming the field and the competing manager.

kustomize-controller
Apply failed with 1 conflict: conflict with "kubectl-edit" using apps/v1: .spec.replicas

Common causes

A field is owned by another manager

Someone edited the resource with kubectl, or an autoscaler owns spec.replicas, so Flux's apply conflicts over that field.

Two controllers fight over the same field

A mutating controller keeps rewriting a field Flux also manages, producing a persistent apply conflict every reconcile.

How to fix it

Stop managing the contested field, or force ownership

  1. Decide whether Flux or the other manager should own the field.
  2. If a controller (like an HPA) owns replicas, remove spec.replicas from your manifest.
  3. If Flux should own it, allow it to take ownership so it stops conflicting.
kustomization.yaml
spec:
  force: true
flux reconcile kustomization apps

Identify the competing manager

Read managedFields to see which manager owns the field before deciding who should win.

Terminal
kubectl -n apps get deployment web -o yaml --show-managed-fields

How to prevent it

  • Do not manually kubectl edit resources that Flux manages.
  • Drop fields owned by autoscalers or other controllers from Flux manifests.
  • Decide a single owner per field to avoid recurring apply conflicts.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →