Objects, labels, and namespaces

Everything in Kubernetes is an API object with metadata, spec, and often status. Consistency in naming and labeling is what makes automation safe.

Core identity

• name + namespace uniquely identify most namespaced objects
• uid is immutable for the object’s life
• labels are for selection (Services, Deployments, NetworkPolicies)
• annotations are for non-identifying metadata (build SHAs, tooling hints)

Do not overload labels as a free-form database. Keep a small, documented vocabulary (app, tier, version, team ownership).

Selectors couple objects

A Service selects Pods by labels. A Deployment’s template labels must match its selector — changing selectors later is painful by design. Treat label contracts as APIs between controllers.

Namespaces for tenancy boundaries

Namespaces group resources and scope RBAC, NetworkPolicies, and quotas. They are not strong security walls by themselves, but they are the unit of team ownership in most platforms.

Patterns that work: one namespace per team/env or per service/env — pick a convention and stick to it. Dumping all prod workloads into default is how accidents propagate.

Finalizers and deletion

Finalizers block deletion until a controller cleans up (volumes, external LBs). A stuck terminating Namespace usually means a finalizer owner is dead or misconfigured — not “kubectl is broken.”

Resource discovery

kubectl api-resources and CRDs extend the same model. If you cannot name the object kind and API group, you are guessing — and GitOps will encode the guess forever.