Giới thiệu và Kiến trúcIntroduction and Architecture

Part of the Kubernetes Roadmap knowledge base.

Overview

Kubernetes (K8s) is an open-source platform for automating the deployment, scaling, and operation of containerized applications across a fleet of machines. It was originally designed at Google — descended from an internal system called Borg — open-sourced in 2014, and is now the flagship project of the Cloud Native Computing Foundation (CNCF). The name comes from the Greek word for “helmsman”; “K8s” is a numeronym (K, eight letters, s).

To see why Kubernetes exists, follow the arc of application packaging. Bare-metal ran one app per server — wasteful and slow to provision. Virtual machines packed several isolated OSes onto one host, but each VM carries a full guest OS: heavy, slow to boot, big to ship. Containers (Docker, 2013) share the host kernel and package only the app plus its dependencies — a container image is small, starts in milliseconds, and runs identically on a laptop, in CI, and in production. Containers solved packaging. But once you have hundreds of containers spread across dozens of nodes, a new class of problems appears: which node should each container run on? What happens when a container crashes, or a whole node dies? How do you roll out a new version without downtime, roll it back if it breaks, scale replicas with load, let containers find and talk to each other, and attach storage and configuration? This is orchestration, and it is exactly the gap Kubernetes fills.

The alternative to an orchestrator is a pile of brittle bespoke scripts: placement logic, health checks, restart loops, rolling-deploy shell scripts, service-discovery hacks. Kubernetes turns every one of those operational concerns into a declarative API primitive. You describe the destination; the platform figures out the route and keeps you there.

A mental model

Kubernetes is best understood as a control-loop machine. Everything is an object stored in a database (etcd); every object has a spec (what you want) and a status (what actually is). Controllers continuously watch objects and work to make status match spec. kubectl apply does not do anything imperatively — it records your intent, and controllers make it real. Internalize this one idea and most of Kubernetes’ behavior — self-healing, rollouts, autoscaling, GitOps — stops being magic and becomes obvious.

Fundamentals

The declarative model and desired state

Traditional automation is imperative: you issue commands (“start this container”, “add a replica”, “restart that process”). If a command is missed, if a machine reboots, or if a step half-fails, the system drifts and you must reason about how it got here to fix it.

Kubernetes is declarative: you submit the desired end state (“I want 3 replicas of image web:1.4.2 behind a load balancer”), and the system’s job is to make reality match — and to keep it matching. This is the difference between a to-do list and a thermostat. A thermostat doesn’t fire a one-shot “heat up” command; it continuously compares the room temperature (actual) to the target (desired) and acts until they agree, then keeps watching.

This design is level-triggered, not edge-triggered. Controllers don’t react to individual events (“a pod was deleted”); they repeatedly re-derive the correct action from current state (“desired 3, actual 2, therefore create one”). That is why Kubernetes recovers cleanly from missed events, controller restarts, and partial failures: it never depends on having seen a particular event — it always re-reads the world and converges.

Cluster architecture

A Kubernetes cluster is split into two planes: the control plane (the brain — makes global decisions and stores state) and the worker nodes (the muscle — run your containers). In production these run on separate machines; managed offerings (EKS, GKE, AKS) run the control plane for you.

Control plane components:

• kube-apiserver — the front door and the only component anything else talks to. Every read and write — from kubectl, from controllers, from kubelets — goes through this REST API. It handles authentication (who are you?), authorization (RBAC — are you allowed?), and admission control (validating/mutating webhooks that can reject or rewrite requests). It is the only component that talks to etcd directly. It is stateless and horizontally scalable.
• etcd — a distributed, strongly consistent key-value store (Raft consensus) that holds the entire cluster state: every object, its spec, and its status. etcd is the source of truth — lose it and you lose the cluster, so back it up and run an odd number of members (3 or 5) for quorum.
• kube-scheduler — watches for newly created Pods with no assigned node and picks one for each, based on resource requests, node affinity/anti-affinity, Pod affinity/anti-affinity, taints/tolerations, and topology spread constraints. It only decides where; it never runs anything itself.
• kube-controller-manager — a single binary running many built-in control loops: the Deployment, ReplicaSet, Node, Job, EndpointSlice, and namespace controllers, among others. Each loop drives actual state toward desired state.
• cloud-controller-manager — the seam between Kubernetes and a cloud provider. It runs the loops that provision cloud load balancers for LoadBalancer Services, manage node lifecycle against the cloud’s instance API, and configure routes and volumes. Splitting this out lets Kubernetes core stay cloud-agnostic.

Node components (on every worker):

