Dry-Run Mode: The "Are You Sure?" Button for Kubernetes

Picture this: You confidently type a kubectl apply command, hit enter, and watch in horror as half your cluster disappears into the abyss.

Congratulations, you just became the DevOps legend who accidentally deleted production.

If only Kubernetes had an "Are you sure?" button.

Oh, wait—it does. It’s called dry-run mode, and it lets you preview changes before actually applying them.

---

1. What Is --dry-run and Why Should You Care?

Dry-run mode is like a test drive for kubectl commands. It validates your changes, simulates execution, and tells you what would happen—without modifying anything.

Think of it as Kubernetes’ Undo button, except you run it before making a mistake, not after.

---

2. Using Dry-Run to Validate YAML Before Applying

Before applying a new deployment, run:

kubectl apply -f my-deployment.yaml --dry-run=client

This checks:
✅ If your YAML is valid
✅ If Kubernetes understands the resource
✅ If there are any syntax errors

But it does not create the resource.

If the output looks good, remove --dry-run=client and apply for real:

kubectl apply -f my-deployment.yaml

---

3. Testing a kubectl delete Before Destroying Everything

Accidentally deleting resources is painful. Before nuking anything, check what would happen:

kubectl delete deployment my-app --dry-run=client

If it shows "deleted", but you’re unsure, don’t run it without the flag yet. Instead, double-check your labels to ensure you're not deleting the wrong thing:

kubectl get deployment my-app -o yaml

Once you’re confident, then delete it for real.

---

4. Dry-Run with kubectl create: Testing a New Resource

Before creating a resource, preview what Kubernetes would do:

kubectl create configmap my-config --from-literal=key=value --dry-run=client

This ensures:
✅ The syntax is correct
✅ The resource name is valid
✅ Kubernetes would accept the request

If it works, remove --dry-run=client and apply for real.

---

5. Simulating a Patch Without Risk

Patching resources is powerful but also dangerous. Instead of blindly modifying a deployment, test the patch first:

kubectl patch deployment my-app --type=merge -p='{"spec":{"replicas": 5}}' --dry-run=client

If the output looks correct, then remove --dry-run=client and apply the patch:

kubectl patch deployment my-app --type=merge -p='{"spec":{"replicas": 5}}'

This prevents accidental misconfigurations before they happen.

---

6. Checking What Changes kubectl apply Would Make

To see what changes would be applied without modifying anything:

kubectl apply -f my-deployment.yaml --dry-run=server

The server option validates the request against the actual cluster API, unlike --dry-run=client, which only checks local YAML syntax.

This is useful when:

• The resource already exists, and you want to see what will change.

• You're applying changes to a live cluster and need to validate against its current state.

---

7. Combining Dry-Run with kubectl diff for Change Comparison

If you want to compare what’s different between your YAML and the existing resource in Kubernetes, run:

kubectl diff -f my-deployment.yaml

This highlights differences line by line, so you can see exactly what will change.

Bonus: Combine kubectl diff with --dry-run=server for maximum safety:

kubectl apply -f my-deployment.yaml --dry-run=server | kubectl diff -f -

Now you’re double-checking everything before it actually happens.

---

8. Why Every Kubernetes User Should Use Dry-Run

🔴 "Oops, I deleted the wrong thing!" → Dry-run would have warned you.
🔴 "Why isn't my YAML working?" → Dry-run would have caught the error.
🔴 "Did I just overwrite something important?" → Dry-run would have shown the diff.

Every kubectl apply, patch, delete, or create command should first be run with --dry-run=client.

Kubernetes is powerful but unforgiving. With dry-run mode, you’re no longer flying blind—you’re in full control.

Always check before you wreck. 🚀