Services and Networking
This chapter covers the Kubernetes networking model, how Services provide stable access to Pods, how cluster DNS resolves names, and how Ingress and NetworkPolicies control routing and access. Networking issues are among the most common real-world problems, so these concepts matter for both configuration and troubleshooting.
The flat network model
Kubernetes requires that every Pod can reach every other Pod across nodes without NAT, giving each Pod its own IP. A Container Network Interface (CNI) plugin implements this flat network. Until a NetworkPolicy selects a Pod, it accepts traffic from anywhere in the cluster.
Service types and DNS
A ClusterIP Service exposes Pods on an internal virtual IP; NodePort opens a fixed port on every node for external reach; LoadBalancer provisions an external load balancer in supported clouds; and ExternalName maps to a DNS name. Cluster DNS resolves a Service as <service>.<namespace>.svc.cluster.local, and Pods in the same namespace can use the short service name.
Ingress and NetworkPolicy
An Ingress defines Layer 7 HTTP and HTTPS routing rules, such as host- and path-based routing, and is realized by an Ingress controller. A NetworkPolicy restricts which sources may reach selected Pods; once a Pod is selected by an ingress policy it becomes default-deny for ingress, allowing only the sources you list. NetworkPolicies require a CNI plugin that enforces them.