Kubernetes Fundamentals and Architecture

Cloud and DevOps pathAvailable

Read Kubernetes as a control system: declarations describe desired state, controllers act, and status plus events provide evidence.

Difficulty: Intermediate
Time: 100 min
Practice: Diagnose a workload that is not ready
Assessment: Knowledge check

Before you start

Who is this for?

For operations learners who already understand Linux processes, containers, and basic networking.

Prerequisites

Docker and container fundamentals
Basic YAML
Basic service and port concepts

What you'll be able to do

Describe control-plane and node responsibilities
Choose a workload and service object
Understand labels and selectors
Read status and events
Diagnose common scheduling and readiness failures

Practical outcome

You can explain why a pod is not ready and choose the next read-only inspection command.

1. Kubernetes is a control system

Kubernetes stores a desired state in its API and continuously works toward it. A deployment may declare three replicas; a controller creates pods, the scheduler assigns them to nodes, and the kubelet asks the container runtime to start them. If a pod fails, the control loop observes the difference and acts again.

The control plane includes the API server, persistent cluster state, scheduler, and controllers. Nodes run workloads through a kubelet and container runtime. kubectl is a client of the API; it is not the scheduler or the runtime.

2. Core objects

Pod: the smallest scheduling unit; usually one application container plus optional sidecars.
Deployment: manages replicated pods and rolling updates.
Service: gives a stable virtual address to selected pods.
ConfigMap: non-secret configuration.
Secret: sensitive configuration with important access-control and encryption considerations.
Namespace: a logical boundary for names, policy, and access—not a complete security boundary by itself.

Labels and selectors connect objects. A Service with a selector that matches no pod can exist successfully while routing no traffic.

3. A small declaration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: bytepath-web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: bytepath-web
  template:
    metadata:
      labels:
        app: bytepath-web
    spec:
      containers:
        - name: web
          image: nginx:1.27-alpine
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: 80
            periodSeconds: 10

The selector and pod label must match. The readiness probe controls whether a pod receives Service traffic; it does not restart a container. A liveness probe has a different purpose and should not be used as a substitute for understanding startup time.

4. Read-only inspection

Use a disposable cluster or approved lab:

kubectl get nodes
kubectl get deploy,pods,svc
kubectl describe pod <pod-name>
kubectl get events --sort-by=.lastTimestamp
kubectl logs <pod-name> --all-containers
kubectl get pod <pod-name> -o yaml

Start with status and events. Then compare image, command, environment, volume, selector, and probe configuration. Do not delete production workloads as a first diagnostic step.

5. Common failure patterns

Pending: insufficient resources, an unmatched node selector, taints, or a missing volume.
ImagePullBackOff: wrong image/tag, registry access, or credentials.
CrashLoopBackOff: the process exits, configuration is invalid, or a dependency is unavailable.
Running but not Ready: the readiness endpoint, port, path, or startup timing is wrong.
Service has no endpoints: selector labels do not match ready pods.
Traffic reaches a Service but not the app: check target port, container listener, NetworkPolicy, and application logs.

6. Safe rollout thinking

A rolling update changes replicas gradually. Define readiness, resource requests, and a rollback plan before changing an image. Keep manifests in version control and review the rendered difference. Secrets should not be committed as plain text.

Practical lab

In a local cluster, deploy the example, inspect the pods and Service, then deliberately change the selector so it matches no pods. Observe the difference between a healthy Deployment and a Service with no endpoints. Restore the selector and verify traffic only after the pods report Ready.

What you should be able to do now

You should be able to describe the control loop, distinguish pod readiness from process liveness, and use status, events, logs, and selectors to narrow a failure.