Cloud Native Networking
Cloud native networking provides connectivity for containerized workloads running on orchestration platforms like Kubernetes. It covers pod-to-pod communication, service discovery, ingress, network policies, and service mesh patterns that replace traditional network appliance approaches.
itCloud native tools and technologies | OpenSkills.info
Intro
Cloud Native Networking
Cloud native systems replace a few long-lived machines with many short-lived workloads. Those workloads move, scale, and restart. Their addresses can change each time. The network must preserve useful connections while the endpoints keep changing.
The easiest mental model is a stack of contracts. Each layer answers a different question:
- Node network: Can the machines reach one another?
- Workload network: Can each workload send and receive traffic?
- Service network: Can clients find a changing group of healthy workloads through a stable name?
- Traffic entry: Can external clients reach the right service?
- Traffic control: Which connections and requests should be allowed?
- Traffic evidence: Can you see what happened when a connection became slow or failed?
Do not treat the stack as one product. A cloud network, a Container Network Interface plugin, a service proxy, a gateway, and a service mesh solve different parts of the path.
Why the network changes in a cloud native system
A traditional server often keeps one address for months. A containerized workload may exist for seconds. An orchestrator creates new replicas, removes old ones, and places replacements on other nodes.
Directly storing workload addresses in application configuration would couple every client to that churn. Service discovery breaks that coupling. A stable service name points clients toward the current backends. Load balancing then selects one suitable backend.
Kubernetes makes this pattern concrete. Each Pod receives a cluster-wide address. A Service provides a stable address or hostname for a changing set of Pods. EndpointSlices record the current backends. A service proxy or equivalent data plane steers traffic toward them.
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
- Per-Pod cluster-wide addresses and direct Pod communication model
- Service, EndpointSlice, service proxy, Gateway, NetworkPolicy, and CNI responsibilities
- Separation between Kubernetes APIs and external implementations
- https://kubernetes.io/docs/concepts/cluster-administration/networking/
Supports
- Container, Pod, Service, and external communication problem categories
- Non-overlapping node, Pod, and Service address ranges
- IPv4, IPv6, dual-stack, CNI, and network-plugin considerations
- https://github.com/containernetworking/cni/blob/main/SPEC.md
Supports
- CNI as the interface between runtimes and plugins
- Configuration, operations, plugin delegation, IPAM, and result types
- https://kubernetes.io/docs/concepts/services-networking/service/
Supports
- Stable Service abstraction for changing workload backends
- Selectors, EndpointSlices, discovery, and headless Services
- https://gateway-api.sigs.k8s.io/docs/introduction/
Supports
- Layer four and layer seven routing focus
- Role-oriented GatewayClass, Gateway, and Route model
- North-south ingress and east-west mesh uses
- https://kubernetes.io/docs/concepts/services-networking/network-policies/
Supports
- Layer three and layer four traffic control
- Plugin enforcement requirement
- Directional isolation and additive allowed traffic
- https://istio.io/latest/docs/overview/what-is-istio/
Supports
- Service mesh traffic management, mutual Transport Layer Security, authorization, and telemetry
- Control-plane programming of proxy-based data planes
- Sidecar and per-node data-plane patterns
- https://istio.io/latest/docs/concepts/observability/
Supports
- Service metrics, distributed traces, and access logs
- Proxy and service evidence for troubleshooting communication
- https://spiffe.io/docs/latest/spiffe-about/overview/
Supports
- Workload identity independent of dynamic placement
- Short-lived verifiable identity documents and mutual authentication
- https://docs.cilium.io/en/stable/overview/intro/
Supports
- Overlay encapsulation and native-routing deployment patterns
- eBPF-based networking, policy, and visibility as one implementation
- https://docs.cilium.io/en/stable/network/concepts/routing/
Supports
- Underlay requirements for encapsulation and native routing
- Maximum transmission unit overhead from encapsulation
- Route, address, and cloud network-interface tradeoffs
- https://docs.cilium.io/en/stable/network/ebpf/intro/
Supports
- Linux BPF hooks used to construct forwarding, filtering, and policy behavior