Lab: Diff and Server-Side Apply

In a shared cluster, many people and tools change the same objects. How do you preview a change, before you make it? And how does Kubernetes avoid two tools overwriting each other, silently? The answers are, kube control diff, and server side apply. Both are small, and both prevent big accidents.

• Preview before you apply
• Many writers, one object
• Avoid silent overwrites

Preview with diff

First, we apply a deployment, with two replicas, of engine X one point twenty seven. Now we have a second version of the file. It asks for three replicas, and an older image. Before applying it, we ask, kube control diff. It prints exactly what would change, with a minus for the old line, and a plus for the new one. The generation, the replicas, and the image. Nothing has been changed yet. Making diff part of your review process, or your pipeline, catches a lot of surprises.

kubectl apply -f dep.yaml
deployment.apps/demo created
kubectl diff -f dep2.yaml | grep -E '^[+-] '
-  generation: 1
+  generation: 2
-  replicas: 2
+  replicas: 3
-      - image: nginx:1.27
+      - image: nginx:1.25

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: web
        image: nginx:1.27

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: web
        image: nginx:1.25

Server-side apply

Now we apply the change, with the server side flag. In this mode, the A P I server, not your computer, merges the change, and records which manager owns which field. If two managers try to set the same field, to different values, the server reports a conflict, instead of silently overwriting. Here, we ask for the managed fields, and see the managers listed, with their operations. This is how several tools, like a person, an autoscaler, and a Git ops controller, can share one object safely, each owning their own fields.

kubectl apply --server-side --force-conflicts -f dep2.yaml
deployment.apps/demo serverside-applied
kubectl get deployment demo --show-managed-fields -o yaml | grep -E 'manager:|operation:' | head -4
    manager: kubectl-last-applied
    operation: Apply
    manager: kubectl
    operation: Apply

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: web
        image: nginx:1.27

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: web
        image: nginx:1.25

Safe change habits

A few habits prevent most accidents. Always diff before you apply, especially in production. Prefer declarative files, in Git, to manual edits. Use server side apply, when several tools manage one object. Never edit live objects by hand, without recording the change, because the next apply may undo it. And watch for drift, between Git and the cluster, which Git ops tools detect, and correct. These habits make a shared cluster calm, and predictable.

Summary