How to use the Kubernetes YAML Generator
1. Enter your app name, container image, and desired replica count.
2. Configure port, resource limits/requests, service type, and environment variables.
3. Copy the generated YAML — it includes both a Deployment and a Service definition ready to apply with kubectl apply -f.
What is it?
Kubernetes Deployments manage a set of identical container replicas, ensuring your application is always running at the specified count. The Deployment controller automatically replaces failed pods, handles rolling updates, and supports rollbacks. Paired with a Service, your application becomes accessible within the cluster (ClusterIP), from the node (NodePort), or via a cloud load balancer (LoadBalancer).
Resource requests and limits are critical in Kubernetes: requests tell the scheduler how much CPU/memory to reserve for pod placement; limits cap the maximum a container can consume, preventing one noisy-neighbour pod from starving others. Setting both correctly is a Kubernetes production best practice that prevents OOMKilled errors and uneven cluster load.
Example
App: my-api · Image: my-api:1.0.0 · Replicas: 3 · Port: 3000
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-api
spec:
replicas: 3
selector:
matchLabels: {app: my-api}
template:
spec:
containers:
- name: my-api
image: my-api:1.0.0
ports: [{containerPort: 3000}]Apply with: kubectl apply -f deployment.yaml. Use kubectl rollout status to track the rollout.
Benefits
Generate Kubernetes manifests without memorising the API schema
Produce valid Deployment and Service YAML with container spec, resource limits, labels, selectors, and port configuration.
Resource limits and requests included by default
Unconstrained containers starve other pods — the generator includes CPU and memory limits so your workload is production-safe from the start.
Liveness and readiness probes configured correctly
Probes prevent traffic from reaching unhealthy pods — the generator includes correct probe configuration for your container's health endpoint.
Bootstrap Kubernetes configuration for a new service in minutes
Start from a complete, valid YAML rather than copying from documentation or adapting a previous service's manifest.
Frequently asked questions
What is the difference between ClusterIP, NodePort, and LoadBalancer?
ClusterIP (default) exposes the service only inside the cluster — other pods can reach it but external users cannot. NodePort exposes the service on a static port on every node's IP — useful for testing. LoadBalancer provisions a cloud load balancer (AWS ELB, GCP LB) to expose the service externally — used in production.
What are resource requests and limits?
Requests are the minimum CPU/memory guaranteed to the container — used by the scheduler to place pods on nodes with enough capacity. Limits are the maximum — if a container exceeds its memory limit, it gets OOMKilled (killed for Out Of Memory). Setting requests = limits is the most predictable configuration.
What does kubectl apply -f do?
kubectl apply -f deployment.yaml reads your YAML file and creates or updates the Kubernetes resources described in it. Unlike kubectl create, apply is idempotent — running it multiple times only changes what's different, making it safe for CI/CD pipelines and GitOps workflows.