Kubernetes Core Concepts

Key terms in plain words

• Cluster: a group of machines that work together as one system.
• Node: one machine (real or virtual) in the cluster. It runs your containers.
• Pod: the smallest thing Kubernetes runs. It holds one or more containers that run together.
• Replica: one copy of a pod. "5 replicas" means 5 identical copies.
• Control plane: the part of Kubernetes that makes decisions. The nodes do the actual work.
• YAML: a simple text format for settings, written as indented keys and values. You write your Kubernetes objects in YAML.
• kubectl: the command-line tool you use to talk to a cluster.
• Label and selector: a label is a key=value tag on an object (like app: orders-api). A selector is a rule that finds all objects with a given label.
• Endpoints: the list of pod addresses that a Service currently sends traffic to. Only ready pods are on the list.
• Stateless and stateful: a stateless app keeps no important data inside itself, so any copy can be replaced. A stateful app (like a database) keeps data that must not be lost.

Architecture: control plane and nodes

The control plane (the brain):

• kube-apiserver: the front door. Every change goes through its API (a set of web requests that tools can call).
• etcd: a small database that stores data as key-value pairs. It keeps copies on several machines and uses the Raft algorithm (post 24), a method that lets several machines vote and agree on one value, so the copies always agree. It holds all cluster state. Back it up.
• kube-scheduler: chooses a node for each new pod. It looks at the resources the pod asks for, any placement rules, and how to spread pods out.
• controller-manager: runs many controllers. A controller is a loop that watches the state and fixes any difference from what you asked for.

Worker nodes (the muscle):

• kubelet: a small program (an agent) on each node. It starts and stops containers and reports their status to the control plane.
• Container runtime: the program that actually runs the containers, such as containerd or CRI-O. It runs OCI images (post 55).
• kube-proxy / CNI network plugin: these set up the network between pods and send Service traffic to the right pod. (CNI means Container Network Interface.)

Managed services (Amazon EKS, Google GKE, Azure AKS and others) run the control plane for you. Most teams use one of these instead of running the control plane themselves.

The reconciliation loop

This loop is the main idea of Kubernetes. A "loop" here is a job that repeats forever:

Every controller does this, over and over. Say a node dies and 2 pods disappear. The Deployment's controller sees "desired 5, current 3" and creates 2 new pods on other nodes. You do not write the recovery steps. You only state the goal.

Core objects

Pod

A pod is the smallest unit you can deploy. It is one or more containers that share one network address (IP) and can share storage volumes.

• Usually there is one main container per pod. Sometimes there are also sidecars: helper containers that run next to the main one, such as a logging agent or a service-mesh proxy (post 54).
• Pods are disposable. They are replaced, not repaired, and each new pod gets a new IP. Never depend on one specific pod.

Deployment (and ReplicaSet)

A Deployment is the most common way to run stateless apps. It says "run N copies of this pod template, and update them safely". (A pod template is the blueprint for the pods.)

apiVersion: apps/v1kind: Deploymentmetadata:  name: orders-apispec:  replicas: 3  selector:    matchLabels: { app: orders-api }  strategy:    type: RollingUpdate    rollingUpdate: { maxUnavailable: 0, maxSurge: 1 }   # no downtime during the update  template:    metadata:      labels: { app: orders-api }    spec:      containers:        - name: api          image: myshop/orders-api:1.4.2          ports: [{ containerPort: 3000 }]          envFrom:            - configMapRef: { name: orders-config }            - secretRef:    { name: orders-secrets }          resources:            requests: { cpu: "250m", memory: "256Mi" }            limits:   { memory: "512Mi" }          readinessProbe:            httpGet: { path: /ready, port: 3000 }            periodSeconds: 5          livenessProbe:            httpGet: { path: /healthz, port: 3000 }            initialDelaySeconds: 10            periodSeconds: 10

The Deployment manages ReplicaSets. A ReplicaSet keeps the right number of pods running. Say you change the image to 1.4.3. The Deployment then does a rolling update: it starts new pods and stops old ones a little at a time, so the app stays up. In the example above, maxUnavailable: 0 and maxSurge: 1 mean that no pod may be missing, and at most one extra pod may exist during the update. The command kubectl rollout undo goes back to the previous version.

Other workload types

• StatefulSet: for stateful apps (databases, Kafka, which passes streams of messages between programs, or ZooKeeper, a coordination service). Its pods get fixed names (db-0, db-1), their own storage that stays with them, and they start and stop in a set order.
• DaemonSet: runs one pod on every node. It is used for log collectors, monitoring agents and network plugins.
• Job: runs pods until the work is finished, then stops. Examples are a database migration or a batch import.
• CronJob: runs Jobs on a schedule, like "every night at 2 AM" (post 38).

Service: a stable address for changing pods

Pods come and go, so their IPs keep changing. A Service fixes this. It gives a set of pods (chosen by labels) one stable name and virtual IP. It also load-balances (shares) the traffic between the pods that are ready (post 54):

apiVersion: v1kind: Servicemetadata:  name: orders-apispec:  selector: { app: orders-api }  ports: [{ port: 80, targetPort: 3000 }]  type: ClusterIP

Other pods can now call http://orders-api. The cluster DNS (the name lookup service) turns that name into the Service IP.

Service types:

• ClusterIP (the default): reachable inside the cluster only.
• NodePort: opens the same port on every node. It is rarely used directly.
• LoadBalancer: asks the cloud provider to create an external load balancer (a machine that spreads incoming traffic, post 12).
• Headless (clusterIP: None): has no single virtual IP. DNS returns the IPs of the individual pods. It is often used with StatefulSets.

Ingress and Gateway API: HTTP traffic from outside

