Anatomy of a Pod Manifest

Every Kubernetes 5,150 manifest has the same four top-level fields: apiVersion and kind 14,561 name the type (kubectl explain), metadata gives the object its name, namespace and labels, and spec is the desired state. The API server adds a fifth, status, which only controllers write. Here is the manifest this section builds up to, BookNest's API as a single Pod:

k8s/api-pod.yaml: BookNest's API as one PodYAML

apiVersion: v1
kind: Pod
metadata:
  name: api
  labels: { app: booknest, tier: api }
spec:
  initContainers:
  - name: wait-for-db
    image: localhost:33500/booknest-api:1.3
    command: [bash, -c, 'until (echo > /dev/tcp/db/5432) 2>/dev/null; do
      echo waiting for db; sleep 2; done']
  containers:
  - name: api
    image: localhost:33500/booknest-api:1.3
    ports: [{ name: http, containerPort: 3000 }]
    env:                             # plain values for now; Section 6.12 moves them to a Secret
    - { name: PGHOST, value: db }
    - { name: PGUSER, value: booknest }
    - { name: PGPASSWORD, value: booknest }
    readinessProbe: { httpGet: { path: /ready, port: http }, periodSeconds: 5 }
    livenessProbe: { httpGet: { path: /health, port: http }, periodSeconds: 10 }
    resources:
      requests: { cpu: 50m, memory: 64Mi }
      limits: { memory: 256Mi }
    securityContext: { runAsNonRoot: true, allowPrivilegeEscalation: false }

Only spec.containers is required, and each container needs just a name and an image; the API server defaults the rest, such as restartPolicy: Always and a 30-second terminationGracePeriodSeconds. The labels matter more than they look: Services and Deployments find their Pods by label, never by name.

MENU

Anatomy of a Pod Manifest