Building Kubernetes deployment pipeline – Imperative vs Declarative approach

In DevOps paradigm, having robust and efficient CI/CD pipeline is very essential.

Over the years tool like Jenkins, Ansible etc. become popular choice.

They essentially follow imperative approach in which these tools provide/support easy to use scripting language to describe target deployment state of application. User can write Jenkins files or Ansible playbook to instruct Jenkins and Ansible steps to perform respectively.

For Kubernetes deployments also, kubectl command can be executed as Jenkins pipeline steps. In Ansible, it can be achieved using playbook.

The Other approach gaining popularity recently is declarative way of deploying workloads.

Tools like Argo CD and Flux CD work on GitOps principle where git is considered as single source of truth.

All infrastructure configurations manifests which defines target start of application deployment are stored in git repository.

Argo CD extends Kubernetes APIs, provide Custom Resource (CR) and Custom Resource Definition (CRD) extension.

The Argo CD agent is responsible for keeping the state of application in sync with respective git repository definitions on pull based model i.e. It pulls latest changes from git repository and reconcile with application state.

In this approach the tool knows what to do and how to achieve target state. Users need to define the target state and the deployment tool like Argo CD and Flux CD strive to achieve the target state defined in manifests which much similar to how software like Terraform and Kubernetes also work.

Argo CD agent is deployed inside same Kubernetes cluster as application. Hence can watch the application state at runtime. This gives Argo CD capability to monitor, rollback and observe deployed application states which is not the case in imperative tools like Jenkins and Ansible. Argo CD also comes nice UI to see every thing visually.

#argocd #kubernetes