DevOps aims to reunite development and operations teams and automate the process of bringing new software versions into the production environment. To achieve that, automation frameworks support a way to describe what and how a software component should be deployed. This could be achieved either in an imperative or declarative manner. In DevOps, these ways are called paradigms.
With imperative practise (e.g. kubectl create deployment nginx --image=nginx
, kubectl expose deployment nginx --port=80 --target-port=8000
, ... ), the order of the commands is relevant. In case a previous step has not been executed, the command fails.
The declarative way does not rely on previous configuration steps and is lesser error-prone. A file contains the desired state and e.g. Kubernetes ensures that the actual state is adjusted to the desired state. This is also why it is best practice to store the manifests files for Kubernetes resources to deploy or redeploy them. This way it is guaranteed whenever and wherever the same manifest files are applied that the same resources are created and the application is running as the last time.
The big question is: where to store these Kubernetes manifest files?
Typically these Kubernetes manifest files could change based on the functionality of the application which will be deployed. For example, if the application is extended with probes endpoints, the corresponding Kubernetes manifest file should be adjusted to use them. Since the manifest files are bound tight to the software it does make sense to store them in the same version control system. Nowadays, this is usually Git.