In Kubernetes there is the "Desired State", which is the sum of all resources (your yaml files) and the "Actual State". Whenever a change is requested on the "

In Kubernetes there is the "Desired State", which is the sum of all resources (your yaml files) and the "Actual State". Whenever a change is requested on the "Desired State", Kubernetes will validate it (using RBAC, Admission Webhooks, ...) before persisting it (in etcd in most cases). Then after the persistance is done, it will notify the operators (watching the resources) that are in charge of performing the side effects (run that docker image, allocate that storage volume, ...), moving the "Actual State" closer to your "Desired State". Creating a new Custom Resource Definition and an operator helps you hide the complexity. For example: - the (builtin) Deployment operator creates a ReplicaSet - the (builtin) ReplicaSet operator creates Pods - the (builtin) Pod operator runs Docker images and updates the Pods status Nothing prevents you from making an operator that creates Deployment/Services/Ingress for you. This is even simplified with Helm (to template your resources) and the HelmOperator[1]. [1] - https://github.com/fluxcd/helm-operator https://github.com/fluxcd/helm-operator