# Why GitOps?
Two everyday tasks in managing and operating computer systems are infrastructure configuration and software deployment.

*Infrastructure configuration* prepares computing resources (such as servers, storage, and load balancers) that enable the software application to operate correctly.

*Software deployment* is the process of taking a particular version of a software application and making it ready to run on the computing infrastructure.



Traditional organizational model vs DevOps organizational model


## GitOps
The GitOps release workflow starts with creating a branch of the repository containing changes to the definition of the system’s desired state.


In a GitOps model, the system’s desired configuration is stored in a revision control system, such as Git. Instead of making changes directly to the system via a UI or CLI, an engineer makes changes to the configuration files that represent the desired state.

GitOps doesn’t require a particular set of tools, but the tools must offer this standard functionality:
+ Operate on the desired state of the system that is stored in Git
+ Detect differences between the desired state and the actual state
+ Perform the required operations on the infrastructure to synchronize the actual state with the desired state

## Kubernetes and GitOps
Every time the `kubectl apply` command updates a resource, it saves the input manifest in the `kubectl.kubernetes.io/last-applied-configuration` annotation. So when the command is executed the next time, it retrieves the most recently applied manifest from the annotation, representing the common ancestor of the new desired manifest and live resource manifest. This allows kubectl to execute a three-way diff/merge and properly handle the case where some fields are removed from the resource manifest.

To pass control of the `replicas` field over to the Horizontal Pod Autoscaler, the `replicas` field must first be deleted from the file that contains the Deployment manifest. This is so the next `kubectl apply` does not override the `replicas` value set by the Horizontal Pod Autoscaler.

### Controller architecture
Let’s talk about what is behind each Kubernetes resource: the controller architecture.

**Controller delegation**


Kubernetes allows for a resource hierarchy. Higher-level resources providing additional functionality, such as ReplicaSets and Deployments, can manage other higher-level resources or primary resources, such as Pods. This is implemented through a series of controllers, each managing events related to the resources it controls.

**Controller pattern**

Although all controllers have different responsibilities, the implementation of each controller follows the same simple pattern. Each controller runs an infinite loop, and every iteration reconciles the desired and the actual state of the cluster resources it is responsible for.


The desired state is represented by the `spec` field of the resource manifest. The question is, how does the controller know about the actual state? This information is available in the `status` field. The `status` field provides information about cluster state to end users and enables the work of higher-level controllers.