📦 Module 01 — Kubernetes Fundamentals

Containers run on any OS that supports the containerization platform. You can also run multiple versions of the same app, each with its own dependencies, side-by-side. Analogy: shipping containers ride on trucks, trains and ships unchanged.

Containers are lightweight and self-contained, so they fit naturally into managed cloud platforms. On AWS that means Amazon EC2, AWS Lambda, Amazon ECS, Amazon EKS, and AWS App Runner — each runs containerized apps with a different operational model.

Because containers are small and start fast, you can scale out by adding more copies and scale in by removing them — without changing your build tools, architecture, or development workflow. Scaling is just "add another instance," not "rebuild the app."

A container image is identical in dev, QA, and prod — only the host OS and infrastructure change. That minimises divergence between environments and integrates cleanly with automated build → test → deploy pipelines.

You describe the result you want, not the steps to produce it. Drawing a rectangle imperatively means drawLine×4; declaratively it's { shape: "rect", w: 300, h: 100 }. Kubernetes manifests are declarative — you say "I want 4 replicas" and let the controller reconcile.

A monolith is one program that does everything: UI, business logic, data. Each app duplicates shared concerns (order history, mailing). A microservice architecture splits the app into many small, independently-deployable services — e.g., one ordering service, one reporting service — each owning its own concerns.

Microservices need to be independently deployable, independently scalable, and portable across environments. Those are exactly the properties containers give you out of the box.

Running 1–2 containers on one host is trivial. Once you move to dozens of hosts and hundreds of containers — let alone production with thousands — you can no longer place, monitor, or restart them manually. That's the problem orchestration solves.

Scheduling & placement · cloud integration · networking · load balancing · storage · security · monitoring · logging. You declare desired state; the orchestrator makes the cluster match it.

All the orchestration concerns — scheduling, scaling, load balancing, deployments — plus a strong community and a declarative API. Kubernetes is the substrate; EKS is the AWS-managed flavour.

A group of one or more containers that share the same network namespace (IP, port space) and can share storage. The smallest deployable unit in Kubernetes — and the basic building block for deployment, scaling and replication.

The YAML specification that describes how to run the containers in a Pod — image, ports, env, volumes. Stored declaratively and submitted to the API server.

They share a network namespace, so they can talk via localhost and shared volumes. They're co-scheduled to the same node and live and die together.

Each Pod gets its own cluster IP. Pods can hit each other directly by IP — but those IPs change when Pods restart, so you almost always go through a Service instead.

A logical collection of Pods plus a stable way to reach them. The Service has its own IP and port; it's continuously updated with the set of Pod IPs that currently match its selector, so callers never need to track individual Pods.

Pod IPs are ephemeral. A Pod crashes → it gets recreated with a new IP. A Service IP is stable and load-balances across whichever Pods currently match its label selector.

A node is a machine (VM or physical) that runs Pods. A Kubernetes cluster is the set of nodes. Pods are always scheduled to exactly one node — containers within a Pod cannot be split across nodes.

In EKS, nodes live in AWS subnets, which live in specific AZs (e.g., us-east-1a, us-east-1b). Spreading nodes across multiple AZs is how you survive an AZ failure. The scheduler can place Pods AZ-aware via topology spread & affinity rules.

The set of components that manage the cluster: schedule Pods, detect failures, react to events. Components: API server, etcd, scheduler, controller manager, cloud controller.

The set of worker nodes that actually run your containerized applications. Each node runs a container runtime, kubelet, and kube-proxy.

