Using IaC(Infrastructure as a Code) tool like Ansible, one can provision/deploy infrastructure. This involves servers, and various resources on Cloud like computing, storage, and networking rules in SDN in public clouds like AWS, Azure, GCP.

Ansible can also be used as a configuration management tool wherein a set of configuration settings can be pushed to multiple devices/servers in one go.

The above actions are repetitive in nature and hence by nature Ansible is a "declarative" tool. What does "declarative" mean in the context of Ansible?

Declarative - means the infrastructure being deployed or configuration being maintained by Ansible will be "precisely" the same (to the T) as one defines in the config files of Ansible(or Puppet). When one says Ansible is declarative in nature - this is exactly what it means.

Now this differs when one talks about the declarative approach in Kubernetes. In K8s, there are two ways one can manage objects - imperative and declarative. The declarative configuration defines resources within manifest files and then applies those definitions to the cluster. In the Imperative approach, usually, to describe the configuration of the resource, you execute a command from a terminal’s command prompt(with or without referring to config files). This is not a deep dive into technical differences/ nuances in both these approaches. What I wanted to highlight here is, the meaning of "declarative" is interpreted by Kubernetes in a different way than the way it is meant in Ansible/Puppet world.

In Kubernetes, while the "declarative" approach would create cluster objects as defined in the config files(manifest), there are some aspects, and attributes of a cluster that the config files may not choose to define. For example, while deploying a cluster it is outside of the scope of the config files on how the cluster would scale. The scaling (number of Pods in a cluster) of applications might depend on multiple factors in the production runtime. Config files(manifests) would typically define the image, names, labels, etc for a Pod, however, the scaling of the application is usually not scoped here - which is logical. So, effectively, one can not say with 100% confidence looking at a config file in K8s - that the running infra will be exact replica of it, with no other additional properties.

The simile I could think of here as far as declarative approaches of both - Config mgmt tools like Puppet/Ansible to an Orchestrator like Kubernetes is of the performing art world.

Cinema or a movie for example would play out in the same way on repeat runs. This is like Ansible. No change in each repetition - precisely the same thing each time. You expect the resultant infrastructure to be the same as the code is written.

A theatre play on the other hand would have a template - a tightly knit theme, protocol, sequences and even the lines or each actor on stage, however in each play there could be slight differences - in the way a character/actor would improvise a line, a different way actors would connect and adjust the act as per audience and occasion, fine-tune the acting method- underplay or make it loud. This is a Kubernetes way - follow the template without any deviation, but runtime would have some additional attributes.

Hope this analogy makes sense to me as I graduate further in k8s journey. :D

PS: There is much more to the declarative approach than the oversimplification I did above. Took a while for me to understand - the below links helped, and there is much more to it - will be in some other blog post as I keep learning.
1)kubernetes.io/docs/tasks/manage-kubernetes-..
2)youtube.com/watch?v=CW3ZuQy_YZw