Kubernetes Networking
Kubernetes networking provides pod-to-pod connectivity, service discovery, load balancing, and ingress routing within and across clusters. Every pod gets its own IP, services provide stable endpoints, and network policies control which workloads can communicate.
itCloud native tools and technologies | OpenSkills.info
Recommended first:kubernetes-fundamentals
Intro
Kubernetes Networking
Kubernetes networking answers four questions that every distributed application eventually asks: how do containers in the same Pod talk to each other, how do Pods talk to Pods, how does traffic reach a changing set of Pods reliably, and how does the outside world get in. The platform answers them with a deliberately simple model and a small set of APIs — Services, DNS, Ingress/Gateway, and NetworkPolicy — that hide an enormous amount of moving machinery.
The mental model: every Pod is a small host with its own IP on one flat network. From there, everything else is naming and routing on top — stable virtual names for unstable Pod sets, and controlled doors between the cluster and the world.
The network model
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://kubernetes.io/docs/concepts/services-networking/
Supports
- Network model — per-Pod cluster-wide IPs, shared namespace within a Pod, localhost between containers
- All-Pods-to-all-Pods communication without NAT; node agents reach node-local Pods
- Service API purpose; automatically managed EndpointSlices; service proxy programming the data plane
- Gateway API and Ingress for external traffic; NetworkPolicy for segmentation; cluster DNS
- https://kubernetes.io/docs/concepts/services-networking/service/
Supports
- Service selectors, virtual IPs, port vs targetPort vs nodePort
- Service types — ClusterIP, NodePort, LoadBalancer, ExternalName; headless Services
- Selector-less Services with manual endpoints
- externalTrafficPolicy behavior
- https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/
Supports
- EndpointSlice objects tracking current Service backends
- https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
Supports
- Service DNS naming scheme <svc>.<ns>.svc.<cluster-domain>; cluster.local default
- Headless Service and StatefulSet per-Pod DNS records; SRV records
- https://kubernetes.io/docs/concepts/services-networking/ingress/
Supports
- Host/path-based routing, TLS termination, ingressClassName, default backend
- Ingress requires an ingress controller to take effect
- Ingress API frozen with new features added to Gateway API
- https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/
Supports
- Ingress controllers must be deployed separately; multiple controllers and classes
- https://kubernetes.io/docs/concepts/services-networking/gateway/
Supports
- Role-oriented design — GatewayClass, Gateway, Routes and their intended owners
- Gateway API as expressive, portable successor for L4/L7 routing
- https://kubernetes.io/docs/concepts/services-networking/network-policies/
Supports
- Policy scope and rule types — podSelector, namespaceSelector, ipBlock, ports
- Isolation semantics — non-isolated until selected; additive allow-lists; per-direction
- Enforcement by the network plugin; unsupported plugins do not enforce
- Absence of deny logging and L7 rules in the core API
- https://kubernetes.io/docs/concepts/cluster-administration/addons/
Supports
- Network plugins (CNI) as installable addons implementing the network model