Wiki.Quizz.vn

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Learning Kubernetes: Why, What, How, and the Theory Behind It ======

A structured guide for building real understanding of Kubernetes (K8s) — not just memorizing commands, but understanding the problems it solves and the ideas it's built on.

----

===== 1. WHY — The Problem Kubernetes Solves =====

Before learning any tool, understand what pain it removes.

==== 1.1 The world before Kubernetes ====

  * Applications used to run on a few big servers. Scaling meant buying bigger hardware ("scale up").
  * Virtualization (VMs) let you split one machine into many, but VMs are heavy — each carries a full OS.
  * Containers (via Docker, ~2013) made this lighter: package an app + its dependencies into one portable unit that runs the same everywhere.

==== 1.2 The problem containers alone don't solve ====

Once you have containers, new questions appear:

  * If a container crashes, who restarts it?
  * If traffic spikes, who creates more copies (and removes them later)?
  * If a physical server dies, who moves the containers elsewhere?
  * How do hundreds of containers find and talk to each other?
  * How do you roll out a new version without downtime?
  * How do you manage secrets, configuration, and storage consistently across machines?

Doing this manually across a fleet of servers doesn't scale. You need a system that treats a **cluster of machines** as one programmable unit, and constantly works to keep your application in the state you asked for.

==== 1.3 Why Kubernetes specifically ====

  * **Declarative model**: you describe the desired end state ("I want 3 copies of this app running"), not the steps to get there. Kubernetes continuously works to make reality match your declaration.
  * **Self-healing**: it detects failures and corrects them automatically.
  * **Portability**: it runs the same way on AWS, GCP, Azure, bare metal, or your laptop — avoiding vendor lock-in.
  * **Ecosystem**: it became the industry standard (born from Google's internal system, Borg), so most cloud-native tooling assumes Kubernetes underneath.

**Core idea to hold onto:** Kubernetes is an //orchestrator//. Docker/containers give you the packaging; Kubernetes gives you the management of many containers across many machines.

----

===== 2. WHAT — Core Concepts and Theory =====

This is the conceptual model. Understanding this deeply matters more than memorizing YAML syntax.

==== 2.1 The control loop theory (the single most important idea) ====

Kubernetes is built on **control theory** — the same principle behind a thermostat.

  - You declare a **desired state** (e.g., "3 replicas of nginx running").
  - Kubernetes observes the **actual state** of the cluster.
  - A **controller** continuously compares desired vs. actual state.
  - If they differ, the controller takes action to reconcile them.
  - Repeat forever.

This "control loop" (or "reconciliation loop") pattern is used //everywhere// in Kubernetes — it's not one feature, it's the architectural philosophy. Once this clicks, most of Kubernetes' behavior becomes predictable.

==== 2.2 Cluster architecture (the "what exists") ====

A Kubernetes **cluster** = a set of machines (**nodes**), split into two roles:

**Control Plane (the brain)** — makes global decisions, doesn't run your app containers:

  * **API Server**: the front door. Every interaction (kubectl, controllers, dashboards) goes through it. It's the only component that talks to ''etcd''.
  * **etcd**: a distributed key-value store holding the entire cluster state. Think of it as the cluster's single source of truth/database.
  * **Scheduler**: decides //which node// a new pod should run on, based on resource needs, constraints, and node availability.
  * **Controller Manager**: runs the control loops (e.g., ensuring the right number of pod replicas exist).

**Worker Nodes (the muscle)** — where your actual application runs:

  * **Kubelet**: an agent on each node that talks to the API server and ensures containers described for that node are actually running.
  * **Container Runtime**: the software that actually runs containers (e.g., containerd).
  * **Kube-proxy**: handles networking rules so traffic reaches the right pods.

==== 2.3 The object model (the "nouns" of Kubernetes) ====

Everything in Kubernetes is an **object** described in YAML/JSON, stored in etcd. Learn these in this order, smallest to largest:

^ Object ^ What it is ^ Theory / purpose ^
| Pod | The smallest deployable unit. One or more tightly-coupled containers sharing network/storage. | Containers are never scheduled directly — pods are the atomic unit Kubernetes schedules. |
| ReplicaSet | Ensures N copies of a pod are always running. | A direct implementation of the control-loop idea for pod count. |
| Deployment | Manages ReplicaSets; handles rolling updates and rollbacks. | You almost always use Deployments instead of raw Pods/ReplicaSets — it's the standard way to run stateless apps. |
| Service | A stable network identity (IP/DNS name) in front of a changing set of pods. | Pods are mortal — they get replaced and get new IPs. Services solve "how do I reliably reach my app" despite that churn. |
| ConfigMap / Secret | Externalized configuration and sensitive data. | Keeps configuration out of container images, following the "build once, configure per environment" principle. |
| Namespace | A way to partition one cluster into virtual sub-clusters. | Multi-team/multi-environment isolation without separate physical clusters. |
| Volume / PersistentVolume (PV) / PersistentVolumeClaim (PVC) | Storage that can outlive a pod. | Pods are ephemeral; PV/PVC decouples "storage that exists" from "app that requests storage." |
| StatefulSet | Like a Deployment, but for apps needing stable identity/storage (databases, queues). | Solves ordering, stable network names, and stable storage per replica — things stateless Deployments don't guarantee. |
| DaemonSet | Ensures a pod runs on every (or selected) node. | Used for node-level agents: log collectors, monitoring agents, network plugins. |
| Ingress | Rules for routing external HTTP(S) traffic into Services. | Gives you host/path-based routing, TLS termination, etc., at the cluster edge. |

==== 2.4 Labels, selectors, and the "loose coupling" theory ====

Kubernetes objects don't reference each other by hard IDs — they use **labels** (key-value tags) and **selectors** (queries over labels). A Service doesn't say "send traffic to pod-123"; it says "send traffic to any pod labeled ''app: frontend''." This loose coupling is //why// pods can be destroyed and recreated constantly without breaking anything pointing at them.

==== 2.5 Networking theory (the model, not the implementation) ====

Kubernetes assumes a flat network model with these rules:

  * Every pod gets its own IP.
  * Pods can talk to all other pods without NAT, regardless of node.
  * Nodes can talk to all pods.

This is called the **Kubernetes networking model**, and it's implementation-agnostic — a plugin (CNI: Container Network Interface) fulfills these guarantees underneath. You don't need to master CNI internals early, but knowing this model exists explains why Services and DNS "just work" across nodes.

----

===== 3. HOW — Learning Path and Hands-On Practice =====

Theory sticks when paired with doing. Suggested order:

==== Phase 1 — Prerequisites (if shaky) ====

  * Comfort with Linux command line
  * Docker fundamentals: images, containers, ''Dockerfile'', ''docker run'', ''docker build''
  * Basic YAML syntax
  * Basic networking: IP addresses, DNS, ports

==== Phase 2 — Local cluster setup ====

Use a lightweight local cluster (don't start with cloud — remove billing/complexity while learning):

  * **minikube** or **kind** (Kubernetes-in-Docker) — both run a real cluster on your laptop.
  * Install ''kubectl'', the command-line tool for talking to the API server.

==== Phase 3 — Core hands-on exercises (in order) ====

  - Run a single Pod imperatively (''kubectl run''), inspect it (''kubectl describe'', ''kubectl logs'').
  - Write a Pod YAML manifest by hand, ''kubectl apply -f'', and delete/recreate it to see the lifecycle.
  - Create a Deployment; scale it up/down; kill a pod manually and watch it get recreated (this is where the control-loop theory becomes visible).
  - Expose the Deployment with a Service (''ClusterIP'', then ''NodePort'') and understand why the Pod IPs alone weren't enough.
  - Add a ConfigMap and Secret; mount them into a pod as environment variables and as files.
  - Perform a rolling update (change the image tag) and a rollback (''kubectl rollout undo'').
  - Add a PVC to a pod and understand what happens to data when the pod is deleted vs. the PVC.
  - Set up an Ingress controller (e.g., ingress-nginx) and route traffic by hostname/path.
  - Explore resource requests/limits and watch what happens when you exceed them.
  - Look at a StatefulSet example (e.g., a small database) to see stable naming/storage in action.

==== Phase 4 — Operational literacy ====

  * ''kubectl get'', ''describe'', ''logs'', ''exec'', ''port-forward'', ''top'' — the daily-driver commands.
  * Reading events (''kubectl get events'') to debug scheduling/crash issues.
  * Understanding pod lifecycle phases: Pending → Running → Succeeded/Failed, and probes (liveness/readiness/startup).

==== Phase 5 — Beyond the basics ====

  * **Helm**: templating/packaging Kubernetes manifests (the "package manager" for K8s).
  * **Horizontal Pod Autoscaler**: scaling based on metrics — another control loop.
  * **RBAC**: who can do what in the cluster.
  * **Observability**: Prometheus + Grafana for metrics, centralized logging.
  * **GitOps**: tools like ArgoCD/Flux that apply the control-loop idea to deployment itself — git as the source of desired state.
  * A managed cloud cluster (EKS/GKE/AKS) once local concepts are solid, to see how cloud integration (load balancers, storage classes) plugs into the same object model.

----

===== 4. Suggested Mental Model to Keep Reinforcing =====

Every time you learn a new Kubernetes object, ask three questions:

  - **What desired state am I declaring?**
  - **What actual state is being observed and compared against it?**
  - **What controller is reconciling the difference?**

If you can answer those for Deployments, Services, PVCs, and HPAs, you understand Kubernetes' actual design — not just its API surface. Almost every "advanced" feature (operators, custom resources, autoscalers) is the same control-loop pattern applied to a new kind of desired state.

----

===== 5. Quick Reference: Why → What → How Summary =====

^ Term ^ Question it answers ^
| Why | Why can't containers alone manage a distributed system reliably? |
| What | What are the building blocks (Pods, Deployments, Services, etc.) and what theory (control loops, loose coupling) underlies them? |
| How | How do you actually run, expose, configure, and operate an app on a cluster? |

Keep coming back to this table as you go deeper — it's easy to get lost in YAML details and lose sight of the underlying "why."