How Applications Actually Run on Kubernetes

Most people start learning Kubernetes by creating Pods, Deployments, and Services.

kubectl create deployment nginx --image=nginx

The Pod becomes Running, the Service gets created, and everything appears to work.

But have you ever stopped to ask:

What actually happens behind the scenes when an application runs on Kubernetes?

Understanding this changed the way I think about Kubernetes.

Instead of seeing Deployments, Services, and Pods as individual resources, I started seeing them as components working together to deliver an application to end users.

Let’s walk through the complete journey.

The Traditional Way

Before Kubernetes, deploying an application was relatively simple.

Install a server.
Install the application.
Start the process.
Open a port.
Hope nothing crashes.

If the server failed, the application became unavailable.

If traffic increased, scaling was often manual.

Kubernetes was designed to solve these operational challenges.

The Application Journey

Imagine you’re deploying a simple web application.

A user opens a browser and enters:

https://myapp.com

From that single request, several Kubernetes components begin working together.

Step 1: DNS Resolves the Application

The domain name points to an external load balancer or ingress endpoint.

The user’s request reaches the Kubernetes cluster.

At this point Kubernetes has not yet reached the application itself.

The request has only arrived at the cluster boundary.

Step 2: Ingress Receives the Traffic

The Ingress acts like a smart traffic controller.

It examines:

Hostname
URL path
Routing rules

Example:

apiVersion: networking.k8s.io/v1
kind: Ingress
spec:
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

The Ingress determines where the request should go next.

Step 3: Service Finds the Application

A Service provides a stable endpoint for application Pods.

Instead of communicating directly with Pods, users communicate with Services.

Why?

Because Pods are temporary.

Pods can:

Restart
Move to another node
Be recreated
Receive new IP addresses

Services solve this problem by providing a permanent virtual endpoint.

Example:

kind: Service
spec:
  selector:
    app: web

The Service continuously discovers Pods matching its selector.

Step 4: Service Selects a Pod

Suppose three Pods are running:

web-1
web-2
web-3

The Service automatically load-balances traffic among them.

Request 1 → web-1

Request 2 → web-2

Request 3 → web-3

This happens transparently.

The user never knows which Pod handled the request.

Step 5: Pod Runs the Application

A Pod is the smallest deployable unit in Kubernetes.

Inside the Pod lives the actual application container.

Example:

containers:
- name: web
  image: nginx

This container contains:

Application code
Runtime
Libraries
Dependencies

When the request reaches the Pod, the application processes it and generates a response.

Step 6: Node Provides the Compute

Pods do not run directly on Kubernetes.

They run on Nodes.

A Node is a machine that provides:

CPU
Memory
Storage
Networking

Think of Nodes as apartment buildings.

Pods are the apartments.

Kubernetes decides which apartment building should host each tenant.

Step 7: Kubelet Keeps Everything Running

Every Node runs a component called Kubelet.

The Kubelet continuously checks:

Is the Pod running?
Did the container crash?
Does the Pod match the desired state?

If something goes wrong, Kubernetes attempts to restore the desired state automatically.

This is one of Kubernetes’ most powerful features.

Step 8: Deployment Maintains Desired State

The Deployment acts as the application manager.

Suppose you want three replicas:

replicas: 3

If one Pod crashes:

Current Pods: 2
Desired Pods: 3

The Deployment immediately creates another Pod.

You don’t need to intervene.

Kubernetes continuously works to ensure reality matches your declared configuration.

Why This Architecture Matters

When I first learned Kubernetes, I viewed each resource separately.

Deployment.

Service.

Ingress.

Pod.

Node.

But real understanding came when I saw how they work together.

A user request travels through an entire chain:

User
  ↓
DNS
  ↓
Ingress
  ↓
Service
  ↓
Pod
  ↓
Container
  ↓
Application

Every Kubernetes resource exists to support that journey.

Once you understand the flow, troubleshooting becomes much easier.

Instead of guessing, you can systematically identify where the problem exists.

DNS issue?
Ingress issue?
Service issue?
Pod issue?
Application issue?

The architecture starts making sense.

The Biggest Lesson

The biggest lesson I learned is that Kubernetes is not really about Pods.

It’s about managing the entire lifecycle of applications.

Pods, Deployments, Services, Ingresses, Nodes, and Controllers are simply building blocks working together toward one goal:

Delivering reliable applications to users.

The moment you stop seeing Kubernetes as a collection of YAML files and start seeing it as an application delivery platform, everything begins to click.

And that’s when your Kubernetes journey truly starts.

Final Thoughts

When I began learning Kubernetes, I spent a lot of time memorizing resources and commands.

Pods.

Deployments.

Services.

Ingresses.

But the real breakthrough came when I understood how these components work together to run and deliver applications.

Kubernetes is not just a platform for managing containers — it is a system designed to ensure applications remain available, scalable, and resilient, even when failures occur.

Once you understand the journey of a request from a user’s browser to a running container, Kubernetes becomes far less intimidating and much more logical.

If you’re learning Kubernetes, don’t focus solely on YAML syntax or exam objectives.

Focus on understanding the flow.

Because when you understand how applications actually run on Kubernetes, you’re no longer just deploying workloads — you’re building the foundation for reliable, cloud-native applications.