Kubernetes Architecture: How apps start and traffic reaches them

Imagine you run an online shop. You want three copies of the website so customers can keep shopping if one copy fails. You also want a stable address, such as shop.example.com, even when those copies are replaced.

Kubernetes helps organize this. You describe what you want, and its components keep working toward that state.

There are two stories to understand:

How the shop starts: instructions become running application containers.
How a customer reaches it: a web request travels to one ready application Pod.

Understanding these separately makes the architecture much easier to follow.

1. Start with the big picture

A cluster is a group of machines managed together. A machine in that cluster is a node. Nodes can be virtual machines or physical servers.

Kubernetes has two main parts:

Part	What it does	Shop example
Control plane	Stores the desired state and coordinates changes.	The management office.
Worker nodes	Run application containers.	The places where the shop actually operates.

A small learning cluster can put both roles on one machine. A larger cluster often has several worker nodes and multiple control-plane instances for availability.

Kubernetes cluster
├── Control plane
│   ├── API server: accepts Kubernetes requests
│   ├── etcd: stores cluster state
│   ├── Controllers: keep actual state close to desired state
│   └── Scheduler: chooses nodes for Pods
└── Worker nodes
    ├── kubelet: coordinates work assigned to this node
    ├── Container runtime: starts and stops containers
    ├── Pod networking and Service forwarding
    └── Pods: run the application containers

Some supporting components are installed separately, and the exact layout depends on the cluster. The roles are more important than memorizing a picture of one installation.

Open the architecture map. Lines show component relationships, not the path taken by a customer request.

2. Container, Pod, and Deployment

A container image packages the application and its runtime files. A container is a running instance of that image.

A Pod is the smallest unit Kubernetes schedules. It can contain one container or several closely related containers. Containers in one Pod share networking and can share mounted volumes. They run together on one node.

For our shop, each Pod contains one web-server container. Three copies means three Pods, not three containers placed automatically into one Pod.

A Deployment describes how those Pods should run: the image, number of copies, settings, and other instructions. Its Pod template is the recipe used to create them.

The Deployment manages a ReplicaSet, and the ReplicaSet maintains the requested number of Pods.

Deployment: “Run three shop copies.”
    ↓
ReplicaSet: maintains the requested Pod count
    ↓
Pod A       Pod B       Pod C

Replica means a copy. Kubernetes does not automatically copy a Pod’s temporary files or database contents when it creates another replica.

3. The control plane, one component at a time

API server: the front desk for cluster management

The API server accepts Kubernetes API requests. When you apply a Deployment, your command talks to this component.

It checks identity, permissions, and admission rules, validates the request, and stores accepted changes. Controllers and node agents also communicate through this API.

Think of it as the management office’s front desk: instructions and reports enter through a common place.

The API server is not the public web server for your shop. A customer’s normal shopping request does not travel through it.

etcd: the cluster’s record book

etcd stores Kubernetes cluster state, including object specifications and recorded status.

For example, it holds the Deployment object describing three replicas. The API server reads and writes this state. Other Kubernetes components normally use the API rather than writing directly to etcd.

Think of etcd as the office record book. It records how the shop should operate; it is not the customer database or the place to store uploaded product photos.

Application data needs its own database or storage, with suitable backups.

Controllers: keep checking what is missing

A controller repeatedly compares the desired state with the observed state and takes action to reduce the difference. This repeated check is called a reconciliation loop.

Suppose the ReplicaSet wants three Pods but one has been deleted. It creates a replacement Pod object.

The controller manager runs many of these control loops, including the Deployment and ReplicaSet controllers.

Think of a supervisor checking: “We need three working copies. What action is needed to get there?” Controllers do not run the application containers themselves.

Scheduler: choose where a Pod can run

The scheduler watches Pods that have not yet been assigned to nodes. It finds a suitable node and records that assignment through the API.

It considers requirements such as resource requests, node labels, affinity, taints, and storage constraints.

For example, if a Pod requests more memory than any eligible node can provide, it may remain Pending. An idle-looking CPU does not guarantee a fit because scheduling uses requests rather than only current usage.

The scheduler chooses the location. It does not pull the image or launch the container.

4. What runs on a worker node?

kubelet: the node’s local coordinator

The kubelet is the agent on a node. It watches the work assigned to that node and coordinates container startup, volumes, and health checks. It reports status back through the API.

Think of it as the local supervisor who receives the assignment and makes sure the required processes are running.

Container runtime: run the containers

A container runtime, such as containerd or CRI-O, pulls images and runs containers when requested by the kubelet through the Container Runtime Interface, or CRI.

Think: the kubelet coordinates the job; the runtime performs the container operations.

A running container can still be an unhealthy application. Kubernetes uses probes to learn more:

Startup probe: has the app finished starting?
Readiness probe: should this Pod receive normal Service traffic?
Liveness probe: should this container be restarted?

