Kubernetes Networking

A container is an isolated Linux process. If it binds to a port, it needs a network interface to receive traffic.

Kubernetes groups containers into Pods. They share a single network namespace so they can communicate over localhost.

To talk to other Pods, the Pod needs its own IP address that the rest of the cluster can route to.

The Container Network Interface (CNI) plugin is responsible for connecting the Pod namespace to the node's network.

Once wired, the Pod has a full network identity and can participate in cluster traffic.

Kubelet requests a new Pod sandbox through the Container Runtime Interface (CRI).

The container runtime creates the sandbox and, in this Linux example, its network namespace.

The runtime invokes the configured CNI plugin chain with an ADD request.

This example's IPAM implementation reserves 10.244.1.15 from its configured pool.

The plugin creates the veth attachment and configures the Pod-side interface and routes.

Kubelet requests the sandbox creation as usual.

The network namespace is created and waiting.

The CNI ADD command fires to wire up the network.

The local IPAM range is exhausted, so no IP is available and the process fails.

Kubelet attempts to set up the sandbox.

The runtime reads its configuration to find the CNI plugin.

It searches the configured binary path, usually /opt/cni/bin.

The required binary is not found, leaving the Pod without a network attachment.

The Pod sends a packet to a peer address on the same Node.

The packet crosses the Pod-side interface and host-side veth peer.

In this example, cni0 looks up the destination MAC address in its forwarding database.

The bridge sends the frame through the peer connected to Pod B.

Pod B receives the packet without an underlay hop.

The source Pod sends the packet through its interface.

An eBPF program attached at a kernel hook observes it.

The implementation redirects the packet toward the local destination without using a Linux bridge.

The target Pod receives the packet; the exact hooks and route processing remain implementation-specific.

The Pod declares hostNetwork and shares the Node network namespace.

It uses Node interfaces and addresses rather than an ordinary Pod veth attachment.

Its processes share the Node port space and can conflict with host or other host-network processes.

ClusterFirstWithHostNet is available when the Pod should use cluster-first DNS behavior.

The Pod originates a packet to a destination on another node.

The host routing table knows that the destination Pod CIDR is reachable via Node B.

The packet is forwarded at layer 3 without any encapsulation.

Node B receives it and routes it locally to the target veth interface.

The target Pod receives the unencapsulated packet.

The Pod originates the inner packet.

The flannel/vxlan interface encapsulates it in a UDP VXLAN header.

The outer packet uses the node IPs to cross the underlay network.

Node B receives the UDP packet and decapsulates the inner payload.

The target Pod receives the original inner packet.

The network implementation allocates a Pod address from the VPC subnet.

The cloud fabric routes that address without a VXLAN overlay.

By default in this AWS VPC CNI example, Pods share security groups associated with the Node ENIs; per-Pod groups require a separate feature.

Subnet addresses, ENI capacity, prefix delegation, and optional branch interfaces constrain density differently.

The client Pod initiates a connection to a virtual ClusterIP.

The PREROUTING chain matches the traffic against the KUBE-SERVICES rules.

A probability rule selects a specific backend (KUBE-SEP) for load balancing.

The kernel rewrites the destination IP and port to the actual Pod.

The target Pod receives the traffic.

The client initiates a connection to the ClusterIP.

The traffic matches the KUBE-SERVICES chain.

No backend rules exist because the Service has no ready endpoints.

The connection is explicitly rejected or dropped by the node.

A backend Pod dies, and kube-proxy updates iptables to remove it.

An existing TCP connection sends another packet.

The connection tracking (conntrack) table remembers the old destination.

The packet routes to the dead IP and times out.

The application queries a short name with fewer dots than the ndots threshold.

The resolver appends the first search suffix.

CoreDNS matches the full internal name.

The query succeeds in a single round trip.

The application gives its resolver an external-looking name that is below the example ndots threshold.

The resolver can try one or more search-expanded names according to its search list.

Negative answers cause the resolver to continue according to its own algorithm.

The resolver eventually asks for the absolute name; the exact sequence and count are not fixed by Kubernetes.

The Service is configured as headless with clusterIP: None.

CoreDNS returns the individual Pod IPs directly.

The client receives multiple A records.

The client selects one and connects directly without kube-proxy DNAT.

In this common NodePort path, an external connection lands on Node A.

Node A source-NATs traffic that it forwards to another Node.

The translated connection reaches a backend Pod on Node B.

