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.

The node network and workload network

The node network, sometimes called the underlay, connects the machines that run workloads. It may be a cloud virtual network, a data-center fabric, or another routed network.

The workload network connects the workloads on those machines. Some implementations route workload addresses directly through the node network. Others create an overlay. An overlay encapsulates workload traffic inside packets that the node network can carry.

Neither choice is automatically better. Direct routing can reduce encapsulation overhead. An overlay can work without teaching the surrounding network every workload route. Your address plan, maximum transmission unit, cloud limits, and operations model should drive the choice.

On Linux, container runtimes commonly use the Container Network Interface, or CNI. CNI specifies how a runtime invokes plugins to apply network configuration. CNI is an interface, not the network itself. A plugin may create interfaces, assign addresses, install routes, and perform related cleanup.

Address assignment is often called IP address management, or IPAM. Plan non-overlapping ranges for nodes, workloads, and Services. Overlap can produce ambiguous routes that look like random connection failures.

Stable services over unstable workloads

Applications should normally connect to service names, not workload addresses. The name is the stable contract. The current endpoints are implementation detail.

This separation has three parts:

Discovery maps a service name to a reachable service address or endpoints.
Endpoint tracking records which workload instances currently back the service.
Load balancing chooses a backend and forwards traffic.

A headless Kubernetes Service skips the virtual service address and publishes backend addresses through DNS. That pattern helps clients that perform their own discovery or load balancing. It also exposes more endpoint churn to those clients.

North-south and east-west traffic

North-south traffic crosses a platform boundary. An external client might enter through a cloud load balancer and then a gateway. The gateway can terminate Transport Layer Security, match a hostname or path, and route the request to a Service.

Gateway API models this work with separate resources for infrastructure, listeners, and routes. That role-oriented split lets platform operators manage shared entry points while application teams manage their own routes.

East-west traffic moves between services. Basic service discovery and load balancing may be enough. A service mesh adds application-aware traffic management through a managed data plane. Depending on the implementation, it can provide mutual Transport Layer Security, request routing, retries, authorization, metrics, traces, and access logs.

A mesh adds cost as well as capability. It introduces more components, configuration, resource use, and failure modes. Add one when you have a clear cross-service requirement that simpler network and gateway controls do not meet.

Policy and identity

Reachability is not authorization. A packet arriving at a destination only proves that the network found a path.

Kubernetes NetworkPolicy controls traffic at the IP address and port layers. Policies select Pods and add allowed ingress or egress paths. Enforcement belongs to the network plugin. A policy object has no effect when no compatible controller implements it.

Address-based policy also has a limit. Workloads move, and addresses are reused. Workload identity gives software a cryptographically verifiable identity that is independent of its current address. SPIFFE defines standards for issuing short-lived identity documents to workloads. A mesh or application can use such identity in authentication decisions.

Use both ideas where needed. Network policy reduces reachable paths. Workload identity helps a destination decide who is connecting.

Data plane, control plane, and evidence

The data plane handles live traffic. It includes kernel routing, packet filters, proxies, and load balancers. The control plane watches desired state and programs the data plane.

This split explains a common failure pattern. The configuration object may look correct while the data plane has not received or accepted the expected state. Debug both planes.

Data planes can use several mechanisms. Linux routing, packet filtering, virtual interfaces, proxies, and eBPF programs can all participate. eBPF is one programmable kernel mechanism, not a synonym for cloud native networking.

Observability must follow the same layers as traffic. Collect evidence from DNS, endpoints, gateways, policies, proxies, and the node network. Metrics show rates and trends. Logs show discrete events. Traces connect work across services. Packet captures show what crossed an interface. No single signal explains every failure.

A practical decision order

Start with the smallest complete system:

Make node and workload routing correct.
Add stable service discovery and load balancing.
Expose only the traffic that must cross the platform boundary.
Apply network policy and verify enforcement.
Add workload identity when address-based trust is insufficient.
Add a service mesh only for explicit cross-service needs.
Instrument every layer you depend on.

This order keeps each new component tied to a known requirement. It also gives you a clear boundary to inspect when traffic fails.

Limits of this course

This course gives you a broad map. It does not replace implementation documentation for a specific cloud, CNI plugin, gateway controller, or mesh. It also does not cover advanced routing protocols, network function virtualization, or vendor-specific performance tuning.

Use the linked official material to study each contract in depth. Test important behavior in a non-production environment before you trust it in production.