A readiness failure usually removes the Pod from normal eligible Service traffic. It does not itself restart the container.

Pod network: connect the Pods

A network implementation, commonly using CNI plugins, provides Pod networking. It gives Pods connectivity according to the installed network design.

The application in a Pod can reach other Pods, including those on another node, when routing and network policy allow it.

Think of the Pod network as the roads between shop locations. Kubernetes defines expectations, while the installed network implementation builds the routes.

Service forwarding: reach the right backend

kube-proxy commonly programs forwarding rules for Kubernetes Services. It usually does not handle every packet as a user-space proxy process. Some network implementations provide an alternative, such as eBPF-based Service forwarding.

This forwarding connects a Service address and port to an eligible backend endpoint. It is a different job from the scheduler, which placed the Pod earlier.

5. Watch how the app starts

Use Play to watch the stages in order, or Next to study one at a time. The connecting lines draw as the flow advances. All stages remain readable, and reduced-motion settings show the complete static diagram.

Open the app-startup motion diagram.

For our shop:

You submit a Deployment asking for three replicas.
The API server checks the request and stores accepted state in etcd.
Deployment and ReplicaSet controllers create the required Pod objects through the API.
The scheduler assigns each unassigned Pod to a suitable node.
Each assigned node’s kubelet coordinates volumes, networking, image pulls, and container startup with the relevant components.
The application starts. Readiness determines whether the Pod should receive normal Service traffic.

The arrows in this diagram show the order of actions. They are not direct network links between every adjacent component. The controllers, scheduler, and kubelets use the API server to observe and update state. Storage setup and scheduling can influence each other.

6. How a Service finds the shop Pods

Pods can be replaced, and their IP addresses can change. Customers and other applications need a stable way to find the shop.

A Service gives the application a stable network identity, commonly a cluster-internal IP address and DNS name.

A typical Service uses a selector to match Pod labels. For example, the shop Pods have label app=shop, and the Service selects app=shop.

An EndpointSlice records backend endpoint information, including readiness. Service forwarding uses that information to reach eligible Pods.

Service: shop-service, port 80
       ↓ selector matches app=shop
Ready shop Pod A     Ready shop Pod B     Ready shop Pod C

The Service is a Kubernetes object, not an extra application container sitting between the customer and the shop.

Think of it as the shop’s stable contact number. The staff member answering may change, but the contact number remains useful.

A connection is typically sent to one backend; do not assume every individual HTTP request rotates to a different Pod. Connection reuse, session affinity, and the forwarding implementation affect the distribution.

The common Service types

Type	Simple meaning
ClusterIP	Reach the app through a cluster-internal Service address.
NodePort	Expose a Service on a port on nodes, subject to routing and firewall rules.
LoadBalancer	Ask the installed integration to provide an external load-balancing entry point.

A LoadBalancer Service needs an implementation, such as a cloud integration or an installed load-balancer component. Creating the object alone does not guarantee that a public address appears.

7. How public web traffic reaches the application

For our example, use this design:

shop.example.com resolves to an external entry address.
A load balancer exposes an Ingress controller.
That controller handles HTTPS and matches host/path rules.
The matching route selects shop-service, which represents the shop’s ready Pod backends.

An Ingress stores HTTP routing rules. An Ingress controller is the running software that reads those rules and handles traffic.

Gateway API is another way to describe entry points and routes, using objects such as Gateway and HTTPRoute. It also needs a compatible implementation. You do not need to use both APIs for the same simple route.

Step 1: DNS looks up the address

The browser asks DNS for the IP address of shop.example.com. DNS gives an address to connect to.

DNS is like looking up a shop’s street address. The later HTTP request does not travel through the DNS server. DNS may also be cached, so a fresh lookup is not required for every request.

Step 2: connect to the external entry point

The browser connects to the reachable load-balancer address. That entry point forwards traffic toward the Ingress controller according to the installation’s configuration.

The actual path may include a LoadBalancer Service, a NodePort, or another exposure method. There is no single packet path shared by every Kubernetes cluster.

Step 3: handle HTTPS and match the route

In our design, the Ingress controller handles the browser’s TLS connection. TLS protects the connection, and the certificate helps the browser verify the server’s identity.

The controller checks the requested hostname and path. A rule might say: “Requests for shop.example.com/products go to shop-service on port 80.”

TLS can terminate at a different component in another design, such as an external load balancer or the app itself. Always identify where it ends before troubleshooting certificates or TLS settings.

Step 4: reach an eligible backend Pod

The route refers to the Service. The controller and networking implementation use backend endpoint information to reach a suitable shop Pod.

Some controllers forward directly to endpoint IPs rather than through the Service’s ClusterIP. The Service stage in our diagram is therefore a logical routing relationship, not a guaranteed extra network hop.

