Kubernetes YAML Generator

Deploying one container to Kubernetes takes several objects that must agree with each other: a Deployment that runs the pods, a Service that gives them a stable address, an Ingress that routes a hostname to that Service, and often an autoscaler. Writing them by hand means repeating names, labels and ports in several places, and one typo breaks the chain silently. This generator writes all four from one form.

The four objects

The Deployment describes the pod template, the container image, its port, environment variables, resources and probes, and how many replicas to run. The Service selects those pods by label and exposes them inside the cluster on a port of its own. The Ingress maps a hostname and path to the Service for traffic from outside. The HorizontalPodAutoscaler watches CPU usage and changes the Deployment’s replica count between a minimum and a maximum.

How they connect

Everything hangs on labels and names. The pods carry app.kubernetes.io/name: web, the Deployment’s selector and the Service’s selector both match that label, and the Ingress and HPA refer to the Service and Deployment by name. The container port is named http, and the Service’s targetPort and the probes refer to that name rather than a number, so changing the container port later only needs one edit.

Probes and resources

With a health path set, the container gets a readiness probe, which keeps a pod out of the Service until it answers, and a liveness probe, which restarts a pod that stops answering. Resource requests tell the scheduler how much CPU and memory to reserve, and limits cap what the container may use. Requests are also what the autoscaler compares usage against.

Ingress and TLS

Setting a host adds an Ingress with ingressClassName, a single / path of type Prefix and the Service as backend. With TLS on, it adds a tls section that stores the certificate in a secret named after the app and the annotation cert-manager.io/cluster-issuer: letsencrypt, so cert-manager requests and renews a certificate automatically if it is installed with an issuer of that name.

Autoscaling and replicas

When the HPA is enabled, the Deployment deliberately has no replicas field. If it did, every kubectl apply would reset the count to that number and undo the autoscaler’s decision. The HPA uses the autoscaling/v2 API with a target average CPU utilisation, and its minimum replica count takes the place of the fixed number.

A worked example

With the default form values, the output contains four documents separated by ---: a Deployment for ghcr.io/example/web:2.4.1 without a replicas line, a ClusterIP Service on port 80, an Ingress for app.example.com with ingressClassName: nginx and TLS, and an HPA from 2 to 6 replicas with averageUtilization: 70. Turning the autoscaler off puts replicas: 2 back into the Deployment.

Applying the manifests

Download the file and validate it against the cluster with kubectl apply --dry-run=server -f web.yaml, which catches schema errors and admission policies without changing anything. Then apply for real and watch the rollout with kubectl rollout status deployment/web. Configuration files, Secrets, volumes and network policies are not generated and can be added as separate documents.

Related tools

• Kubernetes Resource Calculator sizes the requests and limits.
• docker run to Compose covers single-host setups.
• YAML to JSON converts manifests for tools that need JSON.
• .env Converter turns a .env file into a ConfigMap or Secret.