ZeonTools
0101. What is a Kubernetes Deployment?
A Kubernetes Deployment is a controller object that provides a declarative way to manage stateless applications. Rather than directly managing Pods (the atomic unit of compute in Kubernetes), you express your desired state in a YAML manifest and Kubernetes reconciles the actual cluster state to match it — continuously, in a control loop.
Underneath the hood, a Deployment manages a ReplicaSet, which in turn creates and monitors Pods. This abstraction layer delivers three capabilities that raw Pods cannot:
- Zero-Downtime Rolling Updates: When you change the container image, Kubernetes replaces Pods incrementally according to the
maxUnavailableandmaxSurgeparameters. By default, it ensures at least 75% of desired replicas remain available throughout the rollout. This means a cluster running 10 replicas can have at most 3 unavailable and at most 11 total Pods during a rolling update. - Instant Rollback: Every rollout creates a new ReplicaSet revision. The command
kubectl rollout undo deployment/my-appatomically shifts traffic back to the previous stable ReplicaSet within seconds. You can also jump to a specific revision with--to-revision=N. - Continuous Self-Healing: The Deployment controller runs a watch loop in the Kubernetes API server. If a Pod is evicted because its Node runs out of memory, or if a container crashes and its Liveness Probe fails, the controller immediately schedules a new Pod on a healthy Node to restore the
replicascount.
The selector.matchLabels field in your generated YAML is critical — it links the Deployment to the Pods it owns. If you change these labels after creation without also updating the Pod template labels, the Deployment will lose ownership of its Pods, creating orphaned resources and a potential replica storm.
Rolling Update Strategy: maxSurge & maxUnavailable
Our generator always adds an explicit strategy.type: RollingUpdate block with maxSurge: 1 and maxUnavailable: 0. This is the safest production configuration: Kubernetes will add one extra Pod beyond the desired replica count before removing an old one, ensuring zero unavailability throughout the rollout.
For high-traffic production deployments, tune these values based on your SLA requirements:
The kubectl rollout status deployment/my-app command blocks and waits until all new Pods pass their Readiness probes, then exits with code 0. This makes it perfect as a CI/CD pipeline step: fail the pipeline if a deployment does not become healthy within your timeout window.
0202. Kubernetes Services: ClusterIP, NodePort & LoadBalancer
Pods are fundamentally ephemeral. They can be terminated and rescheduled at any time, receiving a new IP address on each restart. Without a stable endpoint, no other application in your cluster can reliably communicate with them. A Kubernetes Service solves this by providing a virtual, stable DNS name and IP address (called a ClusterIP) that automatically load-balances TCP/UDP traffic to all matching Pods via kube-proxy rules on each Node.
The three primary Service types cover the full spectrum from internal communication to public internet exposure:
ClusterIPNodePortLoadBalancerAn important implementation detail: a LoadBalancer Service on a managed cloud cluster (EKS, GKE, AKS) automatically provisions a cloud load balancer through the cloud controller manager. However, each LoadBalancer Service creates a separate, billable load balancer resource. For most applications, using a single Ingress controller (backed by one LoadBalancer Service) to route traffic to multiple backend ClusterIP Services is dramatically more cost-effective.
0303. Ingress Controllers: NGINX, Traefik & AWS ALB Deep Dive
An Ingress is a Kubernetes API resource that defines rules for routing external HTTP/S traffic to internal Services. It is not itself a load balancer; it is a set of routing rules that must be interpreted by an Ingress Controller running inside your cluster.
The most widely deployed controller is NGINX Ingress (maintained by the Kubernetes project at kubernetes/ingress-nginx). It runs as a Deployment inside the cluster and watches the Kubernetes API for Ingress objects, dynamically rewriting its nginx.conf every time a rule changes. Other popular options include Traefik (excellent for automatic Let's Encrypt TLS), AWS ALB Ingress (which provisions an Application Load Balancer on AWS natively), and Contour (built on the Envoy proxy for high-performance environments).
When you enable TLS in our generator, it adds a tls: block to the Ingress manifest. The secretName must reference a Kubernetes Secret of type kubernetes.io/tls containing a valid certificate and private key. In practice, cert-manager with a Let's Encrypt ACME solver is the standard way to automate this: cert-manager watches your Ingress resources and automatically provisions and renews free certificates.
For large-scale production deployments, consider AWS ALB Ingress Controller, which maps directly to AWS Application Load Balancers and supports native AWS WAF integration, SSL policies, and target group weighting for blue-green deployments. On GCP, GKE Gateway Controller uses the newer Kubernetes Gateway API (successor to Ingress) for more expressive, role-separated routing configuration.
0404. CPU Millicores & Memory Mebibytes: Requests vs Limits & QoS Classes
Every production-grade Kubernetes Deployment must define both requests and limits for CPU and memory. Missing these values is the most common cause of node instability and Pod eviction in production clusters.
Requests are the minimum amount of resources that Kubernetes guarantees to a container. The scheduler uses requests to determine which Nodes have enough available capacity to place a new Pod. If your Deployment requests 100m CPU and 128Mi memory, K8s will only schedule it on a Node where that much capacity is available.
Limits are the absolute ceiling. If a container attempts to use more CPU than its limit, it is throttled (slowed down). If it attempts to use more memory than its limit, the Linux OOM killer terminates the process and K8s records an OOMKilled exit reason.
Based on whether requests and limits are set — and whether they match — Kubernetes assigns a Quality of Service (QoS) class to each Pod:
Production Warning: CPU is measured in millicores (100m = 0.1 CPU core). Memory is in binary bytes: 128Mi = 128 Mebibytes (134MB). Setting memory limits equal to requests (Guaranteed QoS) prevents your critical Pods from being evicted during node memory pressure events.
0505. Liveness, Readiness & Startup Probes: When to Use Each
Kubernetes relies on probes to understand whether your application is healthy. Three distinct probe types exist, each solving a different operational problem. Omitting them is a frequent production anti-pattern that leads to traffic being routed to broken Pods.
Readiness Probe — "Is this Pod ready to serve traffic?" If the probe fails, Kubernetes removes the Pod's IP address from the Service endpoints. The Pod is not restarted; it just stops receiving requests. This is essential for graceful startup (your app may take 30+ seconds to initialize its database connection pool) and graceful degradation under heavy load.
Liveness Probe — "Is this Pod alive and not deadlocked?" If a container's goroutine pool exhausts or it enters an infinite loop consuming no CPU but unable to serve requests, only the Liveness probe catches this. A failing Liveness probe triggers a container restart, not just traffic removal. Use it conservatively: an overly aggressive Liveness probe will restart healthy Pods during temporary spikes.
Startup Probe — "Has this Pod finished starting up?" This probe is specifically for slow-starting legacy applications. While the Startup probe has not yet passed, Liveness and Readiness probes are disabled, preventing premature restarts during a lengthy initialization phase. Once it passes, K8s hands off to the standard Liveness/Readiness probes.
Our generator creates both Liveness and Readiness probes using the same configuration. The initialDelaySeconds gives your container time to warm up before the first probe fires, and periodSeconds controls how frequently K8s checks afterward.
0606. Horizontal Pod Autoscaling (HPA v2) with CPU & Custom Metrics
The HorizontalPodAutoscaler (HPA) is a Kubernetes controller that automatically adjusts the number of Pods in a Deployment based on observed resource metrics. It runs as a control loop (default 15s) that queries the Metrics Server API, comparing current Pod CPU or memory consumption against your configured target, and then modifies the Deployment's replicas field accordingly.
Our generator produces an autoscaling/v2 HPA manifest. The v2 API (stable since Kubernetes 1.23) supports multiple metric types simultaneously: Resource metrics (CPU/Memory from the Metrics Server), External metrics (from Datadog, Prometheus, or cloud provider APIs), and Object metrics (from specific Kubernetes API objects like an Ingress's request-per-second count).
A critical prerequisite: the HPA controller calculates utilization as a percentage of the container's CPU request. Without a defined CPU request, the HPA cannot function and will report <unknown>/80%. Always pair HPA with resource requests.
The stabilization window (defaulting to 300 seconds for scale-down) prevents rapid flapping: HPA won't immediately scale down after a traffic spike subsides, giving your application time to absorb any trailing requests.
For more advanced autoscaling, Kubernetes KEDA (Kubernetes Event-driven Autoscaling) extends the native HPA with support for 50+ event sources: scale to zero based on an empty RabbitMQ queue, a Kafka consumer lag threshold, a Datadog metric, or an AWS SQS queue depth. KEDA is now a CNCF graduated project and is the industry standard for workload-based autoscaling beyond simple CPU percentages.
0707. SecurityContext: Hardening Pods Against Container Escapes
A container breakout vulnerability (like CVE-2019-5736 in runc) allows a malicious process inside a container to escape to the host Node if the container runs as root. The SecurityContext in Kubernetes allows you to apply Linux kernel-level security policies at both the Pod and Container level, dramatically shrinking your attack surface.
Our generator injects three key security directives when SecurityContext is enabled:
runAsNonRoot: true— The Kubelet validates at Pod admission time that the container image does not run as UID 0 (root). If the image'sUSERinstruction is root or missing, the Pod fails to start with a clear error. This forces a secure-by-default posture at the platform level.allowPrivilegeEscalation: false— Corresponds to theno_new_privsLinux kernel flag. Prevents a child process (like asetuidbinary) from gaining more privileges than its parent process. Essential for preventing privilege escalation inside a compromised container.readOnlyRootFilesystem: true— Mounts the container's root filesystem as read-only. This is an extremely powerful defense: even if an attacker gains code execution, they cannot write malicious payloads, backdoors, or modified binaries to the filesystem. Note: your application must write logs and temp files to explicitly mountedemptyDirvolumes.
0808. Environment Variables vs ConfigMaps vs Secrets
Kubernetes provides three distinct mechanisms for injecting configuration into containers, each with different scope, security, and management trade-offs.
Environment Variables (defined inline in the YAML's env: array) are the simplest approach. They are suitable for non-sensitive, rarely-changing values like feature flags or service URLs. The downside: changing them requires a full Pod restart, and they are plainly visible in the Deployment YAML in your version control history.
ConfigMaps decouple configuration from the container image and the Deployment spec. They store key-value pairs as a first-class Kubernetes object. You can mount a ConfigMap as a volume (each key becomes a file) or inject its keys as environment variables using envFrom: configMapRef. ConfigMaps allow updating configuration without redeploying the entire Deployment, though you may still need to restart Pods to pick up volume-mounted changes depending on your application.
Secrets are structurally identical to ConfigMaps but are base64-encoded (not encrypted by default in etcd, unless you enable Encryption at Rest). Secrets are intended for sensitive data: database passwords, API keys, TLS certificates, and OAuth tokens. The base64 encoding is trivially reversible; the real security benefit of Secrets over ConfigMaps is that Kubernetes RBAC allows you to grant access to Secrets independently of ConfigMaps, and Secret values are not echoed in kubectl describe pod output by default.
0909. PersistentVolumeClaims: Giving Stateless Pods Stateful Storage
Containers are ephemeral: any data written to the container's writable layer is destroyed when the Pod terminates. For applications that must persist data across Pod restarts (like a file processor that queues jobs, or a dev database), you need a PersistentVolumeClaim (PVC).
A PVC is a request for storage from the cluster. The cluster's storage provisioner (like aws-ebs-csi-driver, gce-pd, or local hostPath) dynamically provisions a PersistentVolume (PV) — an actual storage block — and binds it to the PVC. The PV outlives the Pod. When a new Pod starts with the same PVC, it mounts the same persistent storage block.
When our generator creates a PVC, it appends both the standalone PersistentVolumeClaim resource and a volumeMounts + volumes section inside the Deployment's Pod template. The accessMode: ReadWriteOnce (RWO) means the volume can only be mounted by one Node at a time, which is appropriate for most block storage. ReadWriteMany (RWX) allows multiple Pods on different Nodes to mount simultaneously, typically requiring NFS or a CSI driver that supports it.
1010. PodDisruptionBudgets: Maintaining Availability During Node Drains
A PodDisruptionBudget (PDB) protects your application from having too many Pods simultaneously terminated during voluntary disruptions — cluster operations like node drains (kubectl drain), cluster upgrades, or autoscaler scale-down events.
Without a PDB, draining a Node for maintenance could terminate all of your Pods at once if they all happen to run on that Node, causing a complete application outage. With a PDB specifying minAvailable: 1, the drain operation will gracefully move Pods off the Node one at a time, waiting for each new Pod to become Ready before terminating the next, guaranteeing at least one Pod is always serving traffic.
Note that PDBs only protect against voluntary disruptions. Involuntary disruptions (a Node crashing due to hardware failure) will always be able to terminate Pods regardless of PDB settings.
1111. Multi-Document YAML & Applying with kubectl apply
Our generator produces a multi-document YAML stream, where each Kubernetes resource is separated by a line containing exactly --- (the YAML document separator). This allows you to manage a complete application stack — Deployment, Service, Ingress, HPA, ConfigMap, PVC, and PDB — in a single file.
The preferred way to apply this file is kubectl apply -f deployment.yaml, which uses server-side apply semantics. Unlike kubectl create (which fails if a resource already exists), kubectl apply computes a three-way diff between the last-applied configuration, the live object in the cluster, and the new desired state, then patches only the changed fields. This makes it safe to run repeatedly, ideal for CI/CD pipelines.
To verify the rollout after applying, use kubectl rollout status deployment/my-app --timeout=5m, which blocks and reports progress until all Pods in the new ReplicaSet are ready, or exits with an error after the timeout.
1212. Decoding Common Kubernetes Errors
CrashLoopBackOff means a container is crashing immediately after starting, and Kubernetes is backing off exponentially before retrying (10s, 20s, 40s... up to 5 minutes). The actual crash reason is in kubectl logs my-pod --previous. The most common causes when using this generator are: the image doesn't exist (ImagePullBackOff), the container port doesn't match what the application actually listens on, or an incorrect health probe path is causing immediate Liveness probe failures.
OOMKilled (Exit Code 137) means the Linux OOM killer terminated your process because it exceeded its memory limit. The fix is either to increase the limits.memory value in your YAML or to find the memory leak in your application.
Pending (Insufficient CPU/Memory) means no Node in the cluster has enough allocatable resources to satisfy your Pod's requests. Check kubectl describe pod my-pod for the detailed scheduler message. Solutions include adding Nodes to the cluster, reducing resource requests, or removing other workloads.
ImagePullBackOff means Kubernetes cannot pull the container image. Either the image name is misspelled, the tag doesn't exist on the registry, or (for private registries) the ImagePullSecrets reference is missing or incorrect.
1313. How ZeonTools Compares to Other K8s YAML Generators
There are several online Kubernetes YAML generators available, but most share the same critical weaknesses. We analyzed the top 10 tools ranking for "kubernetes yaml generator" to identify every gap and build a superior alternative.
This tool is 100% open to use. Your image names, secret names, env var keys, and all configuration data is processed entirely in your browser's JavaScript engine. It is never sent to our servers, logged, or stored. You can safely generate YAML for production workloads with full confidence.
FAQ14. Frequently Asked Questions
What is the difference between a Pod and a Deployment?
A Pod is the smallest deployable unit in Kubernetes — it wraps one or more containers sharing a network namespace. However, bare Pods have no self-healing: if a Pod crashes, it stays dead. A Deployment is a controller that manages a ReplicaSet of identical Pods. If a Pod crashes, the Deployment controller detects the discrepancy between desired replicas and actual replicas, and immediately schedules a replacement Pod on a healthy Node. Always use Deployments (or StatefulSets for stateful workloads) rather than bare Pods in production.
What does kubectl apply do differently from kubectl create?
kubectl create is imperative — it creates a resource and returns an error if it already exists. kubectl apply is declarative — it performs a three-way merge between the last-applied configuration (stored in the object's kubectl.kubernetes.io/last-applied-configuration annotation), the live object state in the cluster, and your current YAML file. It creates the resource if missing, or patches it if it already exists. This makes kubectl apply idempotent and safe to run repeatedly in CI/CD pipelines.
Why should I always set CPU and Memory resource requests?
Resource requests are used by the Kubernetes scheduler to find a Node with enough allocatable capacity for your Pod. Without requests, the scheduler places Pods arbitrarily, potentially overloading Nodes. More critically, HPA (HorizontalPodAutoscaler) is completely non-functional without CPU requests — it cannot calculate utilization percentages with no baseline. During Node memory pressure, Pods without requests are in the BestEffort QoS class and are the first to be evicted by the kubelet. Always define requests; match them to limits for critical workloads (Guaranteed QoS).
What is the difference between a Liveness probe and a Readiness probe?
A Liveness probe answers: 'Is this container still alive and not deadlocked?' If it fails, Kubernetes restarts the container. Use it for applications that can reach an unrecoverable stuck state (e.g., deadlocked threads). A Readiness probe answers: 'Is this container ready to accept traffic?' If it fails, Kubernetes removes the Pod's IP from the Service endpoint list — no traffic is sent to it, but the container is not restarted. Use it to signal during startup that the app is warming up, or to temporarily pull a Pod out of rotation under heavy load.
What is a Startup Probe and when should I use it?
A Startup probe is specifically designed for slow-starting applications. While the Startup probe has not yet succeeded, both the Liveness and Readiness probes are completely disabled. This prevents premature Liveness probe failures from killing a container during its initialization phase. For example, if your Java application takes 120 seconds to fully load its Spring context, you can set a Startup probe with failureThreshold: 30 and periodSeconds: 10 (giving it up to 300 seconds to start) while keeping Liveness probes aggressive for normal runtime.
How does Horizontal Pod Autoscaling (HPA) work?
HPA is a Kubernetes control loop that periodically (every 15 seconds by default) queries the Metrics Server API for resource utilization across all Pods in a target Deployment. It calculates the desired replica count as: ceil(currentReplicas * (currentMetricValue / desiredMetricValue)). If the ratio exceeds 1.0, HPA scales up. If it drops below 1.0, a stabilization window (default 5 minutes) prevents immediate scale-down to avoid flapping. HPA strictly requires CPU requests to be defined on the container, as utilization is measured as a percentage of the request value.
What is a SecurityContext and why does it matter?
A SecurityContext defines Linux security policies applied to a Pod or individual container. Without it, containers often run as UID 0 (root), meaning a container breakout vulnerability gives an attacker root-level access to the host Node. Key directives: runAsNonRoot: true prevents starting as root; allowPrivilegeEscalation: false maps to the Linux no_new_privs flag, preventing setuid binaries from gaining elevated privileges; readOnlyRootFilesystem: true makes the container filesystem read-only, blocking attackers from writing malicious payloads even after achieving code execution.
When should I use a ConfigMap vs a Secret?
Use a ConfigMap for non-sensitive configuration data: feature flags, service URLs, log levels, connection pool sizes. ConfigMaps are stored in etcd in plaintext and visible to anyone with RBAC access to the namespace. Use a Secret for sensitive credentials: database passwords, API keys, TLS certificates, OAuth tokens. Secrets are base64-encoded (not encrypted by default, though encryption at rest can be enabled). Kubernetes RBAC lets you grant access to Secrets independently from ConfigMaps. Never hardcode sensitive values in your Deployment YAML — always reference a Secret via valueFrom: secretKeyRef.
What does CrashLoopBackOff mean?
CrashLoopBackOff means a container is repeatedly crashing immediately after starting, and Kubernetes is backing off exponentially between restart attempts (10s, 20s, 40s, 80s... up to 5 minutes). It is not an error in itself — it is Kubernetes' description of the symptom. To find the actual error, run kubectl logs <pod-name> --previous to view the logs from the last crashed container. Common causes from our generator: wrong container port, incorrect probe path causing immediate Liveness failures, missing environment variables the app requires, or a bug introduced in the latest image.
What does OOMKilled mean and how do I fix it?
OOMKilled (Out Of Memory Killed) means the Linux kernel's OOM killer terminated your container process because it exceeded its configured Memory Limit. You will see Exit Code 137 in kubectl describe pod. The fix involves two steps: first, use kubectl top pod to observe actual memory consumption under load. Second, either increase the limits.memory value in your YAML to give the application more headroom, or investigate and fix the memory leak in your application code (a common cause in Node.js applications with unbounded caches or in Java apps with insufficiently tuned heap sizes).
What is ClusterIP vs NodePort vs LoadBalancer?
ClusterIP (default) exposes the Service on an internal cluster IP, making it reachable only from within the cluster. Perfect for microservice-to-microservice communication. NodePort opens a specific port (30000–32767) on every Node's external IP, making the Service reachable from outside without a cloud provider. Best for development or bare-metal setups. LoadBalancer automatically provisions a cloud-native external load balancer (AWS NLB, GCP Load Balancer, Azure LB) with a public IP. Best for production internet-facing services on managed cloud Kubernetes (EKS, GKE, AKS).
What is an Ingress Controller and do I need one?
An Ingress resource in Kubernetes is just a set of routing rules — it does nothing by itself. An Ingress Controller is the actual software component (a Deployment running inside the cluster) that reads Ingress rules and configures a proxy accordingly. The most common is NGINX Ingress Controller (kubernetes/ingress-nginx). You need an Ingress Controller if you want to: route HTTP/S traffic to multiple Services using a single external IP (reducing cloud LB costs), configure path-based routing, or terminate TLS with automatic certificate management via cert-manager.
How do I roll back a Kubernetes Deployment?
Every kubectl apply that changes the Pod template creates a new ReplicaSet revision. To instantly roll back to the previous revision: kubectl rollout undo deployment/my-app. To view all revision history: kubectl rollout history deployment/my-app. To roll back to a specific revision: kubectl rollout undo deployment/my-app --to-revision=2. Note: you must set revisionHistoryLimit in your Deployment spec (default: 10) to control how many old ReplicaSets Kubernetes retains for rollbacks.
What is a PersistentVolumeClaim (PVC)?
A PersistentVolumeClaim is a request for persistent storage from the cluster. Unlike a container's writable layer (which is destroyed when the Pod dies), a PVC provisions a storage block that outlives the Pod. When a new Pod restarts with the same PVC, it mounts the exact same data. A PVC specifies: a storage size (1Gi), an access mode (ReadWriteOnce for single-node block storage, ReadWriteMany for NFS-backed shared storage), and optionally a StorageClass. The cluster's CSI driver (EBS, GCE PD, Azure Disk) dynamically provisions the actual disk and binds it to the PVC.
What is a PodDisruptionBudget and why does it matter?
A PodDisruptionBudget (PDB) protects your application from involuntary downtime during voluntary cluster maintenance operations — specifically kubectl drain (used before node upgrades, autoscaler scale-down, or planned maintenance). Without a PDB, a node drain could simultaneously evict all 3 of your Pods if they all happened to land on the same node, causing a complete outage. With minAvailable: 1, the drain operation is forced to wait until a new Pod is Ready on another Node before evicting the next one, ensuring continuous availability throughout the maintenance window.