Kubernetes Networking

Pods zijn vluchtig. Hun IP-adressen veranderen bij elke herstart, herscheduling of schaalactie. Een Kubernetes Service geeft een stabiel virtueel IP en een DNS-naam aan een groep pods, zodat clients nooit individuele pod-adressen hoeven bij te houden. Dit artikel legt de vier Service-typen uit, headless Services, hoe kube-proxy verkeer routeert, en wanneer je welk type kiest.

Ingress geeft je HTTP/HTTPS-routing, TLS-terminatie en host-based of path-based verkeersverdeling achter een enkele load balancer. Dit artikel loopt stap voor stap door het opzetten van Ingress: een IngressClass kiezen en installeren, host-based en path-based rules configureren, TLS termineren met cert-manager, en de meest gebruikte ingress-nginx annotations toepassen in productie.

Standaard kan elke pod in een Kubernetes-cluster elke andere pod bereiken op elke poort. Met NetworkPolicy beperk je dat verkeer op IP- en poortniveau, zodat een gecompromitteerde frontend-pod niet rechtstreeks bij je database kan. Dit artikel loopt door het aanmaken van een deny-all baseline, het toestaan van specifieke ingress- en egressflows, namespace-isolatie en het testen of je policies daadwerkelijk werken.

Gateway API is de officiële Kubernetes-opvolger van de Ingress API. Het scheidt infrastructuur van applicatierouting, ondersteunt geavanceerd verkeersmanagement zonder annotations, en is sinds Kubernetes 1.29 GA. Deze tutorial loopt door het resourcemodel, het opzetten van Envoy Gateway, het configureren van HTTPRoutes met path matching en traffic splitting, TLS-terminatie met cert-manager, en het koppelen van het rollenmodel aan je team's RBAC.

cert-manager automatiseert het uitgeven en vernieuwen van TLS-certificaten op Kubernetes via Let's Encrypt. Deze tutorial loopt door elke stap: cert-manager installeren met Helm, ClusterIssuers aanmaken voor staging en productie, HTTP-01 en DNS-01 challenges configureren, certificaten uitgeven voor Ingress en Gateway API resources, en certificaatvervaldatum monitoren met Prometheus.

Een Deployment behandelt elke pod als inwisselbaar. Een StatefulSet doet het tegenovergestelde: het kent elke pod een vaste naam, een vaste hostname en een eigen persistent volume toe. Dat onderscheid maakt het mogelijk om databases, message brokers en consensus-systemen op Kubernetes te draaien. Dit artikel legt uit welke garanties een StatefulSet biedt, wanneer je ze nodig hebt, en wanneer niet.

Kubernetes plant pods standaard op elke beschikbare node. Als je GPU-workloads op GPU-nodes wilt draaien, batchjobs op spot-instances, of tenant-workloads op dedicated hardware, combineer je taints (die pods weren van nodes), tolerations (die specifieke pods toestaan ondanks de taint) en node affinity (die pods naar nodes met de juiste labels trekt). Deze gids behandelt alle drie de mechanismen, topology spread constraints en praktijkpatronen voor productiecluster.

CoreDNS is de DNS-server achter elke service-naar-service-aanroep in een Kubernetes-cluster. Het resolvet cluster-interne namen vanuit een in-memory API-watchcache en forwardt al het andere naar upstream-resolvers. Dit artikel legt uit hoe de Corefile de configuratie aanstuurt, hoe plugins worden uitgevoerd, welke DNS-records Kubernetes-services opleveren, en hoe je CoreDNS tunet voor performance op schaal.

gRPC- en WebSocket-workloads sturen vaak al het verkeer naar een enkele pod, ook al draaien er meerdere replica's. De oorzaak is een mismatch tussen Kubernetes L4 load balancing (dat TCP-verbindingen verdeelt) en protocollen die veel verzoeken multiplexen over een enkele persistente verbinding. Dit artikel legt uit waarom het standaard kube-proxy-gedrag faalt voor deze protocollen, wat het verschil tussen L4 en L7 load balancing in de praktijk betekent, en welke oplossingen er zijn op elk niveau van infrastructuurcomplexiteit.