Effective networking is fundamental to running applications reliably on Kubernetes. The highly dynamic nature of Pods, which are frequently created and destroyed with ephemeral IP addresses, presents a challenge for communication. Kubernetes addresses this through several core components designed to ensure stable connectivity and service discovery, both within the cluster and from external clients.
A primary abstraction for achieving stable internal communication is the Service. A Service provides a persistent IP address and DNS name for a logical set of Pods. It acts as a stable front-end for a potentially changing group of back-end Pods, effectively load balancing traffic across the healthy instances. Different types of Services cater to various use cases:
- ClusterIP: Exposes the Service on a cluster-internal IP. This type is ideal for communication between Pods within the cluster.
- NodePort: Exposes the Service on each Node’s IP at a static port. This makes the Service accessible from outside the cluster, but it’s generally less suitable for production use due to the fixed, often high, port number.
- LoadBalancer: Exposes the Service externally using a cloud provider’s load balancer. This is a common way to get external traffic into a Kubernetes cluster, provisioning a dedicated external IP.
- ExternalName: Maps a Service to a DNS name outside the cluster, providing a simple way to reference external services.
Crucially, Kubernetes includes its own DNS system. This DNS service allows Pods to discover other Services by their names rather than requiring them to know potentially changing IP addresses. For example, a Pod can reliably connect to a “database” Service by using its DNS name, like database.mynamespace.svc.cluster.local, without needing to track which specific Pods are currently running the database or their IPs. This service discovery mechanism is vital for building loosely coupled microservices within the cluster.
While Services like NodePort and LoadBalancer enable external access, they have limitations, especially for complex web applications needing features like name-based virtual hosts or SSL termination. This is where Ingress comes in. Ingress manages external access to services within the cluster, typically HTTP and HTTPS traffic. It provides routing based on hostnames and paths, allows for SSL termination, and offers more advanced configuration options compared to simple Service types. Ingress resources require an Ingress Controller (like Nginx, HAProxy, Traefik, etc.) running within the cluster to actually implement the rules defined in the Ingress object. The Ingress Controller watches the Ingress resource and configures itself to route external traffic to the correct back-end Services.
In summary, Kubernetes networking relies on the synergy between Services for stable internal endpoints and load balancing, DNS for reliable service discovery via names, and Ingress (along with an Ingress Controller) for flexible and powerful external access management. Understanding these components is essential for deploying and managing connected applications effectively in a Kubernetes environment.
Source: https://www.linuxtechi.com/kubernetes-networking-services-ingress-dns/
