What is the difference between resource requests and limits?

Requests are what the scheduler reserves for the pod and uses to decide placement, while limits are the hard ceiling the container cannot exceed. Memory over the limit triggers an OOM kill, and CPU over the limit is throttled rather than killed.

Why have both liveness and readiness probes?

The readiness probe controls whether a pod receives traffic, so a failing one is pulled from the Service endpoints. The liveness probe restarts a pod that is alive but stuck. Using both prevents sending requests to a not-yet-ready container and recovers hung ones.

How do the selector and template labels connect?

The Deployment selector.matchLabels must exactly match the labels under template.metadata.labels, because that is how the Deployment finds and manages its pods. The generator keeps both in sync using an app label.

What does the Service add?

The optional ClusterIP Service gives the pods a stable internal DNS name and load-balances across replicas. Its selector matches the same app label, and its targetPort points at the container port.

Are the CPU units like 250m correct?

Yes. CPU is measured in millicores where 1000m equals one core, so 250m is a quarter of a core. Memory uses binary suffixes like Mi and Gi. The builder validates and passes these through verbatim.

Kubernetes Deployment YAML Builder

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Writing a Kubernetes Deployment by hand means remembering the nesting of selectors, pod templates, probes, and resource blocks. This builder generates a correct, apply-ready manifest — plus an optional Service — from a few inputs.

How it works

A Deployment wraps a pod template. The top-level selector.matchLabels must match template.metadata.labels, which is how the Deployment tracks its pods. The container spec carries the image, ports, env vars, resource bounds, and health probes:

resources:
  requests: { cpu: 250m, memory: 256Mi }
  limits:   { cpu: 500m, memory: 512Mi }
livenessProbe:
  httpGet: { path: /healthz, port: 8080 }
  initialDelaySeconds: 10
readinessProbe:
  httpGet: { path: /ready, port: 8080 }

CPU uses millicores (1000m = 1 core) and memory uses binary suffixes (Mi, Gi). The readiness probe gates traffic; the liveness probe restarts a hung container. The optional Service selects the same app label and exposes the container port inside the cluster.

Tips and notes

Always set both requests and limits — without requests the scheduler can pack pods badly, and without a memory limit a leak can starve the node. Keep initialDelaySeconds long enough for slow-starting apps so the liveness probe does not kill them during boot. Apply with kubectl apply -f deployment.yaml, and use kubectl rollout status to watch the update.