Kubernetes Fundamentals: Objects, YAML, Labels, Namespaces, and Workloads
Kubernetes is easiest to understand as an API of desired-state objects. You declare what should exist, and controllers continuously work to make actual state match it.
Kubernetes Objects
Most resources have:
spec— what you want.status— what Kubernetes currently observes.
A Deployment spec might request three replicas; status reports how many are actually ready.
Declarative YAML
A basic object includes:
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 3
Prefer version-controlled declarative manifests or an equivalent configuration-as-code workflow over undocumented manual cluster changes.
Labels and Selectors
Labels organize resources and connect controllers/services to the objects they manage.
metadata:
labels:
app: orders
environment: production
Selectors must be designed carefully. Overlapping controller selectors can cause conflicting ownership.
Use annotations for non-identifying metadata that does not need selection.
Namespaces
Namespaces scope names and help organize teams/projects and apply policies or quotas.
They are not automatically a security boundary. RBAC, NetworkPolicy, quotas, and other controls still matter.
For production, avoid dumping everything into the default namespace.
Core Resource Map
Pod → running container group
Deployment → manages stateless Pods
Service → stable network identity
ConfigMap → non-secret configuration
Secret → sensitive configuration object
PVC/PV → persistent storage
Job → run-to-completion work
Namespace → resource scope
Learn these before jumping into the wider Kubernetes ecosystem.
kubectl Is an API Client
Commands such as:
kubectl get pods
kubectl describe deployment api
kubectl apply -f deployment.yaml
are simply ways to interact with the Kubernetes API. The API—not kubectl—is the real platform boundary.
Production Habits From Day One
- Use consistent recommended labels such as
app.kubernetes.io/*where useful. - Keep manifests/configuration version-controlled.
- Set resource requests for workloads.
- Use readiness probes for traffic eligibility.
- Separate sensitive Secrets from normal configuration.
- Use namespaces/policies intentionally rather than creating dozens without purpose.
Final Takeaway
The Kubernetes foundation is small: objects, desired state, controllers, labels/selectors, namespaces, and a handful of workload/network/storage resources. Understand that object model first; most advanced Kubernetes features are extensions of the same reconciliation idea.

Discussion (0)