Kubernetes YAML Generator

Scaffold Kubernetes Deployment, Service, and Ingress manifests from a small form. Copy the YAML straight into kubectl. Runs entirely in your browser.

Resource

Kind Name Namespace

Labels (key=value, comma separated)

Image Replicas Container port

Manifest

—

How it works

Pick a kind, fill the fields, and click Generate YAML — a valid manifest (apiVersion, metadata, spec) is built for you.
Deployment scaffolds a workload with replicas, a container, and a container port; Service maps a port to a target port; Ingress routes a host + path to a service.
Labels you enter are reused as the selector so Service ↔ Deployment wire up correctly.
Apply with kubectl apply -f - after pasting.

About Kubernetes YAML Generator

Kubernetes objects are YAML documents, and the common workflow — a Deployment for your pods, a Service for stable networking, an Ingress for external traffic — has a lot of repetitive boilerplate: apiVersion, kind, metadata, labels, selectors, and ports all need to agree. This generator produces consistent, minimal manifests so you start from something that works instead of from a blank file or a blog snippet you cannot fully trust.

The output targets current stable APIs: apps/v1 for Deployments, v1 for Services, and networking.k8s.io/v1 for Ingress. Treat it as a starting point — add resource requests/limits, probes, config maps, and secrets for production, and remember that the Service selector must match the Deployment’s pod labels, which this tool wires up for you automatically. If your cluster is older, check that the Ingress API version and class name are supported before applying.

Deployment, Service, Ingress and the label contract

The three objects are three different jobs, and the generator's real contribution is making the one thing that commonly breaks agree across all of them. A Deployment needs a selector that matches its own pod template; a Service needs a selector that matches pods it should route to. Both are filled from the same single label input, which is emitted three times in the Deployment — `metadata.labels`, `spec.selector.matchLabels`, and `spec.template.metadata.labels` — so a mismatch is structurally impossible here rather than merely unlikely.

Ingress does not use a label selector. It names a backend service and a backend port, which is why its fields are separate from the Service's: the object it points at is a Service, and the port it names is that Service's `port`, not the container's. Labels entered for an Ingress are written to `metadata.labels` only, and have no effect on routing.

Ports, naming, and what each number means

Three port numbers appear in a working stack and they are not interchangeable. `containerPort` is documentation plus a default for named targets; the Service's `port` is what clients and an Ingress reference; `targetPort` is where the Service forwards. This tool emits numeric `containerPort` and numeric `targetPort`, which always resolve — but if you later switch to a named `targetPort` to decouple the Service from a container port, remember that a named target requires the container port to carry a matching `name`, and the generated manifests leave both unnamed.

The Ingress backend port field is independent of the Service fields and is not cross-checked against them. Point an Ingress at `app.example.com` with backend port 80 while the Service exposes 8080 and the rule returns 503 with no obvious cause — the object is valid, it just has nothing listening on the port it names.

What the generated YAML leaves out

There is no `resources` block, which means every pod is BestEffort QoS: first in line for eviction under node pressure, and invisible to a scheduler that bin-packs on requests. There are no probes either, so a rolling update will happily route traffic to a container that is running but not ready. Neither is fatal for a manifest you apply while learning; both matter the moment replicas actually serve traffic.

The Ingress is inert YAML until an ingress controller with a matching `ingressClassName` is watching that namespace — the object alone does nothing. The namespace is written into `metadata.namespace` but never created, so `kubectl apply` fails outright if it does not already exist. Names are checked against DNS-1123 and at least one label is required, since the Deployment selector cannot be empty; ports are range-checked, and an empty Ingress path falls back to `/`.

Frequently Asked Questions

How do I generate Kubernetes manifests?

Select the resource type (Deployment, Service or Ingress), fill in the form fields (name, namespace, labels, image, replicas, ports), and click Generate YAML. The tool outputs a minimal manifest for that one resource, ready to apply with kubectl.

Can I generate multiple resources at once?

Not in one click. The generator emits a single resource per run — pick Deployment, Service or Ingress, generate, then paste the documents into one file separated by --- if you want a multi-resource bundle. ConfigMap, Secret and PVC are not supported.

Is the generated manifest production-ready?

It is a valid starting point, not a production manifest. There is no resources block, so pods get BestEffort QoS, and there are no readiness or liveness probes. Add both before serving traffic, and create the namespace first — the manifests write metadata.namespace but never create it.

Is my data sent to a server?

No. Every tool on jsonversal runs entirely in your browser using the Web Crypto API, File API, and Clipboard API. Nothing is ever uploaded — not even the JSON you paste in.

Do I need an account or API key?

No signup, no email, no API key. All tools are free to use with no signup required.

Can I use these tools offline?

Yes. Once the page loads, all tools work offline. There are no external API calls or CDN dependencies at runtime.

🔒

Your data never leaves your device

All processing happens in your browser. No uploads, no tracking, no servers. Your API keys, configs, and private payloads stay private — 100% client-side.