Kubernetes manifest generator

What the generator sets up for you

Every manifest uses the recommended app.kubernetes.io/name label for the Deployment selector, the pod template and the Service, so the three always match. Ports are named (http) and the Service and probes refer to the name rather than the number, so changing the container port is a one-line edit.

The defaults follow common production guidance:

• Resources. A CPU and memory request so the scheduler can place the pod, and a memory limit so one leaking pod cannot exhaust the node.
• Probes. A readiness probe that gates traffic and a slower liveness probe that restarts a stuck process.
• Rolling updates. maxUnavailable: 0 keeps full capacity during a rollout; maxSurge: 25% adds new pods before old ones are removed.
• Security. With hardening on, the pod passes the Kubernetes restricted Pod Security Standard: non-root, no privilege escalation, all capabilities dropped, the RuntimeDefault seccomp profile and a read-only root filesystem with a writable /tmp.

Example output

The core of the generated Deployment for nginxinc/nginx-unprivileged:1.27 (an nginx build that runs as non-root on port 8080) with default settings looks like this, shortened for readability:

spec:
  replicas: 2
  revisionHistoryLimit: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 25%
  template:
    spec:
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: web
        image: nginxinc/nginx-unprivileged:1.27
        ports:
        - name: http
          containerPort: 8080
          protocol: TCP
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            memory: 256Mi
        readinessProbe:
          httpGet:
            path: /healthz
            port: http

Applying the manifests

Download the combined file and apply it, then wait for the rollout:

kubectl apply -f web.yaml
kubectl -n default rollout status deployment/web
kubectl -n default get pods -l app.kubernetes.io/name=web

Check the result with a dry run against the API server before applying to a shared cluster: kubectl apply --dry-run=server -f web.yaml validates the manifests against the cluster’s actual API versions and admission policies.

Once you add your own changes, run the file through the Kubernetes YAML validator (the button under the generated manifests opens it pre-filled). It draws how the resources connect and flags security and reliability regressions such as a dropped securityContext or a missing memory limit.

Common pitfalls

• The official nginx image runs as root. Hardened mode will refuse to start it. Use nginxinc/nginx-unprivileged (which listens on 8080) or build an image with a non-root USER.
• Probe path returns 404. The readiness probe defaults to /healthz. If your app has no health endpoint, choose a TCP probe or add one; a probe that always fails keeps the pod out of the Service forever.
• HPA shows <unknown> targets. The autoscaler needs metrics-server installed and a CPU request on the container.
• Secrets in environment variables. Plain env values are stored in the Deployment and visible to anyone who can read it. Put credentials in a Secret and reference them with valueFrom.secretKeyRef.