Kubernetes Manifest Generator

Generate a complete Kubernetes manifest — a Deployment plus a matching Service, with an optional Ingress and ConfigMap — from a short form. Set the image, replica count, container port, CPU and memory requests and limits, environment variables, and readiness and liveness probes, and the tool emits valid YAML you can kubectl apply. Everything is generated in your browser.

manifest.yaml

How to use the Kubernetes Manifest Generator

Enter the application name (used for every resource and its labels), the container image with tag, the replica count, and the port the container listens on. Set CPU and memory requests (what the scheduler reserves) and limits (the hard ceiling) using Kubernetes units — m for milli-CPU, Mi or Gi for memory. Add environment variables one per line as KEY=value. The manifest regenerates live; copy it to a file and run kubectl apply -f manifest.yaml.

Toggle the extras to match your setup: an Ingress adds an HTTP route (you will need an ingress controller in the cluster), and a ConfigMap moves your environment values into a separate object the Deployment references. Keep probes enabled for any real workload — they let Kubernetes restart a hung container and keep traffic off a pod until it is ready. Adjust the probe paths to a real endpoint your app serves.

The objects in a Kubernetes manifest

A Kubernetes manifest is a YAML description of the desired state of one or more API objects. You declare what you want — three replicas of this image, reachable on this port — and the control plane works continuously to make the cluster match, rescheduling pods when nodes fail and rolling out changes when you update the spec. A typical stateless web app needs a small set of objects that this generator produces together.

The Deployment is the core: it manages a ReplicaSet that keeps the requested number of identical pods running, and handles rolling updates and rollbacks when the pod template changes. Each pod runs your container with the image, ports, environment, and resource constraints you set. The Service gives those pods a stable virtual IP and DNS name, load-balancing across whichever pods are currently healthy — essential because pods are ephemeral and their IPs change.

Two things separate a toy manifest from a production one. Resource requests and limits let the scheduler place pods without overcommitting nodes and stop a single container from starving its neighbours; without requests, the scheduler is flying blind. Probes tell Kubernetes about application health: a readiness probe keeps a pod out of the Service until it can serve traffic, and a liveness probe restarts a container that has hung. Optionally, an Ingress routes external HTTP traffic to the Service by host and path, and a ConfigMap holds configuration separately from the image so you can change settings without rebuilding.

Common use cases

  • Deploying a service. Generate the Deployment and Service for a stateless app in one step.
  • Manifest templates. Produce a correct base to copy into a repo or a Kustomize overlay.
  • Learning Kubernetes. See how Deployment, Service, and Ingress fit together with real fields.
  • Adding probes and limits. Bring an under-specified workload up to production standards.

Frequently asked questions

What is the difference between requests and limits?
A request is what the scheduler reserves for the container and uses to decide which node has room; a limit is the hard ceiling the container may use. CPU above the limit is throttled, while memory above the limit gets the container OOM-killed. Setting both keeps scheduling sane and protects nodes.

Why do I need both a Deployment and a Service?
The Deployment runs and maintains your pods, but pod IPs are ephemeral and change on every restart. The Service provides a stable IP and DNS name in front of the pods and load-balances across the healthy ones, so other workloads have a fixed address to reach.

What is the difference between readiness and liveness probes?
A readiness probe controls traffic: until it passes, the pod is kept out of the Service endpoints. A liveness probe controls restarts: if it fails, the kubelet kills and restarts the container. Use readiness for slow startup and liveness for detecting hangs. Point both at a real endpoint your app serves.

Do I need an ingress controller for the Ingress?
Yes. An Ingress object is just routing rules; it does nothing without an ingress controller (such as ingress-nginx or Traefik) installed in the cluster to fulfil them. If you have no controller, expose the app with a LoadBalancer or NodePort Service instead.

Should configuration go in a ConfigMap or env vars?
Both work; a ConfigMap simply stores the values as a separate object the Deployment references, so you can change configuration without editing the Deployment or rebuilding the image. For a few simple values, inline env vars are fine; for larger or shared config, a ConfigMap is cleaner. Never put secrets in either — use a Secret.