Kubernetes YAML Generator

Scaffold Deployment, Service, ConfigMap and Ingress manifests from a form.

Workload
Manifests
Send output to

A correct starting point, not a substitute for thinking

Most Kubernetes manifests begin as a copy of another manifest, which is how a mistake made once ends up deployed across a fleet. The output here is shaped the way a reviewed production manifest is shaped, so the copy you start from has the boring things already right.

What is included by default, and why

  • Resource requests and limits. A container with no requests is scheduled as BestEffort — the first thing evicted when a node comes under memory pressure. This is the single most common cause of pods that restart mysteriously on a busy cluster, and the fix is two lines that nobody remembers to write.
  • Liveness and readiness probes, kept separate. They do different jobs and conflating them causes outages. Readiness controls whether traffic is routed to the pod; liveness controls whether the kubelet kills it. Pointing liveness at a check that depends on a database means a database blip restarts every pod you have, turning a degradation into an outage.
  • A non-root security context. runAsNonRoot, a read-only root filesystem and dropped capabilities. These are cheap to set at the start and awkward to retrofit once an image has come to depend on writing to /.
  • Matching labels. The Service selector and the Deployment pod template labels have to agree, and when they silently do not, you get a Service with no endpoints and no error anywhere. They are generated together here so they cannot disagree.
  • Recommended label conventions. app.kubernetes.io/name and friends, so tooling that expects the standard labels can find your workload.

The optional pieces

A HorizontalPodAutoscaler is only useful once requests are set, since it scales on utilisation relative to the request — another reason those are not optional. A PodDisruptionBudget is what keeps a node drain from taking your service down during a cluster upgrade; it is the piece people discover they needed during their first maintenance window.

Everything is emitted as one file

Selected resources are separated by --- into a single multi-document YAML, ready for kubectl apply -f. Generation happens in your browser — the image names, hostnames and namespaces you type here describe your internal infrastructure, and none of them are transmitted.

Questions people actually ask

Are the generated manifests production-ready?
They are production-shaped: matching selectors and labels, resource requests and limits, liveness and readiness probes, and a non-root security context. Treat them as a correct starting point, not a substitute for reviewing your own cluster's policies.
Why does it always set resource requests?
Because a pod with no requests is scheduled as best-effort and is first to be evicted under memory pressure. Leaving them out is the single most common cause of mysterious restarts in a busy cluster.
Can I generate several resources at once?
Yes. Selected resources are emitted into one multi-document YAML file separated by `---`, ready for a single `kubectl apply -f`.
navigate open esc close