How External HTTP/HTTPS Requests Reach Containers in a Kubernetes Cluster

HTTP Request Flow Overview

The following diagram shows the overall process, which can be summarized in several steps.

1. A user sends an HTTP/HTTPS request from a web, mobile, or PC client.

2. Because the application is usually exposed via a domain name, the request first undergoes DNS resolution to obtain the corresponding public IP address.

3. The public IP address is typically bound to a Load Balancer ; the request then enters this load balancer. • The Load Balancer can be hardware or software and usually has a stable public IP to avoid DNS‑cache‑related outages. • It acts as an important middle layer that accepts external traffic and forwards it internally.

4. The Load Balancer forwards the request to a traffic entry point in the Kubernetes cluster, usually an ingress . • The ingress handles internal routing and can be seen as the cluster’s internal gateway. • The actual traffic forwarding is performed by an ingress‑controller (e.g., Nginx, HAProxy, Traefik, Kong).

5. The ingress forwards the request to a service according to user‑defined routing rules (e.g., based on path or host). • Example routing diagrams are shown below.

6. The service selects the target pod based on its selector (label matching). • The most common service type inside the cluster is ClusterIP . • A service is essentially a configuration that translates to kube‑proxy rules on each node, which manipulate iptables/ipvs to perform the actual forwarding. • A service may map to multiple pod s, but the request is randomly forwarded to one of them.

7. The selected pod finally delivers the request to the appropriate container inside the pod. • A pod can contain multiple containers, but each container must have a unique port; the request is routed to the container matching the destination port.

The above describes a typical end‑to‑end flow of an external HTTP request reaching a container in a Kubernetes pod.

Note that network configurations can vary, so this is not the only possible path. For example:

• In cloud environments you can use a LoadBalancer ‑type service that directly binds a cloud provider’s load balancer, then attach an ingress or other services.

• You can expose a NodePort ‑type service and use node ports with a self‑managed load balancer.

• For very simple services that do not require internal traffic management, you can skip the ingress altogether.

Foundations of Container Technology

Three core Linux kernel features underpin container technology:

• Namespace (Linux kernel namespaces) – provides resource isolation.

• Cgroups – controls resource limits.

• UnionFS – enables layered file systems.

Namespaces isolate resources; each pod gets its own Linux namespace, ensuring isolation. Namespaces include PID, IPC, Network, Mount, Time, etc. The PID namespace gives each pod its own init process, while the Network namespace gives each pod its own network stack.

Since both the node and each pod have separate networks, traffic from the node to a pod travels via veth pairs . The creation of veth pairs , assignment of pod network namespaces, and IP allocation are tasks performed by the CNI (Container Network Interface) plugin.

In summary, the complete process of an external HTTP/HTTPS request reaching a container in a Kubernetes cluster is as described above.

References:

https://kubernetes.io/docs/concepts/services-networking/

https://learnk8s.io/kubernetes-network-packets