Step 5: the application does its work

The container inside the chosen Pod handles the request. It may read a product database, build a response, and return HTML or JSON.

If it needs another in-cluster app, it can use that app’s Service name. For example, the shop might contact inventory-service. CoreDNS commonly provides these internal Service-name lookups.

Step 6: return the response

The response returns along the connection path to the browser, which displays the page. Connection tracking, proxies, and address translation determine the exact return path.

Open the customer-request motion diagram.

The API server, etcd, and scheduler do not forward the customer’s normal web request. They helped set up the system; the application network handles the traffic.

8. The other core concepts you should recognize

Concept	What it means	Shop example
Namespace	A named scope for many Kubernetes resources.	Group the shop’s Deployments, Services, and settings.
Label	A tag attached to an object.	`app=shop` identifies shop Pods.
Selector	A rule for choosing objects by labels.	The Service selects shop Pods.
ConfigMap	Non-confidential application settings.	Log level or web-server configuration.
Secret	Data intended for confidential values.	Database password or TLS private key; access controls still matter.
Volume	Files or storage available to a Pod.	A shared folder or mounted persistent storage.
PVC	A request for persistent storage.	Storage for uploaded product images.
NetworkPolicy	Rules restricting selected Pod traffic, when enforced by the network implementation.	Only the shop app may connect to a database port.
ServiceAccount and RBAC	An identity for workloads and rules controlling Kubernetes API access.	Let a helper read certain API objects without granting administrator access.

A namespace alone does not isolate network traffic. A Secret’s base64 representation is not encryption. A persistent volume is not a substitute for a backup.

These objects solve different problems. A Service gives stable access; it does not preserve files. A Deployment keeps Pods running; it does not guarantee that application data survives replacement.

9. What happens when something fails?

One container crashes

The kubelet can restart the container according to its restart policy. In an ordinary Deployment, containers use Always.

This may happen inside the same Pod. The Pod’s temporary shared volumes can remain across that container restart.

A Pod is deleted

Its ReplicaSet works to restore the desired count by creating a replacement Pod. The scheduler places that new Pod, possibly on another suitable node.

The new Pod has its own identity. An emptyDir starts empty; existing persistent storage must be mounted explicitly.

A worker node fails

Kubernetes detects the missing node health and, after the relevant conditions and timeouts, may replace affected controller-managed Pods elsewhere.

This is not instant. Enough suitable capacity must exist, and storage or network recovery may take time. The system must also stop sending normal traffic to unavailable endpoints as their readiness changes.

The API server is unavailable

Already-running application containers and existing forwarding rules may continue to serve traffic. However, management changes and control loops depending on the API are disrupted, and the system cannot reliably react to new changes.

Control-plane availability and application availability are related, but they are not the same event.

10. A small lab after the concepts

Use a practice cluster. These commands create two NGINX Pods and a Service. They demonstrate Deployment, replicas, labels, Service selection, and Pod replacement. They do not install a public load balancer or Ingress controller.

kubectl create namespace architecture-demo
kubectl create deployment shop --image=nginx --replicas=2 -n architecture-demo
kubectl expose deployment shop --name=shop-service --port=80 --target-port=80 -n architecture-demo
kubectl rollout status deployment/shop -n architecture-demo

Look at what was created:

kubectl get deployment,replicaset,pods,service -n architecture-demo
kubectl get pods -n architecture-demo --show-labels -o wide
kubectl get endpointslices -n architecture-demo -l kubernetes.io/service-name=shop-service

The Deployment has two replicas. The generated Pods have label app=shop, which the Service selects. EndpointSlices show the backends used for the Service.

Test the application using a local tunnel:

kubectl port-forward service/shop-service 8080:80 -n architecture-demo

In a second terminal:

curl http://127.0.0.1:8080

You should see the default NGINX page. This reaches a selected Pod through port-forward; it does not prove the public network path or ClusterIP forwarding works.

To practise Pod replacement, choose one Pod name from the list and delete that Pod:

kubectl delete pod <pod-name> -n architecture-demo
kubectl get pods -n architecture-demo -w

Watch a replacement appear. Stop watching with Ctrl+C. The replacement is evidence of the controller maintaining the desired count; it is not the deleted Pod coming back with the same identity.

Stop the port-forward with Ctrl+C when finished. Remove this lab’s resources if the namespace was created only for the exercise:

kubectl delete namespace architecture-demo

11. Remember the two flows

Starting the app: you describe the desired state, the API accepts it, controllers create Pods, the scheduler chooses nodes, and kubelets coordinate startup with the runtime and supporting components.

Serving the customer: DNS finds the entry address, the configured entry/controller handles the request, routing reaches a ready backend Pod, and the application replies.

Think of the online shop: the office organizes the work; the shop locations serve the customers. Kubernetes needs both, but they have different jobs.