• kubelet — the node’s agent. It watches the API server for Pods scheduled to its node, tells the container runtime to pull images and run containers, mounts volumes, and continuously reports Pod and node status back. It runs the liveness/readiness/startup probes. The kubelet manages containers created by Kubernetes only — not arbitrary containers.
• kube-proxy — maintains the network rules (iptables, IPVS, or eBPF) that make Service virtual IPs work: traffic to a Service’s ClusterIP is load-balanced across its backend Pods. Some CNI plugins (Cilium) can replace kube-proxy entirely.
• Container runtime — the software that actually runs containers, spoken to over the CRI (Container Runtime Interface). The common implementations are containerd and CRI-O. Docker’s built-in shim (dockershim) was removed in Kubernetes v1.24 — Docker-built images still run fine (they’re OCI images), but the runtime under the kubelet is now containerd/CRI-O.
• CNI plugin — Calico, Cilium, Flannel, and others implement Pod networking per the CNI (Container Network Interface) spec, giving every Pod a routable IP so Pods can reach each other flat across nodes.

The objects/resources model

Everything you manage in Kubernetes is an object — a persisted record of intent. Every object shares the same four top-level fields:

The API is grouped and versioned. Groups namespace related kinds (apps, batch, networking.k8s.io); versions graduate through alpha → beta → stable (v1). Deprecated API versions are eventually removed, which is a recurring upgrade concern — a manifest using a removed apiVersion will be rejected after an upgrade.

Labels and selectors are the loose-coupling glue of the whole system. A label is an arbitrary key: value on an object’s metadata (app: web, tier: backend). A selector matches objects by their labels. A Service finds its Pods by selector; a Deployment owns the Pods whose labels match its selector. Nothing is wired by hard reference — it’s all matched by labels, which is what makes the system so composable. Annotations look similar (key: value) but are for non-identifying metadata that tools read (build info, config-hash, ingress controller settings); you never select on annotations.

kubectl and kubeconfig

kubectl is the primary CLI — a thin client over the API server. It reads its connection details from a kubeconfig file (default ~/.kube/config), which bundles three lists plus a current selection:

• clusters — API server URLs and their CA certificates.
• users — credentials (client cert, token, or an exec plugin that fetches a cloud token).
• contexts — a named triple of (cluster, user, namespace). The current-context is the one active now.

Switching context is how you move between clusters or default namespaces without retyping flags:

kubectl config get-contexts                 # list contexts, * marks current
kubectl config use-context prod-eks         # switch clusters
kubectl config set-context --current --namespace=payments   # change default ns

Tools like kubectx/kubens make this even faster. Treat kubeconfig as a credential — it grants cluster access.

Namespaces

A namespace is a virtual cluster inside a physical cluster — a scope for names and a boundary for policy. Object names must be unique within a namespace, not across the whole cluster, so web in dev and web in prod coexist. Namespaces are where you attach RBAC (who can do what here), ResourceQuota (how much CPU/memory/objects this namespace may use), and LimitRange (default and max requests/limits per Pod). Every cluster ships with default, kube-system (control-plane add-ons), kube-public, and kube-node-lease. Note that not everything is namespaced: Nodes, PersistentVolumes, Namespaces themselves, and ClusterRoles are cluster-scoped.

Key Concepts

How a kubectl apply request flows through the system

Following one command end-to-end ties every component together. Suppose you run kubectl apply -f deployment.yaml for a 3-replica Deployment:

1. kubectl reads the YAML, resolves the API endpoint and credentials from kubeconfig, and sends an HTTP PATCH/POST to the kube-apiserver.
2. The API server authenticates the caller, runs authorization (RBAC: may this user create Deployments here?), then admission control — mutating webhooks may inject defaults (e.g. a sidecar), validating webhooks may reject the object (e.g. “no :latest images”). The object is validated against its schema.
3. The API server persists the Deployment object to etcd. At this point the imperative part is over — nothing has been “run” yet. The object simply exists with a spec and an empty status.
4. The Deployment controller (in kube-controller-manager) is watching Deployments. It sees a new one with 0 ReplicaSets and creates a ReplicaSet object (another write to the API/etcd).
5. The ReplicaSet controller sees a ReplicaSet wanting 3 replicas and 0 existing, so it creates 3 Pod objects — still just records in etcd, each with no assigned node (nodeName empty).
6. The scheduler is watching for unscheduled Pods. For each, it filters and scores nodes and writes the chosen nodeName back onto the Pod (a binding).
7. On each chosen node, the kubelet sees a Pod now bound to it, calls the container runtime (via CRI) to pull images and start containers, sets up networking (via CNI), mounts volumes, and starts running probes.
8. As containers come up, the kubelet updates each Pod’s status back through the API server into etcd. The ReplicaSet and Deployment controllers observe the statuses and update their own — status.readyReplicas climbs to 3, and the Deployment reports Available.

Notice: no component gave orders down a chain. Each watched the API, saw a gap between desired and actual, and acted. That is the reconciliation model in motion.

Example: a minimal manifest

The smallest useful object is a single Pod, but in practice you almost always declare a Deployment (which manages Pods for you). Here is a minimal, readable Deployment plus the Service that exposes it:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 3                      # desired state: keep 3 Pods running
  selector:
    matchLabels:
      app: web                     # this Deployment owns Pods with app=web
  template:                        # the Pod template stamped out for each replica
    metadata:
      labels:
        app: web                   # MUST match the selector above
    spec:
      containers:
        - name: web
          image: nginx:1.27        # immutable tag — never :latest
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web                       # route to Pods labelled app=web
  ports:
    - port: 80
      targetPort: 80

