Kubernetes API Server
Kubernetes API Server
Architecture, Request Lifecycle, Communication and Troubleshooting
The Kubernetes API Server is the central interface through which users, Kubernetes components, and external systems communicate with a Kubernetes cluster.
If you understand the API Server, you can understand a large part of how Kubernetes itself works.
A simplified architecture is:
Kubernetes Cluster
User / CI-CD / Operator / kubectl / Controller
|
| HTTPS
v
+-------------------+
| kube-apiserver |
| API Server |
+-------------------+
| | |
| | |
v v v
etcd Scheduler Controllers
|
v
Worker Nodes
|
kubelet
|
Container Runtime
|
Pods
The API Server is the front end of the Kubernetes Control Plane and exposes the Kubernetes API over HTTP. Kubernetes users, cluster components, and external components communicate with the cluster through this API.
1. What Is the Kubernetes API Server?
The Kubernetes API Server is the component that exposes and implements the Kubernetes API.
Its primary implementation is:
kube-apiserver
It provides an HTTP API through which clients can:
Create resources
Read resources
Update resources
Patch resources
Delete resources
Watch resources
Perform subresource operations
Discover available APIs
The official Kubernetes documentation describes kube-apiserver as the component that validates and configures data for API objects and provides the frontend to the cluster's shared state.
A simple mental model is:
API Server
|
+------------+------------+
| | |
v v v
Users Controllers Nodes
| | |
kubectl Scheduler kubelet
The API Server is therefore not simply a REST endpoint for kubectl.
It is a central communication point for the Kubernetes control system.
2. Why Is the API Server So Important?
Almost everything Kubernetes does revolves around API objects.
Examples include:
Pod
Deployment
Service
Node
Namespace
ConfigMap
Secret
Job
CronJob
ServiceAccount
Role
RoleBinding
PersistentVolume
PersistentVolumeClaim
These objects are exposed through the Kubernetes API.
For example:
kubectl get pods
is effectively asking the Kubernetes API:
"Give me the Pod resources I am authorized to see."
Similarly:
kubectl create namespace dev
means:
"Create a Namespace object named dev."
The API Server receives, processes, and responds to these requests.
3. API Server as the Kubernetes Communication Hub
A very useful Kubernetes architecture principle is the hub-and-spoke API pattern.
The simplified model is:
API SERVER
|
+-----------------+-----------------+
| | |
v v v
kubelet Scheduler Controllers
| | |
v | |
Worker | |
| |
+-------+---------+
|
v
etcd
Kubernetes documents that API usage from nodes and Pods running on nodes terminates at the API Server. Other Control Plane components are not designed as general remote services for nodes.
This is an important security and architecture concept.
4. API Server Does Not Mean "Database"
A common misconception is:
"The API Server stores Kubernetes data."
More precisely:
API Server
|
| persists cluster state
v
etcd
The API Server provides the API and handles requests.
etcd is the persistent backing store.
Kubernetes documentation states that Kubernetes stores the serialized state of API objects in etcd.
So:
| Component | Main responsibility |
|---|---|
| API Server | API, validation, authentication/authorization, admission and request processing |
| etcd | Persistent storage of Kubernetes state |
| Scheduler | Pod placement decisions |
| Controllers | Reconciliation |
| kubelet | Node-level Pod management |
5. Where Does kube-apiserver Run?
The API Server runs as part of the Kubernetes Control Plane.
A typical cluster might look like:
CONTROL PLANE
+-----------------------+
| kube-apiserver |
| kube-scheduler |
| kube-controller-mgr |
| etcd |
+-----------------------+
|
|
v
WORKER NODES
+---------+---------+
| |
v v
Worker 1 Worker 2
kubelet kubelet
runtime runtime
Pods Pods
In a highly available cluster, multiple API Server instances can run.
Load Balancer
|
+----------+----------+
| | |
v v v
API-1 API-2 API-3
kube-apiserver is designed to scale horizontally by running additional instances.
6. Kubernetes API Is REST-Based
The Kubernetes API is a resource-oriented HTTP API.
It supports standard HTTP operations including:
GET
POST
PUT
PATCH
DELETE
Kubernetes also has API-specific operations such as:
LIST
WATCH
The official API documentation describes Kubernetes as a resource-based RESTful interface provided over HTTP.
Conceptually:
HTTP Request
|
v
API Server
|
v
Kubernetes Resource
7. Kubernetes API Resources
Consider a Pod.
The resource is:
pods
A request might conceptually look like:
GET /api/v1/namespaces/default/pods
For a specific Pod:
GET /api/v1/namespaces/default/pods/nginx
The response is normally represented as JSON unless another supported representation is negotiated.
Kubernetes uses different URL structures for cluster-scoped and namespace-scoped resources. Core APIs use /api, while named API groups use /apis.
8. /api vs /apis
This is an important Kubernetes API concept.
Core API group
Core resources use:
/api/v1
Examples:
/api/v1/pods
/api/v1/nodes
/api/v1/namespaces
/api/v1/services
The core group does not include a group name in the URL.
Named API groups
Other APIs use:
/apis/<group>/<version>
For example:
/apis/apps/v1
/apis/batch/v1
/apis/rbac.authorization.k8s.io/v1
A Deployment therefore belongs to:
apps/v1
while a Job belongs to:
batch/v1
Kubernetes uses API groups to organize and extend the API.
9. API Versioning
You frequently see:
apiVersion: apps/v1
kind: Deployment
The:
apiVersion
field tells Kubernetes which API version is being used to represent the resource.
For example:
apiVersion: v1
kind: Pod
versus:
apiVersion: apps/v1
kind: Deployment
API versioning allows Kubernetes APIs to evolve while maintaining a consistent interface.
The API Server can also convert between API versions where supported. Kubernetes documents API versioning as occurring at the API level rather than independently for individual fields.
10. What Happens When You Run kubectl get pods?
This is one of the most important flows to understand.
You run:
kubectl get pods
The simplified communication is:
Terminal
|
| HTTPS
v
kubectl
|
v
+-------------+
| API Server |
+-------------+
|
v
Kubernetes API
|
v
Response
|
v
kubectl
|
v
Terminal
kubectl is a Kubernetes API client.
It does not directly query kubelet or etcd for ordinary API operations.
11. What Happens When You Run kubectl apply?
Consider:
kubectl apply -f deployment.yaml
The high-level flow is:
kubectl
|
v
API Server
|
+--> Authentication
|
+--> Authorization
|
+--> Admission
|
+--> Validation
|
v
Persist object
|
v
etcd
After the resource is accepted and persisted, other Kubernetes components observe the resulting state and reconcile it.
For a Deployment:
Deployment
|
v
Deployment Controller
|
v
ReplicaSet
|
v
Pods
|
v
Scheduler
|
v
Worker Node
This is why the API Server is central to the Kubernetes control architecture.
12. API Request Lifecycle
A useful professional mental model is:
Client
|
v
API Server
|
+--> Authentication
|
+--> Authorization
|
+--> Admission
|
+--> Validation
|
+--> Processing
|
+--> Persistence
|
v
Response
The exact internal processing path varies by request type, but this model is useful for understanding the major security and validation stages.
13. Step 1 — Client Sends Request
The client could be:
kubectl
Controller
Operator
Scheduler
kubelet
CI/CD system
Custom application
For example:
kubectl create namespace production
The client sends an HTTP request to the API Server.
Conceptually:
Client
|
| HTTPS
v
kube-apiserver
14. Step 2 — Authentication
The API Server needs to determine:
Who is making this request?
This is authentication.
Examples of Kubernetes authentication mechanisms include:
Client certificates
Bearer tokens
Service account credentials
Authentication integrations configured for the cluster
The important distinction is:
Authentication
=
Who are you?
while:
Authorization
=
What are you allowed to do?
15. Step 3 — Authorization
After authentication, Kubernetes determines whether that identity is allowed to perform the requested action.
For example:
User: alice
Action:
delete
Resource:
pod
Namespace:
production
The authorization decision is conceptually:
Can Alice delete Pods in production?
This is where Kubernetes authorization mechanisms such as RBAC become important.
16. Authentication vs Authorization
A simple comparison:
| Question | Mechanism |
|---|---|
| Who are you? | Authentication |
| What can you do? | Authorization |
| Should this object be modified? | Admission |
| Is the object structurally valid? | API validation |
| Where is persistent state stored? | etcd |
Remember:
Authentication
↓
Authorization
↓
Admission
↓
Validation
↓
Persistence
This sequence is a useful conceptual model for API request processing.
17. Step 4 — Admission Control
Admission control occurs after authentication and authorization and before the resource is persisted.
Kubernetes describes admission controllers as code that intercepts requests to the API Server before persistence. They can mutate or validate requests that modify resources.
Conceptually:
API Request
|
v
Authentication
|
v
Authorization
|
v
Admission Control
/ \
/ \
Mutating Validating
\ /
\ /
v v
Continue
|
v
Persistence
18. Mutating Admission
A mutating admission mechanism can modify an incoming object.
For example, an admission mechanism could add or modify fields before persistence.
Conceptually:
Request
Pod
|
+-- image
+-- containers
becomes:
Modified object
Pod
|
+-- image
+-- containers
+-- injected configuration
Kubernetes currently supports mutating admission mechanisms including mutating admission webhooks and MutatingAdmissionPolicy.
19. Validating Admission
Validating admission mechanisms inspect an object and decide whether it should be accepted.
Conceptually:
Pod request
|
v
Validation
|
+---- valid ----> continue
|
+---- invalid --> reject
For example:
Request
|
v
Policy
|
X
Rejected
Kubernetes has validating admission mechanisms including ValidatingAdmissionPolicy and ValidatingAdmissionWebhook.
20. Step 5 — API Validation
The Kubernetes API Server also validates the structure and fields of API requests.
For example:
replicas: "three"
would not be valid if the API schema expects a number.
Kubernetes performs field validation and can operate with validation levels such as:
Ignore
Warn
Strict
The current API documentation states that Warn is the API Server's default field-validation behavior, while kubectl uses strict validation by default through its --validate setting.
21. Step 6 — Persistence
Once a modifying request passes the relevant processing stages, Kubernetes persists the API object's state.
The architecture is:
API Server
|
|
v
etcd
|
v
Persistent State
Kubernetes stores serialized API object state in etcd.
This is why protecting etcd is critical in a Kubernetes cluster.
22. Does API Server Store Data in Memory?
The API Server does maintain internal caches and mechanisms for efficient API serving, including watch caches.
But the authoritative persistent cluster state is stored in etcd.
Think of the architecture as:
API Server
|
+-------+-------+
| |
caches persistence
| |
v v
fast reads etcd
Do not confuse API Server caching mechanisms with the durable cluster state stored in etcd.
23. API Server and Watch
One of the most important Kubernetes API features is:
WATCH
Instead of repeatedly asking:
"Has the Pod changed?"
a client can establish a watch:
```text
Client
|
| WATCH
v
API Server
|
| events
+----> ADDED
+----> MODIFIED
+----> DELETED
Kubernetes describes watch as a mechanism for tracking resource changes as a stream.
This is fundamental to Kubernetes controllers.
24. Why Watch Is Important
Imagine the Deployment controller wants to know when Pods change.
Without watch:
Controller
|
+--> GET Pods
|
+--> wait
|
+--> GET Pods
|
+--> wait
|
+--> GET Pods
With watch:
Controller
|
| WATCH
v
API Server
|
| Pod changed
v
Controller
This allows Kubernetes components to react efficiently to changes.
25. API Server and Controllers
Controllers are heavily dependent on the Kubernetes API.
Conceptually:
API Server
|
+-----------+-----------+
| |
v v
Controller Scheduler
|
v
Desired state
|
v
Kubernetes API
The controller watches resources and makes API changes to move the cluster toward the desired state.
This is one reason the API Server is central to Kubernetes' declarative architecture.
26. API Server and Scheduler
The scheduler also communicates with the API Server.
A simplified flow:
Pod created
|
v
API Server
|
v
Pod has no node assignment
|
v
Scheduler observes Pod
|
v
Scheduler selects Node
|
v
API Server
|
v
Pod updated with assignment
The scheduler does not normally bypass the API Server and directly configure the Worker Node.
27. API Server and kubelet
The Worker Node's kubelet also communicates with the API Server.
Worker Node
|
kubelet
|
| HTTPS
v
API Server
Kubernetes uses this communication path for node-related API operations and state synchronization.
Nodes are provisioned with credentials and the cluster's root certificate so they can securely communicate with the API Server.
28. API Server → kubelet
There is also an important reverse communication path.
API Server
|
| HTTPS
v
kubelet
|
v
Pod
This path is used for operations including:
kubectl logs
kubectl attach
kubectl port-forward
Kubernetes documents API Server → kubelet connections for fetching Pod logs, attaching to running Pods, and kubelet port-forwarding.
29. Example: kubectl logs
When you run:
kubectl logs nginx
do not think:
kubectl → Worker Node
A more useful conceptual model is:
kubectl
|
v
API Server
|
v
kubelet
|
v
Container / log source
|
v
API Server
|
v
kubectl
This is extremely useful when troubleshooting.
30. Example: kubectl exec
Consider:
kubectl exec -it nginx -- /bin/sh
Conceptually:
Terminal
|
v
kubectl
|
v
API Server
|
v
kubelet
|
v
Container
|
v
/bin/sh
Therefore, a failure in kubectl exec does not necessarily indicate that the Pod cannot communicate with another Pod.
It can instead indicate a problem in the API Server → kubelet → container path.
31. API Server Is Not the Normal Application Data Path
This distinction is critical.
Suppose:
Pod A
|
| HTTP
v
Pod B
The API Server is normally not in the middle of that application request.
Instead:
Pod A
|
v
Pod Network
|
v
Pod B
The API Server handles Kubernetes API/control communication.
Application data normally travels through the cluster's data-plane networking.
Kubernetes explicitly distinguishes API Server communication from node and Pod networking.
32. API Server and Service Networking
A Pod can also access the Kubernetes API through the cluster's Kubernetes Service.
Kubernetes creates a kubernetes Service in the default namespace.
Conceptually:
Pod
|
| HTTPS
v
kubernetes Service
|
v
API Server
The official Control Plane communication documentation notes that Pods can connect securely to the API Server using a ServiceAccount and that the kubernetes Service provides a virtual IP that is redirected to the API Server HTTPS endpoint.
33. API Server Authentication From a Pod
When a Pod needs to communicate with the API Server, Kubernetes can provide it with ServiceAccount credentials.
Conceptually:
Pod
|
+-- CA certificate
|
+-- bearer token
|
v
API Server
The application can then authenticate to the Kubernetes API using those credentials, subject to the permissions granted to its identity.
This is the foundation for:
Operators
Controllers
Kubernetes-aware applications
Automation tools
In-cluster agents
34. API Server Security
The API Server is one of the most security-sensitive components in Kubernetes.
A useful security model is:
API SERVER
|
+-------------+-------------+
| | |
v v v
Authentication Authorization Admission
| | |
+-------------+-------------+
|
v
API Object
|
v
etcd
If an attacker gains unauthorized access to the Kubernetes API, the impact can be extremely serious because the API controls cluster resources.
Therefore:
Use strong authentication
Use appropriate authorization
Protect API Server network access
Protect etcd
Use TLS appropriately
Apply least privilege
Audit API activity where appropriate
35. TLS and HTTPS
The Kubernetes API Server normally exposes its API through a secure HTTPS endpoint.
The official Kubernetes documentation describes the API Server as listening for remote connections on a secure HTTPS port, commonly exposed through port 443 or another configured endpoint.
A common cluster endpoint may look like:
https://kubernetes.example.com:6443
or:
https://kubernetes.example.com:443
The externally visible port depends on the cluster architecture and any load balancer or proxy in front of the API Server.
36. Kubernetes API Server Port
A commonly documented Kubernetes API Server port is:
6443/TCP
However, don't hard-code this assumption into your architecture.
For example:
Client
|
| :443
v
Load Balancer
|
| :6443
v
API Server
The official Kubernetes ports documentation lists 6443/TCP as the default Kubernetes API Server port while allowing deployments to use different configurations.
For production architecture, always inspect the actual cluster configuration rather than assuming the default.
37. API Discovery
Kubernetes clients need to know:
What APIs does this cluster support?
The Kubernetes API provides discovery mechanisms for this.
For example:
kubectl api-resources
can show resources available through the API.
You can also inspect API versions:
kubectl api-versions
The Kubernetes documentation identifies the Discovery API and OpenAPI documents as mechanisms through which Kubernetes publishes API information and schemas.
38. API Resources vs Kind
Kubernetes terminology can initially be confusing.
Consider:
kind: Pod
The API resource is generally:
pods
So:
Kind
Pod
Resource
pods
Another example:
Kind:
Deployment
Resource:
deployments
This distinction becomes useful when working directly with the Kubernetes API.
39. API Object Example
A simple Pod:
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx
The API Server receives this object representation.
Conceptually:
YAML
|
v
kubectl
|
v
API Server
|
+--> Decode
+--> Authenticate
+--> Authorize
+--> Admit
+--> Validate
|
v
Persist
|
v
etcd
40. kubectl Is Not Kubernetes
This distinction is worth remembering.
kubectl
is a client.
kube-apiserver
is the server exposing the Kubernetes API.
So:
kubectl
|
| HTTP/HTTPS
v
kube-apiserver
You can also access the API without kubectl using:
Kubernetes client libraries
REST clients
Controllers
Operators
Other API clients
The official Kubernetes documentation explicitly states that Kubernetes APIs can be accessed through kubectl, other command-line tools, REST calls, and client libraries.
41. Direct API Example
You can inspect the API endpoint using:
kubectl cluster-info
You can also use:
kubectl get --raw='/version'
For example:
kubectl get --raw='/api'
or:
kubectl get --raw='/apis'
These commands allow you to interact with the API more directly.
42. API Server and CRDs
One of Kubernetes' powerful extensibility mechanisms is the Custom Resource Definition (CRD).
A CRD allows users to extend the Kubernetes API with a new resource type.
Conceptually:
Built-in API
Pod
Deployment
Service
+
Custom API
MyDatabase
MyApplication
MyBackup
After creating a CRD:
CRD
|
v
API Server
|
v
New API resource
A custom controller/operator can then watch that resource and implement the desired behavior.
This produces a powerful pattern:
Custom Resource
|
v
API Server
|
v
Controller
|
v
Actual infrastructure
43. API Aggregation
Kubernetes can also expose APIs through the aggregation layer.
This allows additional API servers to serve API groups alongside the main Kubernetes API.
Conceptually:
API Server
|
+-------------+-------------+
| |
v v
Built-in APIs Aggregated APIs
| |
Pods Custom API
Services
Deployments
This is different from simply creating a CRD.
A CRD extends the API resource model within the main API Server, while API aggregation allows separate API servers to provide API groups.
44. API Server and Custom Controllers
Consider a custom operator managing databases.
User
kubectl apply
|
v
Database CR
|
v
API Server
|
v
etcd
|
v
Database Controller
|
v
Create/modify resources
The controller does not need direct access to etcd.
It uses the Kubernetes API.
This reinforces the central architectural principle:
API Server
|
+---- Scheduler
|
+---- Controllers
|
+---- kubelet
|
+---- Operators
|
+---- kubectl
45. API Server High Availability
A production Kubernetes cluster should consider API Server availability carefully.
A simplified architecture:
Clients
|
v
Load Balancer
|
+------------+------------+
| | |
v v v
API-1 API-2 API-3
| | |
+------------+------------+
|
v
etcd
Multiple API Server instances can serve API requests.
Because kube-apiserver is designed to scale horizontally, multiple instances can be deployed behind a suitable load-balancing architecture.
46. API Server Is Stateless Relative to etcd
A useful architectural concept is:
API Servers
+------+ +------+ +------+
| API1 | | API2 | | API3 |
+--+---+ +--+---+ +--+---+
| | |
+--------+--------+
|
v
etcd
The API Servers rely on the shared persistent cluster state rather than each API Server maintaining an independent authoritative copy of Kubernetes state.
This is one of the reasons multiple API Server instances can serve the same cluster.
47. What Happens If API Server Goes Down?
Suppose a single API Server exists:
kubectl
|
X
API Server
Users may lose access to the Kubernetes API.
Control-plane operations that require the API Server are affected.
However, already-running containers on Worker Nodes do not simply stop because the API Server becomes temporarily unreachable.
The kubelet and container runtime continue managing workloads locally according to their current state.
This distinction is important:
API Server unavailable
≠
All application containers immediately stop
But cluster management, reconciliation and API-driven operations can be significantly affected.
48. API Server and etcd Failure
The API Server also depends on access to its backing store.
Conceptually:
Client
|
v
API Server
|
X
etcd
If etcd becomes unavailable, API Server operations requiring access to persistent cluster state can fail or become degraded.
This is why etcd availability is fundamental to Control Plane availability.
49. API Server Performance
The API Server is a critical shared resource.
Large clusters can generate a significant number of API requests from:
Controllers
Operators
kubelets
CI/CD systems
Monitoring systems
Automation
Users
Therefore, API Server performance matters.
A common architectural problem is excessive API polling.
Instead of repeatedly doing:
GET
wait
GET
wait
GET
wait
Kubernetes components commonly use efficient:
LIST + WATCH
patterns.
The Kubernetes API provides consistent list operations and watches to allow clients to cache, track, and synchronize resource state efficiently.
50. Large LIST Operations
A common API performance problem is requesting extremely large collections.
For example:
GET all Pods
in a very large cluster can produce a large response.
The Kubernetes API supports pagination/chunking for large collections so clients can retrieve large result sets in manageable portions.
For production automation, avoid blindly retrieving huge collections when a more targeted query can accomplish the same task.
51. API Priority and Fairness
Kubernetes also has mechanisms for managing API request concurrency and fairness.
This becomes important when many clients compete for API Server resources.
For example:
API Server
|
+-------------+-------------+
| | |
v v v
User Controller Operator
100 req 500 req 300 req
Without appropriate request management, one class of workload could consume excessive API Server capacity.
API Priority and Fairness is part of Kubernetes' mechanisms for managing API request concurrency.
52. API Server Health Endpoints
The API Server provides health and readiness endpoints useful for monitoring and operations.
Common endpoints include:
/healthz
/readyz
/livez
For example:
kubectl get --raw='/readyz'
These endpoints can help determine whether the API Server is ready to serve traffic.
For production environments, API Server health should be monitored as part of Control Plane observability.
53. Debugging API Server Connectivity
Start with:
kubectl cluster-info
Then:
kubectl get --raw='/version'
You can inspect the current client configuration:
kubectl config view
And:
kubectl config current-context
To inspect API resources:
kubectl api-resources
To inspect API versions:
kubectl api-versions
54. Debugging "Unable to Connect to the Server"
Suppose:
kubectl get pods
returns:
The connection to the server was refused
Don't immediately investigate Pods.
Start at the API path:
kubectl
|
X
API endpoint
Check:
kubectl config view
kubectl config current-context
kubectl cluster-info
Then investigate:
DNS
↓
Load Balancer
↓
Firewall
↓
API Server
↓
API Server health
55. Debugging API Server → kubelet Problems
Suppose:
kubectl get pods
works but:
kubectl logs <pod>
fails.
Investigate the path:
kubectl
|
v
API Server
|
v
kubelet
|
v
Container
Relevant areas include:
API Server connectivity
Node reachability
kubelet availability
kubelet certificate configuration
kubelet authentication/authorization
Firewall rules
Node networking
Kubernetes documents this exact API Server → kubelet path for logs, attach, and port-forward.
56. API Server and Worker Node Security
Kubernetes uses secure API communication between nodes and the API Server.
The official documentation recommends that nodes have the cluster's root certificate and valid credentials for secure API Server communication.
Conceptually:
Worker
|
| TLS
| Client credentials
v
API Server
|
| authentication
v
Authorized request
This is especially important for:
Private clusters
Multi-network environments
Cloud deployments
Hybrid clusters
Untrusted networks
57. API Server Communication Architecture
A useful complete model is:
USERS
|
kubectl
|
v
+----------------+
| API SERVER |
+----------------+
| | |
| | |
v v v
etcd Scheduler Controllers
|
|
v
Worker Nodes
|
kubelet
|
Container Runtime
|
Pods
And in the opposite direction:
Worker Node
|
| API communication
v
API Server
For specific control-plane-to-node operations:
API Server
|
| kubelet API
v
Worker Node
For application traffic:
Pod A
|
| Data Plane
v
Pod B
These should not be confused.
58. API Server vs kubelet vs etcd
This is a very common interview topic.
| Component | Think of it as | Primary job |
|---|---|---|
| API Server | Front door | Kubernetes API |
| etcd | Persistent backing store | Cluster state |
| kubelet | Node agent | Pod lifecycle |
| Scheduler | Placement engine | Pod → Node |
| Controller | Reconciliation engine | Desired → current state |
A useful memory trick:
API Server
= API
etcd
= State
Scheduler
= Placement
Controller
= Reconciliation
kubelet
= Execution on Node
59. End-to-End Example
Suppose you deploy:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx
Run:
kubectl apply -f web.yaml
The simplified architecture becomes:
kubectl
|
v
API Server
|
+---------+---------+
| |
v v
etcd Controllers
|
v
ReplicaSet
|
v
Pods
|
v
Scheduler
|
+--------------+--------------+
| |
v v
Worker 1 Worker 2
| |
kubelet kubelet
| |
runtime runtime
| |
Pods Pods
This single example connects:
API
+
Storage
+
Controllers
+
Scheduling
+
Nodes
+
Runtime
60. Kubernetes API Server: Professional Mental Model
For interviews and production troubleshooting, remember this:
Kubernetes API Server
FRONT DOOR
|
+---------------------+---------------------+
| | |
v v v
Users Components External Apps
| | |
kubectl Scheduler Operators
Controllers
kubelet
|
v
API Objects
|
+------------------+------------------+
| |
v v
Admission Persistence
| |
v v
Validation etcd
The API Server is the central API boundary of Kubernetes.
61. Common Interview Questions
Q1. What is kube-apiserver?
kube-apiserver is the primary implementation of the Kubernetes API Server. It exposes the Kubernetes API and acts as the frontend for the Control Plane.
Q2. Why is the API Server important?
Because users, controllers, scheduler, kubelets, and other components interact with Kubernetes resources through the API Server.
Q3. Does the API Server store data?
The API Server handles API operations; persistent Kubernetes object state is stored in etcd.
Q4. What is the difference between authentication and authorization?
Authentication = Who are you?
Authorization = What can you do?
Q5. What is admission control?
Admission control intercepts requests after authentication and authorization but before persistence, and can mutate or validate modifying requests.
Q6. What is a Kubernetes API watch?
A watch allows clients to receive resource changes as a stream instead of repeatedly polling the API.
Q7. Does Pod-to-Pod traffic pass through the API Server?
Normally, no. Application traffic uses the Kubernetes data-plane networking.
Q8. How does a kubelet communicate with the Control Plane?
The kubelet communicates with the API Server using secure API communication.
Q9. Why can kubectl get pods work while kubectl logs fails?
Because kubectl logs involves an additional API Server → kubelet path.
Q10. Can multiple API Servers run?
Yes. kube-apiserver is designed for horizontal scaling, allowing multiple instances in a highly available architecture.
62. Final Summary
The Kubernetes API Server is much more than an endpoint used by kubectl.
It is the central API boundary of the Kubernetes Control Plane.
The key architecture is:
CLIENTS
|
v
+---------------+
| API SERVER |
+---------------+
| | |
| | |
v v v
etcd Scheduler Controllers
|
v
Worker Nodes
|
kubelet
|
Container Runtime
|
Pods
The most important concepts are:
| Concept | Remember |
|---|---|
| API Server | Frontend of Kubernetes Control Plane |
kube-apiserver | Main API Server implementation |
| REST API | Fundamental Kubernetes API interface |
/api/v1 | Core API group |
/apis/... | Named API groups |
| Authentication | Identify the caller |
| Authorization | Determine permissions |
| Admission | Mutate/validate requests |
| Validation | Verify API object structure/fields |
| etcd | Persistent Kubernetes state |
| Watch | Efficient resource-change notification |
| kubelet | Node-side Kubernetes agent |
| 6443/TCP | Common API Server port |
| API Server → kubelet | Used for logs, attach, port-forward |
| Pod → Pod | Normal application data path, not API Server |
The most useful mental model is:
API SERVER
|
+--------------+--------------+
| | |
v v v
USERS CONTROL PLANE NODES
| | |
kubectl Scheduler kubelet
Controllers |
v
Runtime
|
v
Pods
And the central principle is:
Kubernetes is an API-driven system. The API Server provides the interface through which the cluster's components and clients observe and modify Kubernetes state.
Once you understand the API Server, the next logical concepts are:
API Server
↓
Authentication
↓
Authorization / RBAC
↓
Admission Controllers
↓
etcd
↓
Controllers
↓
Scheduler
↓
kubelet
↓
Container Runtime
↓
Pod
That sequence provides the foundation for understanding how a Kubernetes request travels through the entire Control Plane and eventually becomes a running workload.