Validate a Kubernetes Pod Manifest

Kubernetes manifests are among the most complex YAML documents developers work with. A single indentation error can cause kubectl apply to reject the file outright, or worse, apply it silently with the misconfigured field defaulting to a zero value that causes unexpected behavior. Pod specs in particular are deeply nested, with containers inside a spec inside a template inside a deployment, making it easy to accidentally place a field at the wrong indentation level. This example shows a basic Pod spec with the essential production configuration: the container image version pinned to a specific tag (not latest, which is a common anti-pattern that makes deployments non-reproducible), a declared containerPort, resource requests and limits, and a liveness probe. Resource requests vs limits explained in depth: requests.cpu of "100m" means 100 millicores — one-tenth of a CPU core. The Kubernetes scheduler uses requests to find a node with enough available capacity to place the pod. limits.cpu of "500m" means the container can burst up to half a CPU core but will be throttled (rate-limited) if it tries to use more. For memory, exceeding the limit is more severe: the container is OOMKilled (killed by the Out-of-Memory killer) and restarted. Setting limits too low causes frequent restarts; setting them too high wastes cluster capacity and may prevent the scheduler from placing pods efficiently. The liveness probe checks /healthz every period with an initial delay before the first check. If the probe fails (returns non-200 status or times out), Kubernetes restarts the container. This is your application's way of saying "I'm broken, please restart me." A readiness probe (not shown in this example but equally important) controls whether the pod receives traffic — a pod can be live but not ready while it's warming up caches or waiting for a dependency. Real-world scenarios: a new service that pods keep restarting because the liveness probe path is wrong or the initialDelaySeconds is too short for the app's startup time; a deployment that runs out of memory during peak traffic because memory limits were set without observing actual peak usage first. Tips: use a Deployment rather than a bare Pod in production. Deployments manage replica sets, enable rolling updates, and reschedule pods when nodes fail — a bare Pod is not rescheduled if its node goes down.

apiVersion: v1
kind: Pod
metadata:
  name: web-api
  labels:
    app: web-api
    version: v2
spec:
  containers:
    - name: api
      image: myapp:2.1.0
      ports:
        - containerPort: 8080
      resources:
        requests:
          cpu: "100m"
          memory: "128Mi"
        limits:
          cpu: "500m"
          memory: "512Mi"
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 10