Kubernetes Pod Manifest

Why Learn Pod YAML?

Even if you mostly use Deployments later, pod manifests teach the core structure shared by many Kubernetes resources.

Full Pod YAML Anatomy

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
  labels:
    app: demo
    tier: frontend
  annotations:
    owner: platform-team
spec:
  containers:
    - name: web
      image: nginx:1.27
      ports:
        - containerPort: 80
      resources:
        requests:
          cpu: "100m"
          memory: "128Mi"
        limits:
          cpu: "500m"
          memory: "256Mi"

Understanding Each Top-Level Field

apiVersion

Tells Kubernetes which API version this resource uses.

kind

Defines the resource type, such as Pod, Service, or Deployment.

metadata

Stores identifying information like name, labels, and annotations.

spec

Describes the desired state of the resource.

Labels vs Annotations

Labels are queryable and often used by Services and Deployments. Annotations are not usually used for selectors.

The containers Array

A pod can run one or more containers, so containers is a list.

Common container fields include:

• name
• image
• ports
• env
• resources
• volumeMounts

Apply the Pod Manifest

kubectl apply -f pod.yaml

View the Live Pod YAML

kubectl get pod demo-pod -o yaml

That command is helpful because it shows defaults and status fields added by Kubernetes.

Why This Structure Repeats Everywhere

Many Kubernetes objects follow the same shape: metadata plus spec. Once you understand pod YAML, other resource types feel much more approachable.

Think of Kubernetes manifests like legal forms with a familiar layout. The exact fields vary, but the structure stays recognizable.