Declarative in Kubernetes
The platform’s architectural foundation is declarative in Kubernetes, which embodies a basic idea in which users specify the “desired state” of a system what the end product should look like instead of giving a series of precise imperative orders to accomplish it. High levels of automation, self-healing, and scalability are made possible by Kubernetes’ capacity to manage the intricate “how” of infrastructure management.
Declarative vs. Imperative Approaches
The distinction between these models is often explained through a chocolate cake analogy. An imperative approach is like a detailed recipe that lists every step: “drive to the store, buy eggs, preheat the oven, mix ingredients, and bake”. If any single step fails, such as the store being out of eggs, the entire process halts unless complex error-handling is manually scripted.
In contrast, the declarative approach is simply stating: “Give me a chocolate cake that feeds ten people”. In Kubernetes terms, instead of telling the system to “run A, then B, then C,” a developer provides a declarative manifest (usually in YAML or JSON) stating a requirement, such as replicas: 10. If a node fails and the number of running replicas drops, the system automatically notices the discrepancy and starts new ones to reach the desired state again without human intervention.
you can also read What is the Pod in Kubernetes? and Pod Lifecycle
The Three Pillars of the Declarative Model
Three states interact continuously to drive the model:
- Desired State: The “record of intent” that the user defines in configuration files is known as the desired state. It includes information about resource constraints, port mappings, and container images.
- Observed (Actual) State: The current state, or observed (actual) state, is the latest picture of the cluster’s operations.
- Reconciliation: Reconciliation maintains alignment between desired and observed states. Controllers that operate in a continuous reconciliation loop oversee it.
A YAML manifest sent by a user to the API Server is verified and saved in the cluster’s database, etcd, as the new desired state. Controllers that continuously monitor this state include the Deployment and ReplicaSet controllers. They operate quickly to generate the required resources if they notice that the actual state (such as zero pods) does not correspond with the intended intent.
Key Declarative Resources
Several high-level Kubernetes objects use this approach to handle various application requirements, including:
- DaemonSets: These are perfect for logs or monitoring agents since they guarantee that a particular Pod operates on each cluster node.
- Deployments: The most popular method for managing stateless apps is deployment. ReplicaSets and automated rolling updates and rollbacks are managed by them.
- ReplicaSets: They run a set number of identical Pod replicas.
- StatefulSets: Databases use StatefulSets for persistent storage and network IDs.
You can also read How to Install Kubeadm in Kubernetes Step by Step Guide
Technical Implementation: kubectl apply
The primary tool for managing objects declaratively is the kubectl apply command. Unlike imperative commands like kubectl create or kubectl run, which are one-time instructions, kubectl apply manages the lifecycle of an object over time. It creates objects if they do not exist and updates them if they do.
A critical component of this process is the kubectl.kubernetes.io/last-applied-configuration annotation. When kubectl apply is run, it calculates a patch request by comparing three things: the local configuration file, the live configuration in the cluster, and the last-applied-configuration stored in the object’s metadata. This mechanism allows Kubernetes to:
- Configure fields found in the configuration file.
- If certain attributes are left out of the configuration file, keep writes made to live objects (such as an autoscaler).
- Any fields that have been deleted from the configuration file since the last apply action should be cleared.
Field Merging Strategies
Depending on their kind, fields are updated differently. Booleans, integers, and strings are examples of primitive fields that are only substituted. Subfields within map fields (or objects) are combined. Lists are more complicated; they can be merged based on a “patchMergeKey” (such as the name of a container) to update individual elements without rearranging the entire set, or they can be completely altered (keeping order).
You can also read How to install Kubectl in Kubernetes Explained Briefly
Operational Benefits and Infrastructure as Code
The declarative model offers important benefits for business operations:
- Self-Healing: The reconciliation loop automatically restores Kubernetes following component failure or “state drift”.
- Consistency and Repeatability: Development, staging, and production deployments are consistent with configuration files.
- Idempotency: Same configuration, resilient system.
- Infrastructure as Code (IaC): Git and other version control systems store state in text files. Code reviews, audit trails, and GitOps procedures—in which the Git repository serves as the cluster’s sole of truth are made possible by this.
- Simplified Rollbacks: Reapplying the previous declarative state (the previous YAML file) to the cluster is all that is required to roll back an unstable application.
Conclusion
By changing the emphasis from “how to do it” to “what I want,” the declarative paradigm simplifies the enormous complexity of overseeing thousands of containers in many contexts. It ensures the cluster is a consistent, repeatable representation of configuration file intent rather than a manually configured “snowflake.” In Kubernetes, controllers, etcd, and the reconciliation loop make static declarations self-healing, autonomous, and dynamic.
You can also read Kubernetes Controller Manager vs Cloud Controller Manager