Imagine arriving at a large international airport.

Regardless of whether you’re a passenger, an airline employee, airport staff, or a delivery partner, everyone enters through a controlled checkpoint. Your identity is verified, your permissions are checked, and only then are you allowed to proceed.

The Kubernetes API Server plays a very similar role.

It is the single entry point to the Kubernetes control plane.

Nothing in Kubernetes bypasses the API Server.

Whether you’re:

• Deploying a new application
• Scaling a Deployment
• Updating a ConfigMap
• Creating a Secret
• Deleting a Pod
• Checking Pod status
• Viewing logs

Every request eventually reaches the API Server.

Think of it as the receptionist, security officer, traffic controller, and record keeper—all combined into one service.

---

Why Does Everything Go Through the API Server?

A natural question many developers ask is:

“Why can’t kubectl communicate directly with a worker node?”

Suppose it did.

Imagine ten developers deploying applications simultaneously.

Operations is scaling a Deployment.

An automated CI/CD pipeline is updating another application.

The Horizontal Pod Autoscaler is increasing replicas.

Meanwhile, the ReplicaSet controller is recreating failed Pods.

If all of these components modified the cluster independently, chaos would quickly follow.

Instead, Kubernetes follows a very strict rule.

                    Every Request

                         │

                         ▼

                  Kubernetes API Server

                         │

                         ▼

                  Cluster State Changes

One entry point.

One source of truth.

One consistent view of the cluster.

This architecture prevents conflicting updates and allows Kubernetes to maintain a reliable record of the desired state.

---

Sarah’s Deployment Request

Let’s return to Sarah.

When she executes:

kubectl apply -f payment-service.yaml

kubectl doesn’t know how to create Pods.

It doesn’t know how to schedule containers.

It simply sends an HTTP request to the Kubernetes API.

Conceptually, it looks something like this:

POST /apis/apps/v1/namespaces/banking/deployments

The body of the request contains the Deployment manifest.

kind: Deployment

metadata:
  name: payment-service

spec:
  replicas: 3

At this moment, the Payment Service still doesn’t exist.

The API Server has merely received a request asking for one.

---

Step 1 – Authentication

The API Server’s first responsibility is security.

Before processing the request, it asks a simple question.

“Who are you?”

This process is called authentication.

Sarah may authenticate using:

• A kubeconfig certificate
• An OAuth token
• Azure Active Directory
• AWS IAM
• OpenShift OAuth
• A service account
• An enterprise identity provider

Until her identity is verified, Kubernetes refuses to process the request.

This is no different from internet banking.

Before transferring money, the bank first verifies who you are.

Identity always comes before action.

---

Step 2 – Authorization

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

Suppose Sarah belongs to the Development team.

Her permissions might allow:

✔ Create Deployments in the Development namespace

✔ Update existing Deployments

✔ View Pods

But deny:

✖ Delete Production Deployments

✖ Access Production Secrets

✖ Modify Cluster Roles

If Sarah accidentally executes:

kubectl delete deployment payment-service -n production

The API Server rejects the request immediately.

No Pods are touched.

No containers stop.

Nothing changes inside the cluster.

This protection exists because Kubernetes uses Role-Based Access Control (RBAC) to ensure users only perform authorized operations.

We’ll dedicate an entire article to RBAC later in the series because it’s one of the most important security features in enterprise Kubernetes environments.

---

Step 3 – Admission Controllers

At this stage, Sarah is authenticated and authorized.

But Kubernetes still isn’t ready to accept the Deployment.

Before saving anything, the request passes through a set of components called Admission Controllers.

Think of them as automated quality inspectors.

They can:

• Reject invalid requests
• Add default values
• Enforce organizational policies
• Validate security requirements

For example, suppose Sarah forgot to define CPU and memory limits.

containers:

- name: payment-service

  image: bank/payment-service:2.4.1

A company policy may require every container to define resources.

The Admission Controller rejects the deployment.

Error

Resource limits are mandatory.

