Difference between Imperative and Declarative management in Kubernetes
Tags: kubernetes, declarative, imperative, devops
Published: 2023-03-14 04:44:34



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7hfgxd7qkxirv41tmij0.jpg)
Photo by : [](Photo by <a href="https://unsplash.com/@alexacea?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Alexandru Acea</a> on <a href="https://unsplash.com/photos/XEB8y0nRRP4?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>
  )

In Kubernetes, there are two approaches to managing resources: 

- Imperative

- Declarative


## Imperative Management

In the imperative approach, the user specifies exactly what needs to happen to the Kubernetes resources. This means that each command tells Kubernetes to perform a specific action, such as creating a pod, scaling a deployment, or updating a service. In other words, imperative management involves telling Kubernetes how to make a change happen.
Here's an example of an imperative command that creates a pod with a specific name and image:
css

```
kubectl run my-pod --image=nginx
```

The above command tells Kubernetes to create a pod named my-pod with the nginx image.

## Declarative Management

In the declarative approach, the user specifies the desired state of the Kubernetes resources, and Kubernetes figures out how to make it happen. This means that the user declares the desired configuration of the resources, and Kubernetes takes care of the details required to bring the resources to the desired state. In other words, declarative management involves telling Kubernetes what you want to happen.
Here's an example of a declarative YAML file that creates a deployment with two replicas and a specific image:
yaml

```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-container
          image: nginx:1.16
```

The above YAML file specifies the desired state of a deployment named my-deployment with two replicas and the nginx:1.16 image.

One of the benefits of declarative management is that Kubernetes can continuously monitor the state of the resources and ensure that they stay in the desired state, even if some other process or user makes a change to the resources.

The imperative approach tells Kubernetes how to make a change happen, while the declarative approach tells Kubernetes what the desired state should be, and Kubernetes figures out how to make it happen. Declarative management is the recommended approach for managing Kubernetes resources because it provides a clearer and more maintainable way of describing the desired state of the system.

Lets take another example, suppose we want to create a deployment with three replicas using the kubectl create command. We would issue the following command:

```
kubectl create deployment my-deployment --image=nginx --replicas=3
```

This command creates a new deployment with three replicas and the nginx image. If we later want to update the number of replicas to five, we would issue the following command:

```
kubectl scale deployment my-deployment --replicas=5
```

This command explicitly sets the number of replicas to five, without relying on any desired state configuration.

In summary, declarative management is a more automated and hands-off way to manage resources in Kubernetes, while imperative management provides more direct control over the operations performed on resources. Both approaches have their advantages and disadvantages, and the choice between them will depend on the specific use case and management requirements.