Kubernetes Manifest Generator
Generate Deployment, Service, Ingress, ConfigMap, and HPA manifests with matching labels and ports.
Additional resources
- Apply with
kubectl apply -f manifests.yaml, or check first with--dry-run=server. - Resource requests drive scheduling and are required for an HPA to work at all — without them the autoscaler has no baseline.
- Readiness gates traffic; liveness restarts the pod. A liveness probe that is too aggressive will restart a healthy but slow service.
- Put real secrets in a Secret (or an external secrets operator), never in a ConfigMap.
Your Data Never Leaves Your Device
Every tool runs entirely in your browser. Nothing you type is uploaded, stored, or logged on our servers.
The Kubernetes Manifest Generator emits a Deployment and Service, with optional Ingress, ConfigMap, and HorizontalPodAutoscaler, as a single multi-document YAML file ready for kubectl apply.
The value is in the cross-references being correct by construction. A Deployment's selector.matchLabels must equal its pod template labels or it will not manage its own pods; the Service selector must match those same labels or it routes to nothing; and the Ingress backend port must match the Service port, not the container port. Those three mismatches account for a large share of “my manifest applied but nothing works” problems, and here they are generated together so they always agree. Resource requests are included by default because an HPA cannot compute utilisation without them.
FAQ
Readiness decides whether a pod receives traffic; liveness decides whether it gets restarted. A liveness probe that is too aggressive will kill a healthy service that is merely slow to start, which is why the generated liveness probe has a longer initial delay.
Requests, yes — the scheduler uses them to place pods, and an HPA cannot calculate utilisation without them. Limits are more nuanced: a CPU limit throttles rather than kills, while exceeding a memory limit gets the container OOM-killed.
ClusterIP for anything internal, which is most things. Use an Ingress rather than a LoadBalancer per service — a LoadBalancer allocates a cloud load balancer for each service and gets expensive quickly.
A Deployment's selector.matchLabels must equal the pod template labels or the Deployment will not manage its own pods, and the Service selector must match them too or it routes to nothing. These are generated together so they always agree.
No. ConfigMap data is stored in plain text and visible to anyone who can read the namespace. Use a Secret, and ideally an external secrets operator or sealed secrets, since even Secrets are only base64-encoded at rest by default.
Run kubectl apply --dry-run=server -f manifests.yaml. That validates against the real API server, including admission controllers, without changing anything in the cluster.