Kubernetes manifest builder and explainer
Build Kubernetes manifests from forms — Deployments to NetworkPolicies — with live YAML, checks across the whole bundle, kubectl-explain docs for every field, a CPU and memory unit converter with the QoS class your requests and limits produce, probe timelines and a CronJob schedule explainer.
Added · updated 28 October 2026
Works with
- Compose, Kubernetes, and cron checker Formatting and referenceopens the generated manifests for linting
- Cron expression tool Timeopens a CronJob’s schedule to check its next runs
- JVM memory planner for containers Databases and streamingreceives a Java Deployment with the memory limit and JAVA_TOOL_OPTIONS sized there
How to use it
Pick objects, fill in the forms, and copy the YAML. The form edits the object itself, so anything you paste keeps the fields the form has no control for. Everything runs in this page; nothing is sent anywhere.
How to use it
Build holds a bundle — the objects you are writing together, shown as chips along the top.
+ Add… adds a kind (Deployment, StatefulSet, DaemonSet, Job, CronJob, Service of any type,
Ingress, ConfigMap, Secret, PersistentVolumeClaim, HorizontalPodAutoscaler v2, NetworkPolicy,
ServiceAccount); a new Service takes its selector and ports from the workload in the bundle, a
new autoscaler targets it. Examples… loads ready-made bundles. Paste YAML… loads
manifests (several, separated by ---, or a kind: List from kubectl get -o yaml) into
the form, dropping status and server-set metadata.
For workloads the form covers the containers (pick one, or add a sidecar or init container):
image, command and args, ports, environment — a value can be secret:NAME/KEY,
configmap:NAME/KEY, field:metadata.name or resource:limits.memory — requests and
limits with the resulting QoS class, the three probes, volumes and mounts, the security
context, and pod settings such as the service account, node selector and tolerations. While
Keep the pod labels and the selector in step is ticked, editing the labels also updates the
pod template’s labels and spec.selector.
The YAML on the right updates as you type, for this object or the whole bundle. Click any
line — or a ? beside a field — to read that field’s documentation, as kubectl explain
prints it. Checks lists errors (what the API server would reject: a selector that does not
match the template, a probe on a port name the container lacks, a CPU request above its limit,
memory written as 128m, a CronJob name over 52 characters, a day of week of 7), warnings and,
when ticked, tips — and checks across the bundle: a Service whose selector matches no pod or
whose targetPort name does not exist, an Ingress backend port the Service lacks, an
autoscaler using CPU utilization on containers with no CPU request. Click a finding to jump to
the field. Lint in devops-yaml opens the bundle in the
Compose and Kubernetes checker.
⛶ Full screen (or F when you are not typing) gives the Build form and the YAML the whole
screen, side by side (stacked on a phone), each scrolling on its own — the browser’s full screen
where it is allowed, otherwise a full-window layer (iPhone). Escape leaves.
Explain browses the field docs for a kind: click into fields as with
kubectl explain deployment.spec.template.spec, or search names and descriptions. The docs
are a subset of the OpenAPI spec of Kubernetes v1.37.1 (api/openapi-spec/swagger.json):
every field of the kinds above except status, managedFields, ephemeral containers and
deprecated volume plugins, with long descriptions shortened. They load on first use.
Units & QoS converts and checks a quantity: CPU in cores or millicores (0.5 = 500m),
memory and storage in bytes and in decimal (k, M, G) and binary (Ki, Mi, Gi)
units, and catches the usual mistakes (128m, 1GB, 512 Mi). 1G is 1,000,000,000 bytes;
1Gi is 1,073,741,824. The QoS calculator takes the requests and limits of each container and
names the class the pod gets, following Kubernetes' own rules: requests default to limits;
Guaranteed needs CPU and memory limits on every container equal to the requests;
BestEffort has no CPU or memory requests or limits at all; everything else is Burstable.
Probes draws a timeline of a startup, readiness or liveness probe: when checks run, how long a failure takes to act on, and what happens then (removed from endpoints, or restarted). It uses the kubelet’s defaults for anything left out.
Schedule explains a CronJob schedule in words and lists the next ten runs in any time zone.
It follows the CronJob controller’s parser (robfig/cron): five fields, day of week 0–6, ? as
*, the @daily-style macros, and the rule that when both day fields are restricted a day
matches if either does.
Limits
-
The checks are a subset of the API server’s validation plus common mistakes; they do not know your cluster (admission policies, installed CRDs, quotas, which IngressClass exists).
-
Secret values stay in this page: they are left out of links, of what the browser remembers between visits, and of the devops-yaml link. Secrets are base64, not encryption — keep the YAML out of git.
-
The form covers the common fields; others (affinity, topology spread, lifecycle hooks, …) are kept from pasted YAML but edited as YAML elsewhere. The YAML reader handles what manifests use (block and flow style, anchors, block scalars,
---); like Kubernetes' YAML 1.1 reader, an unquotedyes/no/on/offis a boolean. -
Runs that fall in a daylight-saving gap are skipped in the next-run list; the controller’s handling of such times may differ.
-
The QoS rules ignore pod-level resources (a newer feature) and extended resources.
Related: Compose, Kubernetes and cron checker, kubectl helper (commands, selectors, JSONPath, RBAC), container dashboard, cron expression tool, YAML and JSON converter.
Linking to an example
Share link copies a link to what the open tab shows. On Build that is the bundle (packed
into ?s=, Secret values removed), or ?example=… while it is an unchanged example. Put the tab
after #: build, explain, units, probes or schedule.
| Parameter | Meaning | Example |
|---|---|---|
|
one of the bundles below |
|
|
start from a single new object of that kind (on |
|
|
the field to explain (with |
|
|
a quantity to convert and check, as |
|
|
a CronJob schedule and time zone ( |
|
|
|
|
|
probe settings, and when the app stops answering |
|
example= |
Opens |
|---|---|
|
a Deployment with a Service, an Ingress with TLS, and a CPU autoscaler (open) |
|
a PostgreSQL StatefulSet with a headless Service, a volume claim template and a Secret (open) |
|
a CronJob at 02:30 London time writing to a PVC (open) |
|
NetworkPolicies: deny everything, allow DNS, allow the ingress controller in (open) |
|
a DaemonSet with its ServiceAccount (open) |
|
an Indexed Job: 10 completions, 3 in parallel (open) |
|
a single CronJob (open) |
More: ?q=1G&res=memory#units (1G versus 1Gi),
?probe=startup&period=10&failure=30#probes
(a 300-second start budget),
?cron=0 0 1
(the day-of-month OR day-of-week rule),
?kind=Deployment&field=spec.strategy.rollingUpdate#explain.
Feedback is a gift. Something to improve, a feature to add, or a bug? Tell me.
Runs entirely in your browser; nothing you type leaves this page.