Skip to content
~/Kubernetes YAML Generator
$

Kubernetes YAML Generator

Build Kubernetes manifests visually — configure resources with form fields, preview generated YAML in real-time, and export production-ready configs.

Presets

Basic

Labels

Annotations

Strategy

Containers

Container 1

Node Selector

Tolerations

Image Pull Secrets

Generated YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: default
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: app
          image: "nginx:latest"
          ports: - containerPort: 80
  name: http
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: "25%"
      maxUnavailable: "25%"

What is a Kubernetes manifest?

A manifest is a YAML (or JSON) file that declares the desired state of a cluster resource: which container image to run, how many replicas, which ports to expose, what storage to claim. You submit it with kubectl apply -f manifest.yaml and Kubernetes controllers continuously reconcile reality to match it. Every manifest needs four top-level fields — apiVersion, kind, metadata, and (for most kinds) spec — and getting any of them wrong is the most common beginner error.

How does this generator work?

Pick one of eight resource types — Deployment, Service, Ingress, ConfigMap, Secret, PersistentVolumeClaim, CronJob, or Namespace — and fill in form fields for images, replicas, ports, labels, probes, resource limits, tolerations, and more. The YAML preview updates in real time with correct indentation and apiVersion for each kind. Everything runs locally in your browser, so internal image names and secret values never leave your machine.

How do I validate Kubernetes YAML before applying it?

Use a dry run: kubectl apply -f deploy.yaml --dry-run=client checks syntax and schema locally, while --dry-run=server sends the manifest to the API server for full admission validation without persisting anything. Add kubectl diff -f deploy.yaml to see exactly what would change on a live cluster. For CI pipelines, kubeconform or kubectl-validate catch schema drift against specific Kubernetes versions before anything reaches the cluster.

What is the difference between a Deployment and a Pod?

A Pod is the smallest deployable unit — one or more containers sharing a network namespace. But bare Pods are not rescheduled if their node dies. A Deployment wraps Pods in a ReplicaSet that maintains the desired replica count, performs rolling updates with configurable maxSurge and maxUnavailable, and supports instant rollback via kubectl rollout undo. In practice you almost never create bare Pods; you declare Deployments and let Kubernetes manage the Pods.

When should I use ClusterIP, NodePort, or LoadBalancer?

ClusterIP (the default) exposes a Service only inside the cluster — right for databases and internal APIs. NodePort opens a high port (30000-32767) on every node, useful for quick demos and bare-metal setups. LoadBalancer asks your cloud provider to provision an external load balancer per Service, which gets expensive fast — which is why most production clusters put one Ingress controller behind a single LoadBalancer and route HTTP traffic by host and path instead.

Are Kubernetes Secrets actually encrypted?

No — by default Secret values are only Base64-encoded, and anyone with kubectl get secret -o yaml access can decode them in one command. Base64 is encoding, not encryption. For real protection, enable encryption at rest for etcd, restrict Secret access with RBAC, and consider external managers like Vault, Sealed Secrets, or the External Secrets Operator. This generator Base64-encodes your Secret data fields automatically, exactly as kubectl create secret would.

Why won't my manifest apply?

The classic failures: a tab character instead of spaces (YAML forbids tabs), an apiVersion that moved between releases (Ingress graduated from extensions/v1beta1 to networking.k8s.io/v1), a Service selector that does not match the Deployment's Pod labels (traffic silently goes nowhere), and missing resource requests causing Pods to be evicted under pressure. A form-driven builder removes the indentation and apiVersion classes of error entirely, leaving you to verify only the values.