Declarative Resource Management: CNPA practice questions

Declarative resource management means describing the state you want rather than the steps to get there, and letting software work out and apply the difference. Kubernetes is built around it. Objects carry a spec that records the desired state and a status that reports the current one, and controllers keep working to bring the two together. For a platform team this is what makes self-service, review and automation possible: a desired state written in a file can be stored in Git, reviewed in a pull request, reproduced in another environment and reapplied after a failure.

The Kubernetes documentation separates three management techniques. Imperative commands such as kubectl create deployment act directly on live objects; they are quick for experiments but leave no record, no review step and no template. Imperative object configuration (kubectl create -f, replace -f, delete -f) names the operation and a file; replace overwrites the whole spec and drops anything missing from the file, which breaks fields that the cluster updates on its own. Declarative object configuration (kubectl apply -f on files or directories) lets kubectl detect per object whether to create, patch or delete. It writes only the observed differences with a patch, so changes made by other writers survive. The documentation warns that an object should be managed with only one technique, because mixing them for the same object results in undefined behavior.

The workflow it recommends is to preview with kubectl diff and then run kubectl apply, recursively with -R where needed. Client-side apply stores what was last applied in the kubectl.kubernetes.io/last-applied-configuration annotation and uses it to work out what to remove. Server-side apply moves that logic into the API server: it tracks which field manager owns each field in managedFields, and an apply that tries to change a field owned by another manager is reported as a conflict instead of silently overwriting it. Kustomize, built into kubectl since 1.14 and used with kubectl apply -k, and Helm charts are common ways to generate declarative manifests for several environments.

GitOps builds directly on this. The first OpenGitOps principle is that a system managed by GitOps must have its desired state expressed declaratively; the others require that state to be versioned and immutable, pulled automatically by software agents and continuously reconciled.

Common mistakes are treating a YAML file as declarative while still deploying it with create or replace, assuming declarative means nothing can drift (it can, until something reconciles it), and expecting kubectl apply to delete objects whose files were removed. The documentation recommends kubectl delete -f as the explicit way to delete, and warns that the alternative, apply with --prune, needs care because the selected objects can be unexpectedly deleted or retained.

At associate level, expect to choose between imperative and declarative approaches for a scenario, to recognize the benefits of declarative configuration for audit, review and repeatability, and to connect desired state in files with the reconciliation that keeps a cluster on it.