Kubernetes Deployments

Requests vertellen de scheduler hoeveel CPU en geheugen een pod nodig heeft om op een node te landen. Limits vertellen de kernel wanneer hij moet throttlen of killen. Door ze door elkaar te halen krijg je pods die in Pending blijven hangen, onverwachte OOMKills, of latency op nodes die amper belast zijn. Dit artikel legt de mechanica achter beide uit, hoe Kubernetes er QoS-klassen aan toewijst, en hoe je startwaarden kiest die bij je workload passen.

Een goed opgebouwde Helm-chart bespaart je uren bij elke upgrade, review en incident. Een slecht opgebouwde levert stille fouten op die pas in productie zichtbaar worden. Deze gids loopt door de conventies die charts draagbaar, testbaar en veilig genoeg maken om aan een collega of CI-pipeline te overhandigen zonder een README die langer is dan de chart zelf.

Kompose zet je Docker Compose-bestand in één commando om naar Kubernetes-manifesten. De output ziet er compleet uit, maar mist resource limits, health probes en fatsoenlijke secrets-afhandeling. Deze tutorial doorloopt het volledige migratiepad: conversie met Kompose, en daarna elk manifest hardenen tot het productiewaardig is.

Een rolling update vervangt pods een voor een, maar de standaardinstellingen voorkomen geen verbroken verbindingen. Zonder de juiste readiness probe, preStop hook en terminationGracePeriodSeconds krijgen gebruikers 502-fouten bij elke deploy. Deze gids loopt elke relevante instelling door en eindigt met een compleet, productieklaar Deployment-manifest.

Een slechte deploy staat op productie en je moet terug. De snelste veilige route is `kubectl rollout undo`, maar het commando doet niet helemaal wat de meeste engineers denken. Deze gids geeft je eerst de eenregelige rollback en legt daarna uit hoe Deployment-revisies werkelijk werken, hoe je terugrolt naar een specifieke versie, hoe je de actie monitort en preview, en waarin StatefulSet- en DaemonSet-rollbacks afwijken van Deployments.

De Horizontal Pod Autoscaler voegt replicas toe of verwijdert ze op basis van metrics naar keuze: CPU-gebruik, geheugendruk, request rates uit Prometheus, of externe signalen zoals queue depth. Deze guide loopt door het configureren van HPA v2 voor elk van die scenario's, het tunen van het stabilisatievenster zodat opschalen snel gaat en afschalen voorzichtig, en het vermijden van het conflict dat ontstaat wanneer HPA en VPA dezelfde resource aansturen.

KEDA (Kubernetes Event-Driven Autoscaling) breidt de standaard HPA uit met meer dan 70 ingebouwde scalers en scale-to-zero-ondersteuning. In plaats van alleen op CPU en geheugen te schalen, kun je pods laten schalen op Kafka consumer lag, RabbitMQ queue depth, Prometheus-queryresultaten of een cron-schema. Deze tutorial loopt door het installeren van KEDA, het aanmaken van je eerste ScaledObject, het configureren van veelgebruikte scalers, en het begrijpen van het tweefasen-scalingmodel dat zero-to-many mogelijk maakt.

Kustomize laat je omgevingsspecifieke Kubernetes-manifests (dev, staging, productie) beheren door een gedeelde base te patchen in plaats van te templaten. De base-bestanden blijven geldige, deploybare YAML. Deze gids doorloopt de mappenstructuur, patchstrategieën, generators, components en integratie met ArgoCD en Flux.

Argo CD maakt van een Git-repository de enige bron van waarheid voor je clusterstatus. Je commit manifests, Argo CD reconcilieert ze. Deze tutorial loopt door een complete GitOps-opzet: Argo CD installeren met Helm, een applicatie deployen via de Application CRD, sync policies configureren, resources ordenen met sync waves, een cluster bootstrappen met het app-of-apps pattern, secrets veilig afhandelen, en meerdere clusters beheren vanuit een enkel controlplane.

