What is Kubernetes

In this lesson/article for a DevOps engineer interview, we’ll start with the fundamentals of Kubernetes and how it makes running containers at scale reliable and declarative. What is Kubernetes? Kubernetes is a control plane that runs containerized workloads across a fleet of machines and continuously reconciles the cluster to match the desired state you declare. Instead of specifying which machine should run a workload, you declare the desired outcome (for example, how many replicas of a service you want) and Kubernetes makes that happen — and keeps it that way. Example: declare three replicas

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:latest
        resources:
          requests:
            memory: "2Gi"
            cpu: "500m"

Apply the manifest to the cluster:

kubectl apply -f deployment.yaml

After applying, Kubernetes will ensure three running pods that match your Deployment. If a node fails and a pod is lost, controllers detect the discrepancy and create another pod to restore the declared state. You declare the desired state; Kubernetes continuously works to reach and maintain it. The control plane — the brain of Kubernetes Several components together form the control plane. They coordinate to accept your desired state, store it, and reconcile the actual cluster state with that desired state.

The image illustrates a Kubernetes control plane diagram with components like the API server, etcd, and controllers, organized in a triangle, with the title "The control plane" and stick figures labeled "INTERVIEWER" and "CANDIDATE."

API server: the front door for all requests and the primary interface for components and users. Every command and component talks to the API server.
etcd: the distributed key-value store where Kubernetes persists cluster state (both desired and observed).
Controllers: control loops that continuously compare desired state vs. actual state and take actions to reconcile them.
Scheduler: assigns pods to appropriate nodes based on resource needs, affinity/anti-affinity, taints/tolerations, and other constraints.
Kubelet: the node agent that ensures containers for assigned pods are running on a specific node.

Quick reference table

Component	Primary role	Responsibilities
API server	Cluster frontend	Accepts RESTful requests, validates & persists objects
`etcd`	Cluster storage	Stores desired and observed cluster state
Controllers	Reconciliation loops	Watch API state and create/update/delete resources to match the desired state
Scheduler	Placement decision maker	Chooses the best node for unscheduled pods
Kubelet	Node agent	Starts containers, configures networking, and reports status

etcd stores both:

the desired state you submit (for example, the Deployment with replicas: 3), and
the current observed state of the cluster.

Controllers are declarative reconcilers: they continuously observe API state and make changes until the cluster matches the desired specification.

Scheduling: how Kubernetes picks a node

The image is a diagram illustrating a scheduling system with components like ETCD, scheduler, and controllers, and it shows nodes with different memory capacities where Node B is labeled as "too small."

When a pod is created, it initially exists in the API server in an unscheduled state (no nodeName set). The scheduler watches for unscheduled pods and processes each in two main phases:

Filter (pre-score): Exclude nodes that cannot run the pod. Filters include:
- Insufficient CPU/memory or other resource constraints
- Taints on nodes that the pod does not tolerate
- Node selectors, node affinity, or other constraints
Score (prioritize): Rank the remaining nodes using scoring rules — for example, packing vs. balanced placement, affinity/anti-affinity, or custom scoring plugins — and pick the best fit.

Once a node is chosen, the scheduler writes the chosen node’s name into the PodSpec via the API server. The scheduler decides placement only; it does not start containers. Kubelet: making scheduling decisions real on a node

The image illustrates a Kubernetes setup with two nodes, showing pod IPs and kubelet processes, alongside an interviewer and candidate represented by stick figures.

When a pod becomes assigned to a node, the kubelet on that node notices the new PodSpec via the API server. The kubelet:

Pulls container images using the container runtime (for example, containerd).
Starts and supervises containers for the pod.
Configures pod networking and mounts volumes.
Periodically reports pod and node status back to the API server.

Together: the control loop The core control loop of Kubernetes can be summarized as:

You declare the desired state (create a Deployment, Service, etc.).
The API server stores the spec in etcd.
Controllers and the scheduler watch the API, compare desired vs actual state, and take actions (create pods, assign nodes).
Kubelets on nodes execute the runtime actions to realize the desired state and report status.
Controllers continue reconciling until the actual state matches the desired state.

Docker

Kubernetes

CI/CD & DevOps

Security

Networking

Advanced Concepts

Interview Setup

System Design

What is Kubernetes

Watch Video