An Ingress routes web traffic (HTTP and HTTPS) from outside the cluster to Services. It chooses the Service by host name and path, and it can handle TLS (the encryption for HTTPS). The Gateway API is the newer and more powerful design for the same job. The Kubernetes project now adds new features only to the Gateway API, and the Ingress API is frozen. An Ingress controller (NGINX, Traefik, Envoy-based gateways or cloud load balancers) is the program that does the actual work. It is an L7 load balancer and reverse proxy (posts 12–13) that Kubernetes manages. "L7" means it understands HTTP. A reverse proxy is a server that receives requests for your servers and passes them on.

ConfigMap and Secret

• ConfigMap: settings that are not secret (feature settings, URLs). They are given to the container as environment variables or files.
• Secret: sensitive values such as passwords. ⚠️ By default they are only base64-encoded. Base64 is a way to write data as text. It is not encryption, and anyone can decode it. So turn on encryption at rest for etcd (data is encrypted on disk), limit access with RBAC (rules about who may do what), and think about syncing secrets from an external secrets manager (post 51).

Namespaces

Namespaces divide one cluster into virtual sections (for example payments, search and staging). Each section has its own resources, access rules (RBAC) and quotas (limits). They are useful for separating teams and environments. But on their own they are not a strong security wall. Add NetworkPolicies and RBAC.

Health checks: liveness, readiness, startup

A probe is a check that Kubernetes runs on a container again and again, for example by calling a URL such as /healthz. The answer decides what Kubernetes does next. There are three kinds.

Common mistake: making the liveness probe check the database. If the database has a short problem, every pod restarts at once. This makes the outage much worse. Liveness should only check "is this process healthy?". Use readiness, with care, for temporary "not ready" states (post 12).

Resources, scheduling and scaling

Requests and limits:

• Requests: the amount of CPU and memory the pod is guaranteed. The scheduler uses it to choose a node for the pod.
• Limits: the most the pod may use. If it goes over the memory limit, the container is killed ("OOMKilled", where OOM means out of memory). If it reaches the CPU limit, it is slowed down (this is called throttling). In the example, 250m means 250 millicores, which is a quarter of one CPU core.
• Setting requests correctly matters for both reliability and cost.

Scaling:

• Horizontal Pod Autoscaler (HPA): adds or removes pods automatically. It looks at CPU, memory or custom metrics (like requests per second or queue length). "Horizontal" means more copies, not bigger ones:

apiVersion: autoscaling/v2kind: HorizontalPodAutoscalermetadata: { name: orders-api }spec:  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: orders-api }  minReplicas: 3  maxReplicas: 30  metrics:    - type: Resource      resource: { name: cpu, target: { type: Utilization, averageUtilization: 65 } }

• Vertical Pod Autoscaler (VPA): changes a pod's requests and limits based on what it really uses. "Vertical" means a bigger pod, not more pods.
• Cluster Autoscaler / Karpenter: tools that add or remove nodes. They add nodes when pods cannot be placed, and remove nodes that are barely used.
• Event-driven autoscaling (KEDA): a tool that scales based on events, such as queue length or Kafka lag (how far a consumer is behind). It can even scale down to zero pods.

Spreading for availability: use topology spread constraints or pod anti-affinity (rules that keep pods apart) to spread replicas across nodes and availability zones. An availability zone is one or more separate data centres inside one region, with their own power and network. This way, one failure does not take out every replica (post 40). A PodDisruptionBudget limits how many replicas planned maintenance may remove (evict) at the same time. Bin-packing means fitting many pods tightly onto few nodes to save money.

Storage

• Volumes attach storage to pods. A plain volume may disappear with the pod.
• PersistentVolume (PV): a piece of storage that lives on after the pod is gone (like a cloud disk).
• PersistentVolumeClaim (PVC): a pod's request for storage ("I need 50 GB of fast SSD").
• StorageClass: defines types of storage and creates volumes on demand.

You can run databases on Kubernetes, often with operators (explained below). But many teams choose managed databases outside the cluster because they are simpler.

Security basics

• RBAC (role-based access control) decides who can do what through the API. "Who" can be people or service accounts (identities for programs).
• NetworkPolicies control which pods may talk to which. By default, every pod can talk to every other pod.
• Pod security: run as non-root, with a read-only root file system and only the Linux capabilities you need (post 55).
• Admission policies (tools like Kyverno or OPA Gatekeeper) check every new object and reject unsafe ones.
• Keep the cluster and nodes patched, and scan images.

The ecosystem

• Helm: a package manager for Kubernetes (like npm for your cluster). It bundles YAML files into reusable, configurable packages called "charts".
• Kustomize: keeps one base set of YAML and adds small changes on top for each environment (it is built into kubectl).
• Operators: controllers that contain expert knowledge about running complex software ("how to run PostgreSQL or Kafka"). They add new object types to Kubernetes with Custom Resource Definitions (CRDs).
• GitOps (Argo CD, Flux): you keep the desired state in Git, and a controller keeps the cluster the same as the repository (post 58).
• Service meshes (Istio, Linkerd): a layer of helper proxies that gives services mTLS (both sides prove who they are and encrypt the traffic), traffic control and observability (the ability to see what is happening) between services (posts 51 and 54).

Do you need Kubernetes?

Kubernetes is powerful, but it is complex. It is a good fit when you have:

• many services and teams,
• a need for portability across clouds or on-premises,
• a platform team to run it,
• workloads that benefit from bin-packing, auto-scaling and self-healing (automatic restart and replacement of failed parts).

It may not be a good fit (yet) when you have:

• a small app or small team,
• or a simpler managed platform (a PaaS, serverless, or a managed container service like AWS ECS/Fargate or Google Cloud Run) that would do the job with far less work to run it (post 57).