How to Use the K8s YAML Generator

2026-10-28 · Swift Toolbox · about 4 min read

Writing your first Kubernetes Deployment YAML by hand, you will almost certainly trip over indentation, field names or probes. The good news is that a Deployment has a fixed skeleton — apiVersion, kind, metadata, spec, selector, template and containers — and once those are right, it runs. With the K8s YAML Generator on this site, you fill in a form and get deployable YAML without hand-writing a single indent.

Open the K8s YAML Generator →

Step 1: Fill in the two required fields

Only two fields are required to generate a working YAML: the app name and the image. The app name defaults to my-app and the image to nginx:latest. Both values appear in metadata.name, the labels, the selector and the container name — keeping them consistent is what makes a Deployment work, because the selector's matchLabels must exactly match the labels on the Pod template, or the controller cannot find its own Pods.

The namespace defaults to default; change it if you have your own. Replicas default to 1 — for production, start with 2 or 3 so a rolling update always has capacity to spare.

Step 2: Don't pick the image pull policy at random

The pull policy defaults to IfNotPresent, which means a node reuses an image it already has instead of pulling again — the fastest deploy and the least traffic. Use Always when the image tag stays the same but its contents change often, as in a dev environment. But beware: if the registry needs authentication and you haven't configured imagePullSecrets, Always will leave your Pods stuck in the pulling phase. In production, where tags are fixed (for example my-app:v1.2.3), the default IfNotPresent is the right choice.

Step 3: Ports, environment variables and resource limits

The default container port is one row: name http, port 80, protocol TCP. Click "Add port" for more. Environment variables are one KEY=VALUE pair per line — a common one is TZ=Asia/Shanghai — and the generator writes them as an env list.

It is worth keeping resource limits checked. The defaults are CPU request 100m and limit 500m, memory request 128Mi and limit 256Mi. Watch the units: CPU m means millicores (100m = 0.1 core) and memory Mi means mebibytes. Writing 100M or forgetting the unit will get the file rejected by the API server. Requests decide scheduling — if the remaining resources on a node are not enough, the Pod never gets scheduled. Limits decide the ceiling — go over it and the container gets OOM-killed.

Step 4: Don't confuse the two health probes

The generator checks both probes by default, and both are HTTP GET. The liveness probe defaults to path /health, an initial delay of 30 seconds and a check every 10 seconds: after repeated failures, kubelet restarts the container — the right tool for a process that is still running but deadlocked. The readiness probe defaults to path /ready with a 5-second initial delay: while it fails, the Pod receives no traffic but is not restarted — the right tool for a service that starts slowly and is still warming up.

Pitfall: the probe path must actually exist in your app. Plain nginx has no /health endpoint, so if you deploy with the defaults as-is, the probes will keep failing and the Pod will keep restarting. If your app has no health endpoint yet, uncheck both probes first and turn them on once the endpoints exist.

Step 5: Deploy and verify

Click "Download .yaml" to save the file, then run the following on a machine with kubectl access:

kubectl apply -f my-app.yaml
kubectl get pods -w
kubectl get deployment my-app

Once the Pod status turns to Running and the READY column shows 1/1, it is up. Check the logs with kubectl logs -f deployment/my-app.

Common errors at a glance

ImagePullBackOff: the image cannot be pulled. Check the image name and tag for typos first, then check whether the registry needs authentication and whether a private registry has imagePullSecrets configured.
CrashLoopBackOff: the container exits right after starting. Check the logs — common causes are a wrong start command, a missing config file, a port already in use, or a misconfigured liveness probe that keeps restarting it.
Pending: the Pod cannot be scheduled. Usually the CPU or memory requested is more than the nodes have left, or the nodes carry a taint.
YAML error "invalid": a field in the wrong place or broken indentation. The generator's YAML structure is correct, so check the parts you edited by hand — indentation must be two spaces.

To sum up: the generator only produces a Deployment — no Service, no Ingress. Once the Pod is running, write a Service to expose its ports, and add an Ingress if you need a domain entry point. Get the Deployment running first, then add the rest one step at a time.

Everything is generated locally in your browser — the tool never connects to a cluster and never uploads anything, and the YAML it produces is ready to use.