📝 YAML Manifests — Hands-On

YAML Manifests — Hands-On: In Kubernetes, everything is described as YAML files called 'manifests' — think of YAML as a letter you write to the cluster: 'Dear K8s, please run 3 c

In Kubernetes, everything is described as YAML files called 'manifests' — think of YAML as a letter you write to the cluster: 'Dear K8s, please run 3 copies of my app, connect them to port 8080, and make sure they stay healthy.' YAML indentation with 2 spaces is strictly required; wrong indentation breaks the letter. So why declarative YAML instead of an imperative script that runs `kubectl create` commands in sequence? Because a script describes STEPS, and steps go stale — re-running it twice might try to create the same Deployment twice and fail. A YAML manifest describes the DESIRED STATE, so applying it 100 times produces the same result as applying it once (`kubectl apply` is idempotent) — the same principle behind a Java REST API designing PUT as idempotent while POST is not. The QA risk: a manifest with broken indentation often doesn't fail loudly — it can silently parse into a DIFFERENT structure than intended (a field nested one level too deep gets ignored), which is why `kubectl apply --dry-run=client` before every real apply is a non-negotiable habit, not a nice-to-have.

YAML Structure — Every K8s Object Has 4 Root Fields

The 4 mandatory fields in every K8s YAML

Micro Lab: Kubernetes YAML manifest repair

Replace the TODO line with the critical line from the expected solution. This is not a real runtime; the goal is to reinforce writing the correct structure in a controlled way.

Why Does kubectl apply Reject the File Instantly If One of the 4 Fields Is Missing?

apiVersion picks the schema version

The API Server uses this field to decide WHICH API version to validate the object against.

kind determines which controller

Whether you write "Deployment" or "Service" determines WHICH controller the request gets routed to.

metadata.name is the real identity

This name must be unique WITHIN the namespace — it is the object's one true identity in the cluster.

spec is the ONLY object-specific part

The first 3 fields follow the same template for every object; spec content is COMPLETELY different between a Pod and a Service.