The backend observes Node A as the transport source; provider and proxy implementations can differ.

An external connection lands on a Node with a local endpoint.

Local policy keeps this Service hop on the receiving Node.

The common kube-proxy path can avoid source NAT here.

The backend can observe the client source when the surrounding load balancer also preserves it.

A layer 7 proxy terminates the client connection.

A trusted proxy can add the original client address to Forwarded or X-Forwarded-For.

The separate upstream connection has the proxy as its transport source.

The application must trust only headers supplied by known proxies and parse them correctly.

A controller accepts the GatewayClass.

The Gateway listener reports Accepted and Programmed for the current generation.

The HTTPRoute reports Accepted for the intended parent and listener.

ResolvedRefs confirms that the backend reference exists and is permitted.

An end-to-end request confirms that the programmed data plane is actually reachable.

The HTTPRoute is in the app-team namespace.

The Gateway is in the infra namespace.

The Gateway only allows routes from its own namespace.

The route is rejected for crossing namespace boundaries.

The HTTPRoute is in Namespace A.

It points to a Service in Namespace B.

Namespace B has no ReferenceGrant allowing this.

The reference is rejected as insecure.

The client initiates a TLS connection.

The Gateway terminates that connection using the listener certificate.

It can inspect HTTP attributes and choose a route.

The upstream hop uses whatever backend transport the implementation and policy configure; it is a separate security boundary.

The client initiates a TLS connection.

The Gateway reads only the SNI hostname from the unencrypted handshake.

It forwards the encrypted TCP stream unmodified.

The backend Pod holds the certificate and terminates the TLS.

The client initiates TLS to the Gateway.

The Gateway terminates that connection and inspects the HTTP request.

It starts a distinct TLS connection and validates the configured backend identity.

The backend terminates the upstream connection using its own certificate.

A NetworkPolicy drops all egress traffic.

The DNS query on port 53 is blocked.

Name resolution completely fails.

The application fails because it can't resolve endpoints.

An egress rule explicitly allows DNS.

Name resolution now succeeds.

But traffic to the resolved IPs is still blocked by default.

Connections time out during establishment.

The policy allows DNS.

The policy also explicitly allows the API dependency.

Traffic flows to the existing service.

New dependencies will fail until the policy is updated again.

A Pod sends a packet using its Pod source address.

This implementation evaluates NetworkPolicy before a later translation point.

A subsequent hop may still rewrite the address.

The CIDR rule therefore matched the original source in this particular path.

An external client begins with its own source address.

An entry proxy or Node rewrites the source before the enforcement point.

The policy evaluates the address it observes at that point.

A rule written for the original client range does not match.

The policy first narrows callers to namespaces with the intended label.

A Pod selector in the same peer entry further narrows that set.

The policy expresses an in-cluster workload relationship rather than a transient Pod address.

Matching workloads are allowed without relying on an external CIDR rule.

The Pod phase is Running because at least one container remains active.

No process is listening on the expected application socket.

A suitable readiness check becomes false.

EndpointSlice and Service-proxy consumers converge on making that backend ineligible.

A direct connection helps separate listener failure from Service and DNS state.

The Service defines port 80 for clients.

It rewrites the destination to targetPort 8080.

The container process actually listens on 3000.

The connection is refused because nothing listens on 8080.

Node A has a local backend Pod.

Node A's NodePort works properly.

Node B has no local backend Pods.

Node B's NodePort fails because the Local policy prevents cross-node forwarding.

The vxlan/flannel interface is missing or down.

Same-node traffic still works via bridge forwarding.

Cross-node traffic is dropped before entering the tunnel.

Connections time out.

The routing table lacks an entry for the remote Pod CIDR.

Packets are sent to the default gateway.

The underlay network drops them as unroutable.

Connections time out.

UDP port 4789 is used for VXLAN encapsulation.

A cloud security group blocks this port between nodes.

Same-node traffic works fine.

Cross-node traffic times out because tunnels are blocked.

The iptables Service rules match the configured frontend.

Traffic enters the chain generated for that Service and port.

A statistic rule chooses one endpoint for the new connection.

The endpoint chain applies destination NAT.

Postrouting applies masquerading only when the path requires it.

The Service is deleted and its chains are removed.

New connections fail immediately.

Conntrack keeps existing flows active.

Traffic temporarily continues until the flow times out.

Thousands of Services create tens of thousands of rules.

kube-proxy takes longer to sync changes.

Latency spikes occur during mass updates.