Kubernetes on Software Engineering Learning Paths

Core Concepts

Mon, 01 Jan 0001 00:00:00 +0000

Core Concepts#

Understanding what Kubernetes solves, how a cluster is structured, and the fundamental building blocks that everything else rests upon.

What Kubernetes Solves#

Before Kubernetes, deploying containers at scale meant manually managing placement, networking, scaling, and failure recovery. Kubernetes automates all of this:

Problem	Without K8s	With K8s
Container placement	Manual SSH, docker run	Scheduler decides optimal node
Scaling	Write custom scripts	`kubectl scale` or autoscaler
Self-healing	Monitor + restart manually	Automatic restart, reschedule
Service discovery	Hardcode IPs, use Consul	Built-in DNS and Services
Rolling updates	Downtime or custom tooling	Declarative rolling update strategy
Configuration	Baked into image or env files	ConfigMaps, Secrets, mounted at runtime
Storage	Manual volume management	Dynamic provisioning via StorageClasses

Kubernetes provides a declarative API — you describe the desired state, and the system continuously reconciles actual state to match it.

Workloads

Mon, 01 Jan 0001 00:00:00 +0000

Workloads#

Higher-level abstractions that manage pods — ensuring the right number are running, handling updates gracefully, and supporting both stateless and stateful applications.

Workload Resources Overview#

Resource	Use Case	Pod Identity	Scaling
Deployment	Stateless apps (APIs, web servers)	Interchangeable	Horizontal (replicas)
ReplicaSet	Ensures N identical pods run (managed by Deployment)	Interchangeable	Horizontal
DaemonSet	One pod per node (agents, log collectors)	Per-node	Tied to node count
StatefulSet	Stateful apps (databases, queues)	Stable, ordered	Horizontal (ordered)
Job	Run-to-completion tasks (batch, migrations)	Ephemeral	Parallelism setting
CronJob	Scheduled Jobs	Ephemeral	Per schedule

Deployments#

The most common workload resource. A Deployment manages ReplicaSets, which manage Pods.

Networking

Mon, 01 Jan 0001 00:00:00 +0000

Networking#

How pods communicate with each other, how services expose pods to the cluster and the outside world, and how to control traffic flow.

Pod Networking Model#

Kubernetes imposes a flat networking model with three fundamental rules:

Every pod gets its own IP address — no NAT between pods
All pods can communicate with all other pods without NAT (across nodes)
Agents on a node can communicate with all pods on that node

This is implemented by CNI (Container Network Interface) plugins:

Storage

Mon, 01 Jan 0001 00:00:00 +0000

Storage#

Managing persistent and ephemeral data in Kubernetes — from temporary scratch space to durable database volumes, plus configuration and secrets injection.

Volume Types Overview#

Volume Type	Persistence	Use Case
`emptyDir`	Pod lifetime only	Scratch space, inter-container sharing
`hostPath`	Node lifetime	Node-level logs, dev/testing only
`configMap`	Cluster lifetime	Configuration files mounted as volumes
`secret`	Cluster lifetime	Sensitive data mounted as files
`persistentVolumeClaim`	Independent of pod	Databases, stateful workloads
`nfs`	External NFS server	Shared read-write across pods
`csi`	Depends on driver	Any storage backend via CSI standard

Volumes (Ephemeral)#

emptyDir#

Created when a pod is assigned to a node. Deleted when the pod is removed.

Configuration & Scaling

Mon, 01 Jan 0001 00:00:00 +0000

Configuration & Scaling#

Resource management, autoscaling strategies, and fine-grained pod scheduling — controlling where pods run and how much of the cluster they consume.

Resource Requests and Limits#

Every container should declare how much CPU and memory it needs (requests) and the maximum it may consume (limits).

spec:
 containers:
 - name: api
 image: myapp:1.0
 resources:
 requests:
 cpu: "250m" # 0.25 CPU cores (guaranteed minimum)
 memory: "256Mi" # 256 MiB (guaranteed minimum)
 limits:
 cpu: "1000m" # 1 CPU core (throttled beyond this)
 memory: "512Mi" # 512 MiB (OOM-killed beyond this)

Concept	CPU Behavior	Memory Behavior
Request	Guaranteed allocation; used for scheduling	Guaranteed allocation; used for scheduling
Limit	Throttled (not killed) when exceeded	OOM-killed when exceeded
No request set	Best-effort scheduling	Best-effort scheduling
No limit set	Can consume all available CPU	Can consume all available memory

QoS Classes#

Kubernetes assigns a Quality of Service class based on resource declarations:

Helm & Packaging

Mon, 01 Jan 0001 00:00:00 +0000

Helm & Packaging#

Packaging, templating, and managing Kubernetes applications — from Helm charts to Kustomize overlays, and when to use each approach.

Why Packaging Matters#

Raw Kubernetes manifests work for simple deployments, but real applications need:

Parameterisation — different values per environment (dev, staging, prod)
Reusability — deploy the same app pattern across teams/clusters
Versioning — track which version of your manifests are deployed
Dependencies — install prerequisites (databases, message queues) together

Helm Overview#

Helm is the package manager for Kubernetes. It packages manifests into charts, parameterises them with values, and tracks releases.

Security

Mon, 01 Jan 0001 00:00:00 +0000

Security#

Controlling access to the cluster and its resources, securing workloads, managing secrets safely, and hardening the supply chain.

Security Layers#

graph TB
 subgraph Cluster Access
 AUTH[Authentication]
 AUTHZ[Authorization - RBAC]
 ADM[Admission Controllers]
 end
 subgraph Workload Security
 PSS[Pod Security Standards]
 NP[Network Policies]
 SEC[Secrets Management]
 end
 subgraph Supply Chain
 IMG[Image Security]
 SCAN[Vulnerability Scanning]
 SIGN[Image Signing]
 end
 AUTH --> AUTHZ --> ADM --> PSS
 PSS --> NP
 NP --> SEC
 IMG --> SCAN --> SIGN

RBAC (Role-Based Access Control)#

RBAC controls who can do what on which resources. It’s the primary authorization mechanism in Kubernetes.

Operations

Mon, 01 Jan 0001 00:00:00 +0000

Operations#

Running Kubernetes in production requires proficiency in debugging, monitoring, logging, upgrades, and disaster recovery. This section covers day-to-day operational tasks and the tooling that supports them.

Essential kubectl Commands#

Task	Command
List all pods (all namespaces)	`kubectl get pods -A`
Describe a pod (events + config)	`kubectl describe pod <name> -n <ns>`
Get pod logs	`kubectl logs <pod> -n <ns>`
Follow logs in real time	`kubectl logs -f <pod> -n <ns>`
Logs from a previous crash	`kubectl logs <pod> --previous`
Exec into a container	`kubectl exec -it <pod> -- /bin/sh`
Port-forward for local access	`kubectl port-forward svc/<name> 8080:80`
Get events sorted by time	`kubectl get events --sort-by=.metadata.creationTimestamp`
Get resource YAML	`kubectl get pod <name> -o yaml`
Apply a manifest	`kubectl apply -f manifest.yaml`
Dry-run a change	`kubectl apply -f manifest.yaml --dry-run=server`
Scale a deployment	`kubectl scale deployment <name> --replicas=5`
Rollout status	`kubectl rollout status deployment/<name>`
Rollback a deployment	`kubectl rollout undo deployment/<name>`
Top nodes (resource usage)	`kubectl top nodes`
Top pods	`kubectl top pods -A --sort-by=memory`

Debugging Workflow#

When a pod is unhealthy, follow this escalation path: