Kubernetes Deployment YAML Generator

A Kubernetes Deployment is a resource object that provides declarative updates to applications. It manages a replicated set of pods, ensuring the desired number of replicas are running at all times. Deployments support rolling updates, rollbacks, and scaling operations — making them the recommended way to run stateless applications on Kubernetes.

Deployments are designed for stateless applications — pods are interchangeable and have random identities. StatefulSets are for stateful applications requiring stable pod identities, persistent storage, and ordered deployment/scaling (e.g., databases like MongoDB, PostgreSQL). StatefulSets maintain sticky identities for each pod across rescheduling.

RollingUpdate incrementally replaces old pods with new ones. maxSurge controls how many extra pods can be created above the desired count during the update. maxUnavailable defines how many pods can be unavailable during the process. For example, with 3 replicas, maxSurge=1 and maxUnavailable=0, Kubernetes creates 1 new pod, waits for it to be ready, then terminates 1 old pod — repeating until complete. This ensures zero-downtime deployments.

Always set requests (minimum guaranteed resources) and limits (maximum allowed). Start by monitoring actual usage with tools like Prometheus. Set requests close to average usage, and limits at ~2x requests for burst capacity. For CPU, use millicores (e.g., 100m = 0.1 CPU). For memory, use Mi/Gi units. Avoid setting CPU limits too low — it can cause throttling. For Java apps, set memory limits with proper JVM heap sizing (-Xmx should be ~75% of the limit).

Kubernetes supports three probe types:
httpGet — performs an HTTP GET request; success = status code 200-399.
tcpSocket — attempts TCP connection; success = connection established.
exec — runs a command inside the container; success = exit code 0.
Use liveness probes to detect deadlocked containers (restart), readiness probes to control traffic routing, and startup probes for slow-starting apps (disables liveness/readiness until startup succeeds).

Use valueFrom in the env definition. For ConfigMaps: valueFrom.configMapKeyRef.name and .key. For Secrets: valueFrom.secretKeyRef.name and .key. You can also use envFrom to inject all keys from a ConfigMap/Secret as environment variables. This tool's environment variable section supports both direct values and references — use the dropdown to switch between modes.

emptyDir — ephemeral storage tied to pod lifecycle; deleted when pod is removed. Good for temp files, caches.
hostPath — mounts a directory from the host node; pod-specific, not portable. Use for node-level monitoring agents.
PersistentVolumeClaim (PVC) — durable, portable storage that survives pod restarts and rescheduling. Ideal for databases and stateful workloads. Use PVCs for any data that must persist beyond pod lifetime.

This status means a container keeps crashing after starting. Common causes: application bug causing exit code ≠ 0, missing environment variables, incorrect command/args, insufficient resource limits, or the container expecting external dependencies that aren't available. Check logs with kubectl logs <pod-name> and describe the pod with kubectl describe pod <pod-name> for detailed diagnostics.