Kubernetes YAML Generator
Fill in a short form and get a complete Kubernetes manifest: workload, Service, Ingress, storage, autoscaling. Resource limits, probes and a hardened security context are filled in by default, and the result is run through our own validator before you see it.
manifest.yaml
updates as you typeCommon mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Generating a manifest and applying it unchanged
A generator produces a starting point. Resource requests, probes and security context all depend on the workload and no generator can know them.
Instead:Treat the output as a draft, and fill in the parts specific to your application.
Omitting the namespace
The manifest applies to whichever namespace is current, which is how something lands in the wrong one.
Instead:Set metadata.namespace, or always apply with -n.
Keeping the generated latest tag
The image is not pinned, so a rollout can pull something different and a rollback cannot reproduce the old one.
Instead:Pin a tag, and a digest where the registry allows it.
What it fills in for you
Most manifest generators emit the smallest thing that runs. That is a snippet, and every field it leaves out is one somebody has to remember later. These are the defaults our validator would otherwise flag.
Resource requests, always
A pod with no requests is invisible to the scheduler, which then overcommits the node. It is the single most common reason a cluster costs more than it should while sitting at low utilisation.
A readiness probe
Without one, Kubernetes sends traffic the moment the process starts. During a rolling update that means a burst of errors on every deploy, from pods that are still warming up.
Non-root, read-only, no capabilities
runAsNonRoot, readOnlyRootFilesystem, capabilities dropped to ALL, and a RuntimeDefault seccomp profile. An emptyDir is mounted at /tmp automatically, because otherwise the manifest is correct and the container still crashes on its first temp file.
Its own ServiceAccount, with no token
Sharing the namespace default means every RoleBinding written for anything else applies to this workload too. automountServiceAccountToken is false, so a code execution bug does not get a free cluster credential.
A real image tag
The default is a pinned version, not :latest. Which build actually runs should not depend on when each node last pulled.
No replicas when an HPA owns them
Set both and they fight on every apply, with the Deployment resetting the count the autoscaler just changed. Turn on autoscaling and the replica field disappears from the output.
The generator and the validator are the same rules
The output of this page is fed straight into the Kubernetes YAML Validator on every keystroke, and the strip under the manifest reports what it found. That is not decoration: it is the difference between claiming a generator produces good manifests and demonstrating it.
It also means the two tools cannot drift apart. If a rule is added to the validator that this generator's defaults would trip, the finding appears here immediately, on our own page, in front of whoever is using it.
Which Kubernetes objects does a service actually need?
A running workload is rarely one object. The Deployment keeps pods alive, a Service gives them a stable address, an Ingress puts them on a hostname, and a handful of others handle scaling, disruption and storage. Knowing which of them you need, and which defaults are quietly wrong: is most of what this generator encodes.
The objects and what each one is for
A Deployment manages stateless replicas and replaces them on update. A StatefulSet does the same for workloads that need stable identities and their own storage. A Service is a stable virtual IP and DNS name in front of whichever pods currently match its selector. An Ingress maps a hostname and path to a Service. An HPA scales replicas on load, and a PodDisruptionBudget stops a node drain from taking all of them at once.
Deployment -> ReplicaSet -> Pods
^
Service ------ selector ---------+ stable IP and DNS
Ingress ------ routes to -----> ServiceRequests and limits are two different things
A request is what the scheduler reserves when placing the pod, so it decides where the pod lands and it is what you are effectively paying for. A limit is the hard ceiling enforced at runtime. Omit requests and the scheduler assumes the pod needs nothing and packs it onto a full node. Set a CPU limit too low and the container is throttled rather than killed, which looks like an application that is mysteriously slow rather than one that is constrained.
resources:
requests: reserved at scheduling time
cpu: 100m
memory: 128Mi
limits: enforced at runtime
cpu: 500m exceeding this throttles
memory: 256Mi exceeding this kills the container (OOMKilled)Two defaults that break things quietly
A read-only root filesystem is the right hardening default and it kills any container that writes a temp file, so it needs an emptyDir mounted at /tmp alongside it. And setting spec.replicas while an HPA also manages the same Deployment makes the two fight on every apply, each undoing the other. The generator handles both: it mounts the emptyDir automatically, and omits replicas whenever an HPA is generated.
Why no Secret is generated
Ask for a secret-backed environment variable and this emits a secretKeyRef pointing at a Secret, and no Secret object. Generating one would mean writing the value into a manifest, which is the exact thing the validator on this site flags: a Secret in a manifest is a credential in your Git history. Create it with kubectl, or with a sealed or external secret, and reference it from here.
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: db-credentials <-- created separately, never in this file
key: password