Module #42 · beginner Article
Anatomy of a Kubernetes Manifest: The Four Essential Structure Fields
A manifest is a YAML file describing a desired Kubernetes object. Every manifest requires: `apiVersion`, `kind`, `metadata`, and `spec`.
3 min read+10 XPPublished 2026-06-21
Quick Answer: A manifest is a YAML file describing a desired Kubernetes object. Every manifest requires: apiVersion, kind, metadata, and spec.
Detailed Answer:
# These four fields are REQUIRED in every Kubernetes manifest
apiVersion: apps/v1 # Which API group/version defines this kind
# v1 = core (Pod, Service, ConfigMap, Secret)
# apps/v1 = Deployment, StatefulSet, DaemonSet
# networking.k8s.io/v1 = Ingress, NetworkPolicy
kind: Deployment # The object type — must match what apiVersion supports
metadata: # Object identity
name: my-app # Required — unique within namespace
namespace: production # Optional — defaults to 'default'
labels: # Optional but critical — used for selectors
app: my-app
version: v1
annotations: # Optional — metadata for tools, not selectors
description: "Main application deployment"
spec: # Desired state — structure varies by kind
replicas: 3
# ... rest of spec
# The API server also adds 'status' — you never write this, K8s manages it
status: # Current actual state (managed by K8s)
availableReplicas: 3
readyReplicas: 3
Finding the Right apiVersion:
kubectl api-resources | grep deployment # Shows: apps true Deployment
kubectl api-versions | grep apps # Shows: apps/v1
kubectl explain deployment # Shows apiVersion, kind, fields
Key Takeaway: The spec declares desired state; status reflects actual state — the gap between them is what Kubernetes controllers work to close.
Finished reading?
Mark as complete to claim your +10 XP and track progress.
