Kubernetes YAML Generator

The Kubernetes YAML Generator creates production-ready K8s manifests for the resources you use daily: Deployments, Services (ClusterIP, NodePort, LoadBalancer), Ingresses, ConfigMaps, Secrets, CronJobs, StatefulSets, DaemonSets, PersistentVolumeClaims, HorizontalPodAutoscalers, and NetworkPolicies. Each form fills in the boilerplate (apiVersion, metadata, labels, selectors) and includes best-practice fields (resource requests/limits, liveness/readiness probes, security context, topology spread). The generator follows the latest K8s conventions (as of 1.30+) and produces manifests that pass kubectl apply --dry-run=client.

Writing Kubernetes YAML by hand is tedious and error-prone. One misplaced dash, wrong indentation, or mistyped field name and kubectl apply fails with a cryptic error. Boilerplate (apiVersion, labels, selectors) is the same 80% of the time across manifests. Production-ready manifests need dozens of fields (probes, limits, security, anti-affinity) most developers leave off. This generator fills them in by default, producing manifests ready for kubectl apply -f manifest.yaml in dev, staging, or production clusters.

Kubernetes manifests are YAML files that describe desired state of resources. The API server reconciles actual state to match.

Universal manifest structure:

``yaml
apiVersion: apps/v1 # API group/version for this resource
kind: Deployment # Resource type
metadata: # Resource identity
name: my-app
namespace: default # Optional
labels:
app: my-app
spec: # Desired state (varies by kind)
# ...
``

Common resources and their specs:

Deployment (stateless apps):

``yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: app
image: myapp:1.0
ports:
- containerPort: 3000
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
livenessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 30
readinessProbe:
httpGet:
path: /ready
port: 3000
``

Service (network routing):

``yaml
apiVersion: v1
kind: Service
metadata:
name: my-app
spec:
type: ClusterIP # or NodePort, LoadBalancer
selector:
app: my-app
ports:
- port: 80 # External port
targetPort: 3000 # Pod port
``

Ingress (HTTP routing):

``yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-app
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
tls:
- hosts: [example.com]
secretName: my-app-tls
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-app
port: { number: 80 }
``

Key production-readiness fields:

- Resources (requests/limits): requests = guaranteed, limits = maximum. Without these, pods can be evicted or hog resources.
- Probes: liveness (when to restart), readiness (when to serve traffic), startup (initial slow boot).
- SecurityContext: runAsNonRoot, readOnlyRootFilesystem, drop capabilities.
- TopologySpreadConstraints: spread pods across availability zones.
- PodDisruptionBudget: minimum available during upgrades.
- HorizontalPodAutoscaler: scale based on CPU, memory, or custom metrics.
- NetworkPolicy: firewall rules between pods.

Labels and selectors:

Labels identify resources. Selectors find resources by labels. Standard labels (2026):

``
app.kubernetes.io/name: myapp
app.kubernetes.io/instance: myapp-production
app.kubernetes.io/version: 1.0.0
app.kubernetes.io/component: api
app.kubernetes.io/part-of: mysystem
app.kubernetes.io/managed-by: helm
``

API versions over time:

- apps/v1 — current stable for Deployment, StatefulSet, DaemonSet.
- networking.k8s.io/v1 — current stable for Ingress, NetworkPolicy.
- batch/v1 — Job, CronJob.
- autoscaling/v2 — HPA with custom metrics.
- Old versions (extensions/v1beta1, apps/v1beta1) — deprecated, should be migrated.

Namespaces:

Isolate resources. Specify with metadata.namespace or kubectl -n. Common: default, kube-system, ingress-nginx, monitoring.

Kubernetes vs Docker Compose: Compose for single-host or dev. K8s for multi-host production, auto-scaling, self-healing. Migrate from Compose to K8s when scale or reliability requirements grow.

K8s vs Docker Swarm: Both orchestrate containers. K8s is industry standard with massive ecosystem. Swarm is simpler but declining in adoption. New projects: K8s.

Plain YAML vs Helm: Plain YAML for simple apps. Helm (charts) for templating and versioning. Helm is essential for deploying third-party software (Prometheus, Postgres operators). For your own apps, Kustomize or plain YAML often sufficient.

Plain YAML vs Kustomize: Kustomize is built into kubectl (kubectl apply -k). Base + overlay pattern for environments. Simpler than Helm for your own apps.

Manual manifests vs operators: Operators (Postgres Operator, Elastic Operator) wrap complex apps. User creates a custom resource (simpler than full manifests). Operator generates underlying manifests. Great for databases and infrastructure.

kubectl vs GitOps (ArgoCD/Flux): kubectl apply for ad-hoc. GitOps (ArgoCD, Flux) sync cluster state from Git repo automatically. More reliable for teams; essential for production.

Imperative vs Declarative: kubectl create (imperative) — one-shot commands. kubectl apply (declarative) — reconcile to desired state. Always use declarative for production. Imperative for exploration.