Kubernetes Manifest Generator

A Kubernetes manifest fails in two ways: it is rejected outright for a missing key or an illegal name, or it is accepted and quietly does nothing because a Deployment's selector does not match its pod template's labels. This generates a Deployment, Service or ConfigMap with all three required fields present, names that satisfy the DNS-1123 rules the API server enforces, and — for a Deployment — a selector checked against the template it is supposed to select.

What this generator does

Builds one Kubernetes object of the kind you choose, renders it to YAML, reads it back with an independent parser and compares the two. It then applies the API's own requirements: apiVersion, kind and metadata.name must all be present, names must be legal DNS-1123 labels, a Deployment must have at least one replica, its selector must match its pod template's labels, and every container must name an image with an explicit tag.

How to use this tool

Choose the kind of object you want.
Generate, and read the manifest.
Check the verification note: required keys, name rules and label agreement.
Copy it and change the image, namespace and resource figures for your cluster.

Understanding the controls

Object kind: Deployment for a workload, Service to expose one, ConfigMap for non-secret configuration. Each has a different required shape, which is why they are separate rather than one manifest with parts commented out.
Generate: Draws a fresh application name, namespace, image, port and replica count.

Common use cases

Starting a manifest without looking up the apiVersion again
Showing what a Deployment's selector and template labels have to have in common
Producing fixtures for a tool that reads Kubernetes YAML
Teaching the required fields every Kubernetes object shares
Getting a resource requests and limits block with plausible figures in it

How this generator works

Each kind is built as data with its own required shape, then written to YAML and read back independently. The interesting check is the Deployment's: `spec.selector.matchLabels` and `spec.template.metadata.labels` are compared as structures, because a Deployment whose selector does not match its template is accepted by the API server and then adopts no pods at all — the failure that looks like nothing happening. Container images are checked for an explicit tag, since an untagged image silently means :latest.

Randomness and fairness

Names, namespaces, images, ports and replica counts are drawn with the browser's cryptographic random source. The structure of each kind is fixed, because that structure is what the API server requires.

For how randomness is produced across the whole site, see how Generate Random works.

Limitations and good to know

Three kinds only. Ingresses, StatefulSets, Jobs and CRDs have their own shapes and are not covered.
It checks the manifest against the rules that apply to every cluster, not against your cluster's admission controllers or policies.
No liveness or readiness probes, which a production Deployment should have.
Secrets are deliberately absent: a generated Secret would be a sample credential, and those get pasted into real clusters.

Privacy and your data

The manifest is built in your browser from built-in sample values. You enter nothing, nothing is uploaded or stored, and analytics records only that the tool ran.