Een Kubernetes Job draait een of meer pods tot ze klaar zijn en stopt dan. Een CronJob doet hetzelfde, maar dan op een cron-schema. Samen dekken ze databasemigraties, nachtelijke backups, rapportgeneratie en elk ander werk dat eenmalig of op een timer moet draaien in plaats van continu. Deze gids loopt door beide resources heen: van een minimale Job via parallelisme en failure handling tot timezone-aware CronJobs met concurrency control en automatische opruiming.

Een GitHub Actions-workflow die een container image bouwt, naar een registry pusht en de nieuwe versie uitrolt naar een Kubernetes-cluster is een probleem van drie delen: bouwen, authenticeren, deployen. Elk deel heeft een juiste aanpak en een verleidelijke verkeerde. Deze tutorial loopt door een productiewaardige pipeline: images bouwen en taggen met docker/build-push-action, pushen naar GHCR, kubectl authenticeren via kortlevende OIDC-credentials of een scoped ServiceAccount, en een rollout triggeren. Aan het einde staat een compleet workflow-bestand dat je zo in je repository kunt plakken.

Init containers draaien sequentieel tot voltooiing voordat je applicatiecontainer start. Ze zijn het ingebouwde Kubernetes-mechanisme voor dependency checks, databasemigraties, config ophalen en filesysteem-voorbereiding. Deze gids loopt door elke use case met productiewaardige manifesten, behandelt failure handling en debugging, en legt uit wanneer het nieuwere sidecar-containerpatroon beter past.

Een PodDisruptionBudget vertelt Kubernetes hoeveel pods van je applicatie tegelijk offline mogen zijn bij gepland onderhoud. Zonder PDB kan een enkele kubectl drain al je replica's in een keer verwijderen. Deze gids behandelt de keuze tussen minAvailable en maxUnavailable, het omgaan met unhealthy pods, en de veelgemaakte fouten die clusterupgrades blokkeren.

Rolling updates dekken de meeste stateless services prima af, maar geven je geen instant rollback en geen mogelijkheid om een nieuwe versie aan 5% van het verkeer te tonen voor de volledige cutover. Blue-green en canary deployments wel. Deze tutorial loopt beide patronen door, eerst native met kubectl, daarna met Argo Rollouts en Gateway API erbovenop, zodat je precies ziet wat elk extra stuk gereedschap je oplevert.

Een pod kan meer dan een container bevatten, en Kubernetes behandelt ze als een enkele scheduling-eenheid die netwerk en storage deelt. De vier patronen die uit dit ontwerp zijn ontstaan (sidecar, init, ambassador, adapter) lossen elk een specifiek probleem op, en de verkeerde keuze levert brittle deployments op. Dit artikel loopt door elk patroon met manifesten, legt uit hoe native sidecar containers het beeld veranderden in Kubernetes 1.33, en geeft een beslismatrix om het juiste patroon te kiezen.

Veilig onderhoud op een Kubernetes-node loopt via twee commando's: kubectl cordon zorgt dat er geen nieuwe pods meer landen, en kubectl drain verwijdert de bestaande pods netjes via de Eviction API. Deze gids loopt door de volledige cordon-drain-onderhoud-uncordon flow, de flags die elke drain nodig heeft (--ignore-daemonsets, --delete-emptydir-data, --force, --disable-eviction), en hoe managed Kubernetes op AWS, Azure en GCP verschillen in drain-timeouts.

Een Deployment plaatst pods waar de scheduler ruimte vindt. Een DaemonSet doet juist het omgekeerde: precies één pod op elke node die aan de selector voldoet, en het aantal volgt automatisch de nodes. Dat is wat logcollectors, CNI-plugins en monitoring-agents mogelijk maakt. Dit artikel legt uit wat een DaemonSet garandeert, wanneer je er een nodig hebt, en welke ontwerpkeuzes mensen in productie verrassen.

Probes toevoegen aan je eerste Deployment is vooral een reeks beslissingen: welke probetypen heb ik nodig, welk mechanisme past bij mijn service, en welke startwaarden kloppen voor mijn runtime. Deze gids beantwoordt elke beslissing op volgorde, geeft je aan het eind een compleet Deployment-manifest, en wijst naar een dieper troubleshooting-artikel als er iets misgaat.