# 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**.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1750833652735/7d03b1e7-ba72-43b0-a1ee-d3d51b0772ca.png align="center")

---

### **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:

```bash
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:

```bash
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:

```bash
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:

```bash
kubectl get deployment my-app -o yaml
```

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1750833774609/c6a0655b-14f2-42e3-a646-24411ff3b0d9.png align="center")

---

### **4\. Dry-Run with** `kubectl create`: Testing a New Resource

Before creating a resource, preview what Kubernetes **would do**:

```bash
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**:

```bash
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:

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

This **prevents accidental misconfigurations** before they happen.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1750833795712/aea5afcd-f307-4998-a8a7-a957408d7e6d.png align="center")

---

### **6\. Checking What Changes** `kubectl apply` Would Make

To see what **changes would be applied** without modifying anything:

```bash
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:

```bash
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:

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

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1750833809255/e890bded-ec2c-4053-80b5-f5fcad715913.png align="center")

---

### **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.** 🚀