Kubernetes manifest generator
Fill in the basics and get a matching Deployment, Service, Ingress, autoscaler and disruption budget.
Starter manifests you would write anyway
Almost every web service on Kubernetes needs the same handful of objects, and almost every team copies them from the last project and edits names until it works. The result is easy to get subtly wrong: a selector that does not match the labels, a Service pointing at the wrong port name, an Ingress without TLS, an HPA that cannot scale because the Deployment has no CPU request.
Enter the application name, image, port and resources and this generator writes a consistent set of manifests: Deployment with readiness and liveness probes and resource requests, a Service, an Ingress with a TLS secret, a HorizontalPodAutoscaler on CPU, a PodDisruptionBudget and a ConfigMap for your environment variables. Names, labels and selectors all derive from one name, so they always agree. The defaults suit a Spring Boot service (the probe path is the Actuator health endpoint and the JVM is told to use a share of the container memory).
Things it warns about
- Unpinned or
:latestimages, which make rollbacks unpredictable. - An HPA with no CPU request, which cannot compute utilization.
- A CPU limit, which can throttle the application even when the node is idle.
- An Ingress without TLS, and a PodDisruptionBudget on a single replica (it blocks node drains).
The output is a base to commit to your repository, then adapt with Kustomize or Helm. Review it for your cluster's version and conventions. Everything runs in your browser.
Frequently asked questions
Which resources are generated?
A Deployment for the application, plus (optionally) a ConfigMap for environment variables, a Service, an Ingress with TLS, a HorizontalPodAutoscaler and a PodDisruptionBudget. Everything is labelled with app.kubernetes.io/name so the selectors match.
Why does the Deployment omit replicas when autoscaling is on?
If a manifest declares replicas and an HPA also controls them, every kubectl apply resets the count to the manifest value and fights the autoscaler. Leaving the field out hands control to the HPA.
Requests versus limits?
Requests are what the scheduler reserves for the Pod and what the HPA uses to compute CPU utilization. Limits are the ceiling: exceeding the memory limit gets the container killed, and a CPU limit throttles it.
What is a PodDisruptionBudget?
It limits how many Pods of an application can be taken down voluntarily at once, for example during a node drain or upgrade, so the service stays available.