Kubernetes Deployments

Requests tell the scheduler how much CPU and memory a pod needs to land on a node. Limits tell the kernel when to throttle or kill. Mixing them up leads to pods stuck in Pending, surprise OOMKills, or throttled latency on nodes with idle capacity. This article explains the mechanics behind both, how Kubernetes assigns QoS classes from them, and how to pick initial values that match your workload.

A well-structured Helm chart saves hours during every upgrade, review, and incident. A poorly structured one creates silent failures that only surface in production. This guide walks through the conventions that make charts portable, testable, and safe to hand to a colleague or a CI pipeline without a README longer than the chart itself.

Kompose converts your Docker Compose file to Kubernetes manifests in one command. The output looks complete, but it is missing resource limits, health probes, and proper secrets handling. This tutorial walks through the full migration path: converting with Kompose, then hardening every manifest until it is production-ready.

A rolling update replaces pods one at a time, but the defaults do not prevent dropped connections. Without the right readiness probe, preStop hook, and terminationGracePeriodSeconds, users see 502s every time you deploy. This guide walks through each setting that matters and ends with a complete, production-ready Deployment manifest.

A bad deploy is on production and you need to revert it. The fastest safe path is `kubectl rollout undo`, but the command does not do quite what most engineers think it does. This guide gives you the one-line rollback, then explains how Deployment revisions actually work, how to roll back to a specific version, how to monitor and preview the action, and how StatefulSet and DaemonSet rollbacks differ from Deployments.

The Horizontal Pod Autoscaler adds or removes pod replicas based on metrics you choose: CPU utilization, memory pressure, request rates from Prometheus, or external signals like queue depth. This guide walks through configuring HPA v2 for each of those scenarios, tuning the stabilization window so scaling is fast up and cautious down, and avoiding the conflict that arises when HPA and VPA target the same resource.

KEDA (Kubernetes Event-Driven Autoscaling) extends the standard HPA with 70+ built-in scalers and scale-to-zero support. Instead of scaling only on CPU and memory, you can scale pods based on Kafka consumer lag, RabbitMQ queue depth, Prometheus query results, or a cron schedule. This tutorial walks through installing KEDA, creating your first ScaledObject, configuring common scalers, and understanding the two-phase scaling model that makes zero-to-many possible.

Kustomize lets you maintain environment-specific Kubernetes manifests (dev, staging, production) by patching a shared base rather than templating it. The base files stay as valid, deployable YAML. This guide walks through the directory layout, patching strategies, generators, components, and integration with ArgoCD and Flux.

Argo CD turns a Git repository into the single source of truth for your cluster state. You commit manifests, Argo CD reconciles them. This tutorial walks through a full GitOps setup: installing Argo CD with Helm, deploying an application via the Application CRD, configuring sync policies, ordering resources with sync waves, bootstrapping a cluster with the app-of-apps pattern, handling secrets safely, and managing multiple clusters from one control plane.

A Kubernetes Job runs one or more pods to completion and then stops. A CronJob does the same thing on a cron schedule. Together they cover database migrations, nightly backups, report generation, and any other task that should run once or on a timer rather than continuously. This guide walks through both resources from a minimal Job through parallelism, failure handling, timezone-aware CronJobs, concurrency control, and cleanup.

A GitHub Actions workflow that builds a container image, pushes it to a registry, and rolls out the new version to a Kubernetes cluster is a three-part problem: build, authenticate, deploy. Each part has a right way and a tempting wrong way. This tutorial walks through a production-grade pipeline: building and tagging images with docker/build-push-action, pushing to GHCR, authenticating to a cluster with short-lived OIDC credentials or a scoped ServiceAccount, and triggering a rollout. It ends with a complete workflow file you can drop into your repository.

Init containers run sequentially to completion before your application container starts. They are Kubernetes's built-in mechanism for dependency checks, database migrations, config fetching, and filesystem preparation. This guide walks through each use case with production-ready manifests, covers failure handling and debugging, and explains when the newer sidecar container pattern is a better fit.

A PodDisruptionBudget tells Kubernetes how many pods of your application can be offline simultaneously during voluntary maintenance. Without one, a single kubectl drain can evict every replica at once. This guide covers choosing between minAvailable and maxUnavailable, handling unhealthy pods, and avoiding the misconfigurations that block cluster upgrades.

Rolling updates handle most stateless services well, but they cannot give you instant rollback or expose a new version to 5% of traffic before the full cutover. Blue-green and canary deployments can. This tutorial walks through both patterns natively with kubectl, then layers Argo Rollouts and Gateway API on top so you can see exactly what each tool buys you.

A pod can hold more than one container, and Kubernetes treats them as a single scheduling unit that shares network and storage. The four patterns that emerged from this design (sidecar, init, ambassador, adapter) each solve a specific problem, and choosing wrongly produces brittle deployments. This article walks through each pattern with manifests, explains how native sidecar containers changed the picture in Kubernetes 1.33, and gives a decision matrix for picking the right one.

A safe node-maintenance procedure for Kubernetes uses two commands: kubectl cordon to stop new pods landing on the node, then kubectl drain to evict the existing ones through the Eviction API. This guide walks through the full cordon-drain-maintain-uncordon flow, the flags every drain needs (--ignore-daemonsets, --delete-emptydir-data, --force, --disable-eviction), and how managed Kubernetes services on AWS, Azure and GCP differ in their drain timeouts.

A Deployment puts pods wherever the scheduler finds room. A DaemonSet does the opposite: it places exactly one pod on every node that matches its selector and tracks the node count automatically. That distinction is what makes log collectors, CNI plugins, and monitoring agents possible. This article explains what a DaemonSet guarantees, when you need one, and the design choices that catch people out in production.

Adding probes to your first Deployment is mostly a series of decisions: which probe types do I need, which mechanism fits my service, and what starter values make sense for my runtime. This guide answers each of those decisions in order, gives you a complete Deployment manifest at the end, and points to a deeper troubleshooting article when something misbehaves.