Kubernetes Là Gì và Vì Sao Cần Orchestration

Nếu bạn đã đi qua series Docker, bạn biết cách đóng gói một ứng dụng thành image và chạy nó thành container. Một container, trên một máy — mọi thứ gọn gàng. Vấn đề bắt đầu khi ứng dụng lớn lên: bạn cần mười bản sao của container để chịu tải, trải trên ba máy chủ, và khi một máy chết thì những container trên đó phải được dựng lại ở máy khác — tự động, lúc 3 giờ sáng, không cần ai thức dậy. Quản lý chuyện đó bằng tay là bất khả thi. Đây chính là khoảng trống mà Kubernetes lấp vào.

Series này học Kubernetes từ nền tảng, thực hành trên minikube — một cluster Kubernetes thu nhỏ chạy ngay trên máy bạn. Ta cố tình không đào quá sâu vào nội tại (cơ chế bên trong etcd, controller runtime, CNI...) — phần đó để dành một series "Kubernetes from scratch" sau. Mục tiêu ở đây: hiểu chắc các khái niệm cốt lõi và làm được việc thật.

Từ container tới cluster: vấn đề thực sự

Docker giải quyết "ứng dụng của tôi chạy thế nào". Nhưng khi lên production, hàng loạt câu hỏi mới xuất hiện mà bản thân Docker không trả lời:

• Một container chết giữa đêm — ai dựng lại nó?
• Tải tăng gấp đôi — ai khởi thêm bản sao, rồi giảm đi khi tải hạ?
• Có 3 máy chủ — container nào nên chạy ở máy nào cho cân?
• Deploy phiên bản mới — làm sao thay dần, không gián đoạn, và lùi lại được nếu hỏng?
• 10 bản sao của một service — gọi chúng qua một địa chỉ ổn định kiểu gì, khi IP từng container thay đổi liên tục?

Trả lời tất cả những câu này một cách tự động chính là việc của một container orchestrator. Kubernetes (thường viết tắt K8s — "K", tám chữ, "s") là orchestrator phổ biến nhất, khởi nguồn từ Google và nay thuộc CNCF (Cloud Native Computing Foundation).

   Docker             →   Kubernetes
   ───────                ──────────
   "Chạy 1 container       "Giữ cho 10 bản sao của container này
    trên máy này"           luôn chạy, trải đều trên cụm máy,
                            tự dựng lại khi chết, gọi được qua
                            một địa chỉ ổn định, deploy không downtime"

Ý tưởng cốt lõi: trạng thái mong muốn (desired state)

Nếu chỉ giữ lại một ý về Kubernetes, hãy giữ ý này. Bạn không ra lệnh cho Kubernetes từng bước kiểu "tạo container, nếu chết thì tạo lại, nếu tải cao thì...". Thay vào đó bạn khai báo trạng thái mong muốn: "tôi muốn luôn có 3 bản sao của ứng dụng này chạy". Rồi Kubernetes tự lo phần còn lại.

Bên trong, một vòng lặp gọi là control loop liên tục so sánh:

   Trạng thái MONG MUỐN   ──►  [ so sánh ]  ◄──   Trạng thái THỰC TẾ
   "muốn 3 bản sao"                                "đang có 2 (1 vừa chết)"
                              │
                              ▼
                    Kubernetes hành động:
                    dựng thêm 1 bản sao → về lại 3

Đây là tư duy khai báo (declarative), không phải mệnh lệnh (imperative) — giống hệt tinh thần của Ansible ở series trước, nhưng áp cho cả vòng đời container ở quy mô cụm. Bạn mô tả "đích đến", hệ thống tự tìm đường tới và giữ ở đó. Container chết, máy chủ hỏng, ai đó lỡ xóa một pod — control loop đều kéo hệ thống về lại đúng trạng thái bạn đã khai báo. Tính chất "tự chữa lành" (self-healing) này không phải phép màu; nó chỉ là vòng lặp so sánh đó chạy mãi không nghỉ.

minikube: cluster để học, ngay trên máy bạn

Một cluster Kubernetes thật cần nhiều máy chủ — quá nặng để dựng chỉ để học. minikube giải quyết: nó dựng một cluster Kubernetes đầy đủ chức năng bên trong một container (hoặc VM) trên máy bạn. Một node, nhưng có đủ control plane thật, API thật, kubectl thật. Mọi khái niệm bạn học ở đây áp y nguyên lên cluster production nhiều node.

   Máy của bạn (Mac/Linux/Windows)
   └── minikube  (1 container "node" qua Docker)
        └── một cluster Kubernetes hoàn chỉnh
             ├── control plane (bộ não)
             └── nơi chạy ứng dụng của bạn

Học xong một bài, minikube delete là xóa sạch — không tốn tiền cloud, không để lại rác. Đây là lý do minikube là điểm khởi đầu chuẩn mực để học K8s, được chính tài liệu kubernetes.io khuyến nghị.

Lộ trình series

Mười lăm bài, đi từ "K8s là gì" tới deploy một ứng dụng nhiều thành phần hoàn chỉnh:

• Nền tảng (Bài 0–4): kiến trúc cluster, cài minikube, rồi ba khối xây dựng đầu tiên — Pod, Deployment, và cách scale/rollout.
• Kết nối & cấu hình (Bài 5–9): Service (địa chỉ ổn định), Namespace/Label, ConfigMap/Secret (tách cấu hình), lưu trữ (PV/PVC), và Ingress (đưa HTTP vào cluster).
• Vận hành (Bài 10–14): health check (probes), giới hạn tài nguyên & autoscaling, các loại workload khác (StatefulSet, DaemonSet, Job), gỡ lỗi, và một dự án capstone.

Xong series, bạn sẽ không chỉ chạy được lệnh kubectl mà hiểu vì sao mỗi đối tượng tồn tại và chúng ghép với nhau ra sao — đủ nền để bước vào Kubernetes production và đi tiếp vào những chủ đề sâu hơn.

Bài 1 mở nắp capo: kiến trúc một cluster Kubernetes gồm những gì, và "bộ não" điều phối mọi thứ hoạt động thế nào.