Skip to content
DRDiwakar Rai

Notes01-Introduction

Introduction

Kubernetes runs containerized applications across a cluster of machines by reconciling the objects you declare with what is actually running.

Updated Oct 1, 2026

Kubernetes Quick Notes





What a cluster is

  • Control plane: Decides. kube-apiserver is the only component that writes cluster state. It stores that state in etcd. kube-scheduler assigns Pods to nodes. kube-controller-manager runs the loops that keep replica counts, endpoints, nodes, and similar objects in line with their specs.
  • Workers: Run containers. The kubelet on each node talks to a container runtime through CRI (usually containerd). kube-proxy programs Service forwarding. A CNI plugin assigns Pod IPs.
  • One API: kubectl, controllers, and the scheduler are all clients of the API server. They do not edit etcd themselves.

On a kubeadm cluster the control-plane processes are static Pods, started from files in /etc/kubernetes/manifests, so they can come up before the API is healthy.


Desired state

  • Spec: What you asked for.
  • Status: What controllers last observed.
  • Reconciliation: A controller notices drift and acts. Delete a Pod that a Deployment still wants, and a new Pod appears. You repair the spec. You do not SSH in and restart a process by hand as the steady state.
  • Declarative file: kubectl apply -f creates or updates an object so the live spec matches the file.
  • Imperative commands: kubectl create, kubectl scale, kubectl set, and kubectl expose write the same objects without a file. kubectl create deployment web --image=nginx --dry-run=client -o yaml prints a valid manifest you can edit.


Objects you will use constantly

Object

Role

Pod

Smallest scheduled unit. One or more containers share one IP, localhost, and volumes

ReplicaSet

Keeps a count of Pods that match a label selector

Deployment

Updates a Pod template by rolling out a new ReplicaSet

DaemonSet

One Pod per matching node (agents, kube-proxy, CNI)

Service

Stable virtual IP and DNS name in front of changing Pods

Namespace

Name and policy boundary inside one cluster

ConfigMap / Secret

Configuration and credentials, as env vars or files

PersistentVolume / PersistentVolumeClaim

Disk that outlives the Pod

Ingress / HTTPRoute

HTTP routes from outside the cluster to Services

Namespaces shipped with every cluster: default, kube-system (control plane and addons), kube-public, kube-node-lease.

A Service named web in namespace shop is web.shop.svc.cluster.local from inside the cluster.




Scheduling in one pass

The scheduler places a Pod on a node that survives every filter: enough free CPU and memory for the requests, a matching nodeSelector or node affinity, and a toleration for every NoSchedule taint. Limits cap the running container. Memory past the limit gets the container OOMKilled. Setting spec.nodeName pins a Pod to that node and skips the scheduler.

How a request is allowed

  1. Authentication proves who is calling (client certificate, bearer token, ServiceAccount).
  2. Authorization (RBAC) checks the verb on that resource. kubectl auth can-i asks this question as a given user.
  3. Admission may reject or mutate the object (quotas, Pod Security, webhooks).

A client certificate’s CN is the username and O is the group. kubeconfig ties a cluster (API URL + CA), a user (cert or token), and a context together.


What is stored where

  • etcd holds objects. Snapshot it with etcdctl snapshot save before control-plane upgrades. A restore writes a new data directory that the etcd manifest must point at.
  • Container logs are stdout and stderr. kubectl logs and kubectl logs --previous read them. Files the process wrote to its own disk are not included.
  • Metrics (kubectl top) come from metrics-server. The HorizontalPodAutoscaler uses the same API, and CPU utilization is computed from the container’s CPU request.


Official docs