Active Nerds
Module #36 · beginner Article

Imperative vs. Declarative Management: Infrastructure as Code with Kubernetes Manifests

Imperative commands (`kubectl run`, `kubectl create`) execute immediately and don't leave a record; declarative (`kubectl apply -f`) manages state via files...

3 min read+10 XPPublished 2026-05-21

Quick Answer: Imperative commands (kubectl run, kubectl create) execute immediately and don't leave a record; declarative (kubectl apply -f) manages state via files stored in Git — always use declarative in production.

Detailed Answer:

Imperative means telling Kubernetes how to do something step by step:

kubectl run nginx --image=nginx          # Creates pod directly
kubectl create deployment my-app --image=myapp:v1
kubectl expose deployment my-app --port=80

Declarative means telling Kubernetes what you want and letting it figure out how:

kubectl apply -f deployment.yaml        # Apply desired state from file
kubectl apply -f ./manifests/           # Apply entire directory

| | Imperative | Declarative | |---|---|---| | Speed | Faster for one-off tasks | Slower to set up initially | | Repeatability | Not repeatable | Idempotent — apply multiple times safely | | Version control | No audit trail | Full Git history | | Team collaboration | Doesn't scale | Standard across teams | | Best for | Quick debugging, generating YAML | All production use |

The Golden Workflow:

Use imperative commands to generate YAML, then use declarative to apply it:

# Generate YAML from imperative command — don't apply yet
kubectl create deployment my-app --image=nginx:1.27 \
  --dry-run=client -o yaml > deployment.yaml

# Edit the YAML, then apply declaratively
kubectl apply -f deployment.yaml

Key Takeaway: Use imperative commands only for learning or generating YAML scaffolding — all production changes should be declarative and stored in Git.


Finished reading?

Mark as complete to claim your +10 XP and track progress.