What Really Happens When You Deploy an App on Kubernetes?

Introduction

After studying Kubernetes for a few months, the author organizes the knowledge into a series of notes. The first note focuses on the question “What happens when we deploy an application?” and provides a high‑level view of the Kubernetes architecture and its core components.

Docker, Virtual Machines, and Containers

Application container engine: packages an application and its dependencies into a portable image that can run on any Linux or Windows host (e.g., Docker, rkt).

Virtual machine (VM): a fully isolated software‑emulated computer with its own kernel (e.g., VMware, VirtualBox).

Docker shares the host kernel, while a VM runs a separate kernel. Containers use Linux cgroups and namespaces for isolation, and their file‑system writes are copy‑on‑write.

Kubernetes Overview – What & Why

Deploying an app with Docker requires two manual steps: building & pushing an image, then pulling and running it on a host. When many services need to be deployed, upgraded, or rolled back, this manual process becomes error‑prone and time‑consuming, which is why Kubernetes exists—to automate and orchestrate these operations.

How Kubernetes Deploys an Application

When a user clicks “redeploy” in a platform such as Aone, the platform calls the Kubernetes API to create a Deployment . The Deployment controller creates a ReplicaSet , which in turn creates one or more Pod objects. The scheduler assigns each Pod to a worker node, where the kubelet instructs Docker to pull the specified image and start the containers.

Control Plane (Master)

Kubernetes API – central communication hub.

Scheduler – decides on which node a Pod should run.

Controller Manager – runs cluster‑level controllers (e.g., ReplicationController, ReplicaSet).

etcd – persistent key‑value store for cluster state.

Worker Nodes

Container runtime (Docker, rkt, etc.).

kubelet – talks to the API server and manages Pods on the node.

kube‑proxy – provides service load‑balancing.

Pods and Labels

A Pod is the smallest deployable unit in Kubernetes; it may contain one or more containers that share the same network namespace and storage. Labels are key‑value pairs attached to Pods (and other resources) that enable selection and grouping, which is essential for controllers and service discovery.

ReplicationController (RC) and ReplicaSet

RC/ReplicaSet ensure that a desired number of Pods (the replicas field) are always running. Their specification includes:

Pod selector – identifies the Pods the controller manages.

Replicas – the target number of Pods.

Pod template – the blueprint for creating new Pods.

Typical scenarios:

Pod failure – the controller creates a replacement Pod.

Label change – the controller reconciles the replica count.

Scaling down – Pods are terminated based on priority (unassigned, Pending, NotReady, oldest Ready, high restart count, newest creation time).

Scaling up – new Pods are created until the replica count is met.

Image upgrade – updating the template triggers new Pods with the new image.

ReplicaSet vs. StatefulSet

ReplicaSet is the successor of RC with richer label selectors. StatefulSet manages stateful Pods that require stable network IDs and persistent storage.

Declarative Deployment

Instead of manual recreate or rolling‑update commands, a Deployment resource expresses the desired state (e.g., image version, replica count). Kubernetes watches the Deployment, creates a new ReplicaSet, and gradually rolls out the change while keeping the previous ReplicaSet for easy rollback.

Rolling‑Update Parameters

maxUnavailable – maximum number (or percentage) of Pods that may be unavailable during an update.

maxSurge – maximum number (or percentage) of extra Pods that may be created above the desired replica count.

Declarative vs. Imperative APIs

Declarative APIs describe the desired end state; the control plane works toward that state, handling failures and retries automatically. Imperative APIs require the client to issue each command and monitor the result, which is more fragile in distributed environments.

Autoscaling

Horizontal Pod Autoscaler (HPA)

HPA watches metrics (CPU, custom metrics, etc.) collected by cAdvisor on each node and aggregated by Heapster. It computes the required number of Pods and updates the Deployment’s replicas field. HPA respects minimum intervals (default 3 min for scaling up, 5 min for scaling down).

Vertical Pod Autoscaler (VPA)

VPA adjusts the requests for CPU and memory of a Pod based on observed usage. It requires a Pod restart, so it is best suited for workloads where occasional restarts are acceptable.

Cluster Autoscaler (CA)

When the total resource demand exceeds the capacity of existing worker nodes, the Cluster Autoscaler can add or remove nodes in the underlying cloud provider, using logic similar to HPA.

Conclusion

The article ends by restating the original question and confirming that the reader now understands the end‑to‑end flow: a manual upgrade request triggers a chain of declarative resources (Deployment → ReplicaSet → Pod) that are reconciled by the control plane, with scheduling, container runtime, and autoscaling all working together to keep the system in the desired state.