Nothing reaches production.

Large organizations rely heavily on Admission Controllers to ensure every deployment follows security, compliance, and operational standards.

Instead of relying on developers to remember every rule, Kubernetes enforces them automatically.

---

Step 4 – Validation

Next, Kubernetes validates the Deployment manifest itself.

Questions include:

Does the YAML follow the Kubernetes schema?

Is the API version supported?

Does the Deployment specification contain required fields?

Is the syntax valid?

For example:

replicas: three

This looks harmless.

But replicas must be an integer.

The API Server immediately rejects the request.

Likewise:

apiVersion: apps/v7

If the API version doesn’t exist, Kubernetes refuses to continue.

One important lesson here is that Kubernetes never stores invalid objects.

The cluster state always remains consistent.

---

Step 5 – Defaulting

Suppose Sarah omits certain optional properties.

spec:

  replicas: 3

She doesn’t specify:

• Restart policy
• DNS policy
• Image pull policy
• Scheduler name

Does Kubernetes fail?

No.

The API Server automatically applies sensible defaults.

For example:

restartPolicy: Always

is added automatically for Deployments.

This process is known as defaulting.

Many developers are surprised to discover that the object stored inside Kubernetes is often richer than the YAML they originally submitted.

---

Step 6 – Persistence

After passing every validation stage, the API Server performs what is arguably its most important responsibility.

It stores the Deployment.

Not inside memory.

Not on a worker node.

Not inside Docker.

Instead, it writes the desired state into etcd.

This is the first permanent record of Sarah’s deployment.

Notice what still hasn’t happened.

No Pod exists.

No image has been downloaded.

No JVM has started.

No container has been created.

The Deployment exists only as data inside Kubernetes.

That distinction is extremely important.

Kubernetes doesn’t immediately create infrastructure.

It first records what the desired infrastructure should look like.

Only after the desired state has been safely persisted do the other controllers begin transforming that declaration into reality.

---

Why Persistence Comes First

Imagine a different sequence.

Suppose Kubernetes started creating Pods immediately and only later attempted to record the Deployment.

Now imagine the control plane crashes halfway through.

Some Pods may already exist.

Some may not.

Nobody knows the intended replica count.

The cluster would be left in an inconsistent state.

Instead, Kubernetes follows a much safer approach.

1. Validate Request

        │

        ▼

2. Store Desired State

        │

        ▼

3. Begin Reconciliation

        │

        ▼

4. Create Infrastructure

This design ensures that the desired state is never lost, even if individual controllers or worker nodes fail during deployment.

It’s one of the key reasons Kubernetes is resilient.

---

Meet etcd – The Memory of Kubernetes

If the API Server is the brain of Kubernetes, then etcd is its memory.

Every object in the cluster is stored inside etcd.

That includes:

• Deployments
• Pods
• Services
• Secrets
• ConfigMaps
• Namespaces
• Nodes
• Persistent Volumes
• ReplicaSets

Even though Sarah only created one Deployment, Kubernetes now has a permanent record of her request.

Think of etcd as the cluster’s source of truth.

Whenever a controller wants to know what should exist, it doesn’t ask the worker nodes.

It asks etcd.

Worker nodes represent the current state.

etcd stores the desired state.

That separation is the foundation of Kubernetes’ reconciliation model.

---

The Orchestra Is About to Begin

At this moment, something fascinating happens.

The API Server has completed its work.

It doesn’t create Pods.

It doesn’t schedule containers.

It simply exposes the updated cluster state.

Other Kubernetes components continuously watch the API Server for changes.

One of those components has just noticed something new.

A Deployment named payment-service has appeared.

The Deployment Controller immediately wakes up and begins asking a new question:

“How do I transform this Deployment object into three running Pods?”

That’s where the orchestration process truly begins.

In the next section, we’ll meet the Deployment Controller and ReplicaSet Controller, the components responsible for turning Sarah’s simple YAML declaration into a living, self-healing Spring Boot application.