A loop that compares desired state (from your manifests) to current state (what's actually running). If they differ, the controller acts to make them match. If they match, it does nothing.

It's the front door of the cluster. Everything — kubectl, kubelet, controllers — talks to the API server. It validates and persists cluster state to etcd, and is the only component that reads/writes etcd.

A consistent, distributed key-value store. It holds the entire cluster state — every Pod spec, every config, every secret. Lose etcd and you lose the cluster's memory.

When a new Pod is created without a node assignment, the scheduler picks one. It uses predicates to filter ineligible nodes and priorities to score the survivors. The highest-scoring node wins.

It runs many built-in controllers in one process — Deployment controller, ReplicaSet controller, Node controller, Endpoint controller, Job controller, and others. Each runs its own control loop.

A controller that integrates with the underlying cloud provider: it manages cloud-specific resources like load balancers, routes, and volumes (on AWS: ELB, EBS attachments, route tables) on behalf of the cluster.

The primary node agent. It watches the API server for Pods assigned to its node, then asks the container runtime to start them. It also reports node and Pod health back to the control plane.

A small per-node process that programs networking rules (iptables / IPVS) so that traffic to a Service IP gets routed to one of its backing Pods. Without it, Services wouldn't actually route traffic.

The software that actually starts, stops, and isolates containers on a node. Kubernetes supports several via the CRI interface; EKS uses containerd by default since Kubernetes v1.24 (Docker Engine is deprecated).

Through the API server. The kubelet on each node watches the API server for Pods assigned to its node. There is no direct controller→kubelet channel — everything is mediated by the API server, which is the cluster's single source of truth.

Predicates are filters: "can this Pod possibly run here?" If no, the node is excluded. Priorities are scores: "of the survivors, which is the best home?" Highest score wins.

The minimum guaranteed CPU and memory a container will get. The scheduler uses requests to pick a node with enough free capacity. Example: cpu: 400m, memory: 600Mi.

The maximum a container is allowed to use. CPU above the limit is throttled; memory above the limit gets the container OOMKilled. Limits are enforced at runtime; requests influence scheduling.

A property of a node that repels Pods. Only Pods that explicitly tolerate the taint can be scheduled there. Example taint: spot=true:NoSchedule means "don't schedule unless you tolerate spot instances."

A property of a Pod that lets it ignore matching taints. Tolerations don't force placement — they only permit it. Pairs with affinity to actually attract.

A Pod rule that attracts the Pod to nodes matching labels. requiredDuringScheduling… is a hard filter (no match → no schedule). preferredDuringScheduling… is a soft score (boost matching nodes but don't require them).

An EBS volume in us-east-1a can't attach to a node in us-east-1b. So the volume binding effectively constrains which nodes are even eligible for the Pod. Similarly, a Pod needing a volume already mounted on node X must go to node X.

Dedicated nodes. Taint a node so generic workloads avoid it; add a matching toleration + affinity to specific Pods so only they land there. Classic use: GPU nodes, spot pools, system add-ons.

The command-line interface for communicating with the Kubernetes API server. It runs on your laptop, your CI agent, anywhere — it just needs network access to a cluster and a kubeconfig.

Through a kubeconfig file, by default at ~/.kube/config. Override the path with the KUBECONFIG env var. Within a file, multiple contexts let you switch clusters with kubectl config use-context.

Lists Pods in the current namespace (default: default). Add -n my-ns to target a different namespace, or -A to see Pods across all namespaces.

Sends the manifest to the API server, which creates or updates the matching object to match the file. Idempotent: running it twice is safe; controllers reconcile to the new desired state.

kubectl create namespace my-ns
Imperative shortcut. The declarative equivalent is a one-line YAML manifest applied with kubectl apply.

You'll see "No resources found in default namespace" — because get pods defaults to default. Run kubectl get pods -n my-ns instead, or set the context's namespace.

A virtual cluster inside a physical cluster. Names must be unique within a namespace, but the same name can exist in different namespaces. Combined with RBAC, namespaces give multi-tenant isolation.

When multiple teams or projects share a cluster. Each team gets its own namespace; RBAC controls who can read/write it. Resource quotas can also be applied per namespace.

An API object storing non-confidential configuration as key-value pairs. Pods mount it as files or read it as env vars. Lets the same container image run in dev and prod with different config.

Same shape as a ConfigMap but for sensitive data (passwords, tokens, keys). Values are stored base64-encoded in the data field — note that base64 is encoding, not encryption. At-rest encryption requires enabling etcd encryption.

So the same image runs unchanged from dev to prod. The image is the artifact; ConfigMaps and Secrets are the environment-specific overlay. This is the Twelve-Factor "config in the environment" principle.

Two common ways: (1) mounted as files in a read-only volume (each key becomes a file); (2) injected as environment variables via envFrom.configMapRef. The Pod's container code reads them like any other file or env var.

A user-defined object type, declared via a Custom Resource Definition (CRD). Extends the Kubernetes API. With a custom controller watching it, you get the same reconcile-loop pattern for your own domain — e.g., a Database CR that provisions RDS.

A bare Pod that dies stays dead. A workload controller re-creates Pods to match the desired count or schedule. Workloads also add features bare Pods don't have — rolling updates, fixed identity, scheduled execution.

A workload that runs a Pod once to completion. Good for batch tasks (DB migration, one-shot data processing). The Job tracks success/failure and will retry failed Pods up to a limit.

A workload that creates Jobs on a schedule, using cron syntax (*/1 * * * * = every minute). It's just a Job factory — each scheduled tick produces a fresh Job which produces a Pod.

A workload that runs one Pod on every node (or every matching node). Used for node-level agents: log collector (Fluent Bit), metrics agent, CSI node plugin, kube-proxy itself. Not supported on AWS Fargate (Fargate has no notion of a shared node).

A workload that keeps a specific number of Pod replicas running. If a Pod dies, the ReplicaSet creates a new one. You rarely manage ReplicaSets directly — Deployments do it for you.

A workload that owns and manages ReplicaSets. You declare a desired state — image version, replica count — and the Deployment controller rolls out changes at a controlled rate. The standard way to run stateless apps.

When you change the Pod template, the Deployment creates a new ReplicaSet for the new version. It scales the new RS up and the old RS down in lockstep, respecting maxSurge and maxUnavailable — never both at once. Old RS sticks around for rollback.

A workload for stateful apps. Pods get stable, ordered identities (mysql-0, mysql-1, …) and stable PersistentVolume bindings. Pods are created, scaled, and updated in order. Pairs with PersistentVolumes for databases, queues, leader-elected systems.

Through the selector field, which matches labels on Pods. The Deployment's template.metadata.labels must match its selector.matchLabels — otherwise the Deployment can't manage the Pods it just created.

Deployment: stateless, interchangeable Pods — web frontends, API servers, workers reading from a queue. StatefulSet: each Pod has identity that matters — databases, Kafka brokers, Zookeeper ensembles, anything that does leader election or stores local data.

Pods. Not containers (those live inside Pods), not Tasks (that's ECS terminology), not ReplicaSets (those manage Pods). Pods are the basic building block for deployment, scaling, and replication.

A logical collection of Pods plus a means to access them. The Service is continuously updated with the current Pod IPs, so callers don't need to track individual Pods. (Not scheduling — that's the scheduler's job. Not DaemonSet — that's per-node. Not ReplicaSet — that's replica count.)