Kubernetes Networking

Pods come and go. Their IP addresses change on every restart, reschedule, or scaling event. A Kubernetes Service gives a stable virtual IP and DNS name to a set of pods so that clients never need to track individual pod addresses. This article explains the four Service types, headless Services, how kube-proxy actually routes traffic, and how to choose the right type for your workload.

Ingress gives you HTTP/HTTPS routing, TLS termination, and host-based or path-based traffic distribution behind a single load balancer. This article walks through setting up Ingress from scratch: choosing and installing an IngressClass, configuring host-based and path-based rules, terminating TLS with cert-manager, and applying the most common ingress-nginx annotations for production use.

By default every pod in a Kubernetes cluster can reach every other pod on any port. NetworkPolicy lets you restrict that traffic at the IP and port level, so a compromised frontend pod cannot talk directly to your database. This guide walks through creating deny-all baselines, allowing specific ingress and egress flows, isolating namespaces, and testing that your policies actually work.

Gateway API is the official Kubernetes successor to the Ingress API. It separates infrastructure from application routing, supports advanced traffic management out of the box, and has been GA since Kubernetes 1.29. This tutorial walks you through the resource model, setting up Envoy Gateway, configuring HTTPRoutes with path matching and traffic splitting, terminating TLS with cert-manager, and mapping the role-based model to your team's RBAC.

cert-manager automates TLS certificate issuance and renewal on Kubernetes using Let's Encrypt. This tutorial walks through every step: installing cert-manager via Helm, creating ClusterIssuers for staging and production, configuring HTTP-01 and DNS-01 challenges, issuing certificates for Ingress and Gateway API resources, and monitoring certificate expiry with Prometheus.

A Deployment treats every pod as interchangeable. A StatefulSet does the opposite: it assigns each pod a stable name, a stable hostname, and its own persistent volume. That distinction is what makes it possible to run databases, message brokers, and consensus-based systems on Kubernetes. This article explains the guarantees a StatefulSet provides, when you need them, and when you do not.

Kubernetes schedules pods to any available node by default. When you need GPU workloads on GPU nodes only, batch jobs on spot instances, or tenant workloads on dedicated hardware, you combine taints (which repel pods from nodes), tolerations (which let specific pods override that repulsion), and node affinity (which attracts pods toward nodes with matching labels). This guide covers all three mechanisms, topology spread constraints, and practical patterns for production clusters.

CoreDNS is the DNS server behind every service-to-service call in a Kubernetes cluster. It resolves cluster-internal names from an in-memory API watch cache and forwards everything else to upstream resolvers. This article explains how the Corefile drives configuration, how plugins execute, what DNS records Kubernetes services produce, and how to tune CoreDNS for performance at scale.

gRPC and WebSocket workloads often pin all traffic to a single pod despite having multiple replicas. The cause is a mismatch between Kubernetes L4 load balancing (which distributes TCP connections) and protocols that multiplex many requests over one persistent connection. This article explains why default kube-proxy behavior fails for these protocols, what the difference between L4 and L7 load balancing means in practice, and which solutions exist at each level of infrastructure complexity.