The Deployment’s template.metadata.labels must be matched by its spec.selector — that link is what makes the Deployment own those Pods. The Service’s selector independently matches the same label to find endpoints. Change the image to nginx:1.28 and re-apply: the Deployment controller creates a new ReplicaSet and performs a rolling update, all from that one declarative edit.

Core kubectl commands

# Apply / inspect
kubectl apply -f app.yaml                 # create or update from a manifest
kubectl get pods -o wide                  # list Pods, with node and IP
kubectl get deploy,svc                    # multiple kinds at once
kubectl describe pod web-6d4c...          # events + config — why is it Pending/CrashLooping?
kubectl get pod web-6d4c... -o yaml       # full object incl. status

# Debug
kubectl logs -f deploy/web                # stream logs
kubectl logs web-6d4c... --previous       # logs from the last crashed container
kubectl exec -it web-6d4c... -- sh        # shell into a running container
kubectl get events --sort-by=.lastTimestamp

# Manage
kubectl rollout status deploy/web
kubectl rollout undo deploy/web           # roll back to previous ReplicaSet
kubectl scale deploy/web --replicas=5
kubectl delete -f app.yaml

# Context / namespace
kubectl config use-context prod
kubectl get pods -n kube-system
kubectl api-resources                     # every kind, its apiVersion, and short name

kubectl describe and kubectl get events are your first stop for why something isn’t working — the answer is almost always in the events (image pull failures, failed scheduling, probe failures, OOM kills).

Imperative vs declarative usage

kubectl supports imperative commands (kubectl run, kubectl create deployment, kubectl scale, kubectl edit) and declarative ones (kubectl apply -f). Imperative is convenient for exploration and debugging, but declarative apply against files stored in Git is the production-grade approach: the manifests are your source of truth, changes are reviewable, and the cluster can be rebuilt from them. This is the foundation GitOps builds on.

Best Practices

1. Think declaratively, not imperatively. Describe desired state in manifests and let controllers converge; avoid one-off imperative mutations in production. If you can’t reproduce your cluster from files, you don’t really know its state.
2. Store all manifests in Git and apply them, don’t edit live. kubectl apply/GitOps over kubectl edit. The repository is the source of truth; the cluster should reflect a reviewed, committed state.
3. Understand the API object shape (apiVersion/kind/metadata/spec/status) before reaching for tools. Helm and Kustomize just generate these objects — you can’t debug what they produce if the primitives are a mystery.
4. Pin apiVersion deliberately and track deprecations. APIs get removed across releases; run tools like pluto or heed kubectl deprecation warnings so an upgrade doesn’t reject your manifests.
5. Never use the latest image tag. Deploy immutable, versioned tags (or digests) so rollouts, rollbacks, and audits are reproducible and meaningful.
6. Use namespaces to partition teams and environments, and attach RBAC, ResourceQuota, and LimitRange to each so a mistake in one namespace can’t consume the cluster.
7. Apply least-privilege RBAC from day one. Grant narrow Roles bound to specific ServiceAccounts/users; never hand out cluster-admin casually.
8. Treat kubeconfig as a secret and use explicit contexts. Name contexts clearly (prod-eks, staging), confirm the current context before destructive commands, and keep prod credentials separate from dev.
9. Label everything consistently. Adopt the recommended app.kubernetes.io/* labels; selectors, dashboards, and cost allocation all depend on a clean, predictable labeling scheme.
10. Use annotations for metadata, labels for selection. Don’t overload labels with data you’ll never select on (build SHAs, URLs) — that belongs in annotations.
11. Protect and back up etcd. It is the entire cluster state; run an odd-sized quorum, encrypt secrets at rest, and take (and test-restore) snapshots — on managed clusters this is the provider’s job, but know where the line is.
12. Prefer managed control planes (EKS/GKE/AKS) unless you have a reason not to. Running and patching the API server and etcd yourself is real, ongoing work; let the provider own it and focus on workloads.
13. Learn to read events first. When something is stuck, kubectl describe and kubectl get events almost always contain the reason (ImagePullBackOff, FailedScheduling, OOMKilled) — reach for them before guessing.
14. Keep the control plane and workloads mentally separate. The scheduler decides where, the kubelet runs, the API server is the only front door — knowing which component owns a behavior makes troubleshooting far faster.

References

• Kubernetes documentation
• What is Kubernetes?
• Kubernetes components
• Kubernetes API concepts
• Understanding Kubernetes objects
• Nodes · Control plane / node communication
• The kubelet · Container Runtime Interface (CRI)
• Namespaces
• Labels and selectors
• Organizing cluster access using kubeconfig files
• kubectl overview & cheat sheet
• etcd documentation
• CNCF landscape
• Book: Kubernetes Up & Running (Hightower, Burns, Beda — O’Reilly)
• roadmap.sh — Kubernetes