Kubernetes Manifest Generator

How to use it

1. Pick the object chain: Deployment alone, Deployment + Service, or Deployment + Service + Ingress — the on-page cards follow the preset.
2. Name the app and set the image with a tag or digest; the name becomes every object's name, the app label and the selector.
3. Set replicas and the container ports, then add env rows — a toggle carries them in a ConfigMap through envFrom instead of inline values.
4. Optionally add HTTP probes, resource requests and limits in Kubernetes quantities, the Service type and port, and the Ingress host and path.
5. Press Generate manifests, then copy or download each card — or all of them as one manifests.yaml — and apply with kubectl.

Fill a guided form and get Deployment, Service and Ingress YAML whose wiring actually lines up: the selector matches the pod labels, the Service targets the right container port, the Ingress routes to the Service it names. Field rules follow the Kubernetes documentation, and every output shape this form can produce is schema-tested against Kubernetes v1.33 in CI. Everything runs on this device — no cluster, no upload.

How it works

Generation runs in two phases. Validation collects every finding in one pass — a bad name never hides a bad port — and each field rule carries its kubernetes.io citation: object names are DNS-1123 labels, Ingress hosts are RFC 1123 with one leading wildcard label allowed, label keys take an optional DNS-subdomain prefix, env names never start with a digit. Refusals block emission; advisories, like an untagged image, ride the constraint strip beside finished cards.

The selector is the contract the whole chain hangs on. This generator writes the minimal form: the Deployment's selector matches exactly one label pair, app set to your name, and the pod template carries that same pair. Extra labels you add land on object metadata and the pod template only — never in the selector — because a selector is immutable after create, and every label in it must keep matching the template forever. The Service reuses the same single pair, so the pods a Deployment manages are exactly the pods its Service routes to.

Ports chain through three names that read alike and mean different things. containerPort is what the process listens on; the Service's port is what clients call; targetPort is how the Service finds the container — here it is always your first container port. The Ingress never sees a pod: its backend names the Service and the Service's own port number, which is why an Ingress card only exists in the preset that also emits the Service it routes to. Paths are matched as pathType Prefix, the documented choice that covers subpaths.

Resource fields parse as real Kubernetes quantities through the same shared quantity engine the resource calculator on this site uses — decimal cpu like 0.5 normalizes to 500m, binary memory like 128Mi stays binary, and a limit below its request is refused because the API server refuses it. Env values that look credential-shaped draw a warning naming the key, never echoing the value, and the page points at a Secret instead — a ConfigMap is plaintext by design.

The schema claim is specific: CI executes every output shape this form can reach and validates each object against the frozen v1.33.1 strict schemas (additionalProperties: false), so an emitted key that Kubernetes does not define fails the build, not your cluster. The page itself validates nothing at runtime — for YAML you have edited afterwards, the Kubernetes YAML validator on this site does that job in your browser.

Examples

Deployment only: web on nginx:1.27, 2 replicas

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 8080

Deployment + ClusterIP Service, 80 to 8080

apiVersion: v1
kind: Service
metadata:
  name: web
  labels:
    app: web
spec:
  type: ClusterIP
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP

Full chain: Ingress for web.example.com

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  labels:
    app: web
spec:
  ingressClassName: nginx
  rules:
    - host: web.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

Edge: NodePort for a lab without a load balancer

apiVersion: v1
kind: Service
metadata:
  name: web
  labels:
    app: web
spec:
  type: NodePort
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP

ConfigMap env plus resources, cpu written as 0.5

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 8080
          envFrom:
            - configMapRef:
                name: web-config
          resources:
            requests:
              cpu: 500m
              memory: 128Mi
            limits:
              memory: 256Mi

Every example on this page is executed against the same engine that powers the tool, on every build.

Common errors

Name `Web_App` is not a valid DNS-1123 label — lowercase letters, digits and hyphens, starting and ending with a letter or digit, at most 63 characters.

Object names become DNS entries — web.default.svc.cluster.local — so uppercase and underscores are out. web-app is the usual rewrite.

Ingress host `Web.example.com` is not a valid RFC 1123 host — lowercase DNS labels separated by dots (one leading `*.` wildcard label is allowed).

Hosts follow DNS rules: lowercase, digits and hyphens per label. A wildcard is legal only as the entire first label, *.example.com — never in the middle.

Container port `70000` must be a whole number between 1 and 65535.

TCP ports are 16-bit. The same band applies to the Service port; the two are validated separately so the message names the field you actually mistyped.

`nginx` has no tag or digest — Kubernetes will pull `:latest`, which the images documentation advises against relying on in production.

The cards still generate — an untagged reference is legal — but what :latest points at changes under you. Registry ports never trip this check: localhost:5000/web is untagged, localhost:5000/web:2 is not.

The env value of `AWS_ACCESS_KEY_ID` looks like a credential — put it in a Secret and reference it, instead of a ConfigMap or plain env; nothing typed here is a secret store.

ConfigMaps and pod specs are plaintext to anyone who can read them. The warning names the key, never repeats the value — and share links from this page structurally exclude every typed value anyway.

Keyboard shortcuts

/

Focus the app name (outside any field).

⌘/Ctrl + Enter

Generate the manifests from the current form.

⌘/Ctrl + S

Download every object as manifests.yaml.

⌘/Ctrl + C

With no text selected, copy all generated YAML.

⌘/Ctrl + Shift + C

Force the copy while a selection is active.

t

Cycle the site theme (inactive while typing in a field).

? or ⌘/Ctrl + /

Show the shortcut overlay.

Esc

Dismiss the topmost dialog.