Kubernetes Resource Model (KRM)
When discussing about Kubernetes it is often referred as container orchestration platform or some sort of variant of that. While this statement is true it is omitting a lot and missing the bigger picture of what Kubernetes actually is. It is true that you can run your containers with Kubernetes but you are missing out a lot if that’s all you used it for. It is much better to consider Kubernetes as an API which you can extend and way of reconciling the state of the world (your resources) to conform what you desire it to be.
This reconciliation is also the key part of whole KRM model and Kubernetes overall. You declare your desired state of the world/resources and it is up to Kubernetes to reconcile the state of the world to match what you’ve declared in your manifests. Reconciliation is the superpower of Kubernetes. It is not limited to containers but you can create any kind of resources with it. It is extensible. It is programmable. Changes to resources originate from you but also from within the Kubernetes. You might need to drain computing node of all workloads for maintenance causing all the pods on that node requiring rescheduling. Kubernetes controllers spring into action and reconciliate the changes.
Compared to traditional systems there are no imperative instructions. Everything is declarative and the it is up to Kubernetes controllers to do the work. The declarative model makes it possible to drive the desired state via version control, CI/CD pipelines. This is GitOps, automatic installation of version controlled manifests into the cluster. No more manual work.
Why GitOps?
Most phases of the application lifecycle are automated. Building, testing, deployment being prime examples. Infrastructure has long been the part that has had most manual steps. DevOps practices have been developed to alleviate this but infrastructure configuration has largely remained manual, imperative process. With KRM declarative model it possible to create truly elastic infrastructure which adapts quickly without manual intervention. Traditional DevOps is more about communication and getting development teams to communicate with operations. GitOps can be considered part of the DevOps, focusing using Git version control to manage infrastructure.
GitOps works exceptionally well with KRM model. We store only our desired state and it is reflected in Git. Changes to infrastructure are reflected in Git history just like the changes to application logic. It is possible to utilize the best practices learned in software development and bring those to infrastructure. Faster iterations and less chances for human errors.
Tooling
There are many tools for enabling GitOps way of working. Some abandoned, some actively developed. For greenfield project I would recommend ArgoCD or Flux.