Skip to main content
Kubernetes supports two primary deployment methods: Imperative and Declarative. The Imperative approach relies on explicit kubectl commands to create and manage resources step by step. The Declarative approach uses YAML or JSON manifests to define the desired state of your cluster, which Kubernetes continuously reconciles. Choosing the right method helps teams optimize for speed, reproducibility, and maintainability in environments like Azure Kubernetes Service (AKS).
The image compares imperative and declarative approaches to Kubernetes deployment, highlighting specific commands and defined steps for imperative, and YAML/JSON manifests for declarative.

​
Imperative vs Declarative at a Glance

AspectImperative DeploymentDeclarative Deployment
DefinitionStep-by-step kubectl commandsDesired-state manifests (YAML/JSON)
ExecutionImmediate and manualAutomated reconciliation via control plane
IdempotencyNot guaranteed on rerunsAlways converges to desired state
Common Use CasesPrototyping, troubleshooting, demosProduction, CI/CD pipelines, GitOps

​
Imperative Deployment

Imperative deployment gives you direct control through explicit commands. Here’s a typical workflow: 
kubectl create deployment nginx --image=nginx
kubectl expose deployment nginx --port=80
kubectl scale deployment nginx --replicas=3
kubectl delete service nginx

​
Pros

  • Granular, step-by-step control
  • Instant feedback after each command
  • Perfect for ad hoc tasks: debugging, prototyping, one-off operations

​
Cons

  • Difficult to reproduce complex setups consistently
  • Lacks idempotency—rerunning commands can yield different results
  • Hard to track changes in version control
Imperative commands can introduce configuration drift if reused without validation. Always verify resource status with kubectl get or integrate into CI pipelines.
The image is a comparison of the pros and cons of imperative Kubernetes deployment. Pros include fine-grained control and flexibility, while cons highlight being more error-prone and lacking idempotency.

​
Declarative Deployment

In the declarative model, you define the desired state in a manifest file, and Kubernetes ensures the live cluster matches it. For example: 
# nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
Apply this manifest with: 
kubectl apply -f nginx-deployment.yaml

​
Pros

  • Desired-state management ensures consistency
  • Easy change tracking via Git and pull requests
  • Reusable manifests support automation and GitOps workflows
  • Simplifies scaling, rolling updates, and rollbacks

​
Cons

  • Requires governance on manifest changes to avoid unintended effects
  • Misconfigurations can lead to unexpected resource updates
Store all YAML/JSON manifests in a Git repository and enforce reviews to prevent accidental outages.
The image is a comparison of the pros and cons of declarative Kubernetes deployment. It highlights benefits like configuration management and version control, and notes the need for careful management.

​
Summary

  • Imperative deployment offers fast, hands-on commands ideal for quick experiments and troubleshooting.
  • Declarative deployment provides consistency, versioning, and automation by treating manifests as the single source of truth.
In practice, combine both approaches: use imperative commands for on-the-fly tasks and declarative manifests for robust, production-grade workflows.

Watch Video