Giao diện
Module 1: Kubernetes Architecture (Kiến trúc Hệ thống)
🎓 Thông tin Giảng viên
Bài giảng được biên soạn bởi sự hợp tác giữa Giáo sư Tom (MIT) - chuyên gia về Hệ thống Phân tán, và Kỹ sư Raizo (Phó CTO HPN) - người có 10 năm kinh nghiệm vận hành Kubernetes quy mô lớn tại các tập đoàn công nghệ hàng đầu.
Bạn đã thành thạo Docker. Bạn có thể build Image, chạy Container, và phối hợp nhiều service bằng Docker Compose. Nhưng rồi một ngày, bài toán quy mô ập đến: "Làm sao để vận hành 100 container trên 50 máy chủ, tự động mở rộng khi lượng truy cập tăng vọt, và tự động khôi phục khi có máy chủ gặp sự cố?"
Đó là lúc bạn nhận ra: Docker là công cụ tuyệt vời để đóng gói ứng dụng. Nhưng ai sẽ là người chỉ huy đội quân container đó?
Câu trả lời chính là Kubernetes - vị tướng tài ba chỉ huy hạm đội container của bạn.
🐄 Phần 1: Triết lý Vận hành - Thú Cưng vs Gia Súc
Trước khi đi sâu vào các thành phần kỹ thuật, chúng ta cần thấu hiểu một cuộc cách mạng tư duy đã thay đổi hoàn toàn cách vận hành hệ thống hiện đại.
1.1 Kỷ nguyên Server Thú Cưng (The Pet Server Era)
Trong quá khứ, mỗi máy chủ (server) được đối xử nâng niu như thú cưng (Pet):
- Bạn đặt tên riêng cho nó:
web-server-01,db-master-prod. - Bạn chăm sóc kỹ lưỡng: cài đặt thủ công, tinh chỉnh từng cấu hình, cập nhật phần mềm cẩn thận.
- Khi nó "đổ bệnh" (gặp sự cố): bạn thức đêm để chẩn đoán (debug), sửa chữa, và cầu nguyện cho nó "hồi phục".
- Nếu nó "qua đời" (hỏng hoàn toàn): cả đội ngũ đau buồn, gián đoạn dịch vụ (downtime) kéo dài, và phải họp kiểm điểm (postmortem).
Đây là mô hình Snowflake Server - mỗi máy chủ là một bông tuyết độc nhất vô nhị, khó có thể thay thế ngay lập tức.
1.2 Kỷ nguyên Server Gia Súc (The Cattle Server Era)
Điện toán Đám mây (Cloud Native) đã mang đến một hệ tư tưởng mới - xem máy chủ như gia súc (Cattle) trong một trang trại lớn:
- Bạn đánh số thứ tự:
node-001,node-002,node-003... - Bạn không vương vấn tình cảm: chúng được tạo ra hàng loạt từ khuôn mẫu (template), giống hệt nhau.
- Khi một con "ốm": loại bỏ ngay lập tức và thay thế bằng con mới khỏe mạnh. Không cảm xúc.
- Khi cần tăng năng suất: bổ sung thêm 10 con nữa trong vài phút. Hoàn toàn tự động.
💡 Cốt lõi Vấn đề
Pet vs Cattle không phải là sự vô cảm với hạ tầng. Đó là triết lý xây dựng hệ thống Kiên cường (Resilient) - nơi sự cố của một thành phần nhỏ không bao giờ làm sụp đổ cả hệ thống lớn.
1.3 Tại sao Docker đơn lẻ là chưa đủ?
Docker giải quyết xuất sắc bài toán "Works on my machine" (Chạy tốt trên máy tôi). Nhưng ở quy mô Production, bạn sẽ đối mặt với những thách thức mà Docker đơn lẻ không thể giải quyết:
| Vấn đề | Docker đơn lẻ | Cần Orchestrator (Kubernetes) |
|---|---|---|
| Container gặp sự cố | Phải khởi động lại thủ công | Tự động khởi động lại (Auto-restart) |
| Máy chủ quá tải | Phải di dời container thủ công | Tự động điều phối sang máy khác (Scheduling) |
| Traffic tăng đột biến | Phải tạo thêm container bằng tay | Tự động mở rộng dựa trên tải (Auto-scaling) |
| Cập nhật phiên bản | Downtime hoặc script phức tạp | Cập nhật không gián đoạn (Zero-downtime) |
| Kết nối dịch vụ | Cấu hình IP tĩnh hoặc tool ngoài | Tích hợp sẵn DNS & Service Discovery |
Kubernetes chính là "Nhạc trưởng" giải quyết tất cả những vấn đề trên, biến đội quân container hỗn loạn thành một đạo quân tinh nhuệ, có kỷ luật.
🏛️ Phần 2: Control Plane - Tổng Hành Dinh (The Headquarters)
Hãy hình dung Kubernetes Cluster như một Tập đoàn Sản xuất khổng lồ. Mọi tập đoàn đều cần một Tổng Hành Dinh (Headquarters) để đưa ra các quyết định chiến lược.
Trong Kubernetes, đó chính là Control Plane (hay còn gọi là Master Node).
2.1 API Server - Người Gác Cổng (The Gatekeeper)
API Server là cửa ngõ duy nhất để giao tiếp với Tổng Hành Dinh.
Ẩn dụ: Hãy tưởng tượng một tòa tháp văn phòng an ninh cao. Bạn muốn vào họp? Phải qua Lễ Tân. Muốn gửi công văn? Phải qua Lễ Tân. Muốn tra cứu nhân sự? Cũng phải qua Lễ Tân. Không ai được phép đi "cửa sau".
Vai trò cốt lõi:
- Xác thực (Authentication): Kiểm tra bạn là ai (Certificate, Token, User).
- Phân quyền (Authorization): Kiểm tra bạn có quyền thực hiện hành động này không (RBAC).
- Kiểm soát (Admission Control): Thẩm định và sửa đổi yêu cầu trước khi chấp thuận.
- Cổng giao tiếp (API Gateway): Cung cấp chuẩn RESTful API cho mọi thành phần khác kết nối.
┌─────────────────────────────────────────────────────────┐
│ CONTROL PLANE │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 🚪 API SERVER │ │
│ │ "Không qua tôi, không vào được" │ │
│ └─────────────────────────────────────────────────┘ │
│ ▲ ▲ ▲ ▲ │
│ │ │ │ │ │
│ ┌────┴───┐ ┌────┴───┐ ┌────┴───┐ ┌────┴───┐ │
│ │ User │ │ Kubelet│ │ Other │ │ Internal│ │
│ │ (CLI) │ │ (Node) │ │ Tools │ │ Components│ │
│ └────────┘ └────────┘ └────────┘ └────────┘ │
90: └─────────────────────────────────────────────────────────┘⚠️ Lưu ý Bảo mật
API Server là Điểm tiếp nhận duy nhất (Single Point of Entry). Nếu nó bị tấn công, toàn bộ cluster sẽ bị chiếm quyền. Do đó, bảo vệ API Server là ưu tiên số 1 trong bảo mật Kubernetes.
2.2 Scheduler - Trưởng Phòng Nhân sự (The HR Manager)
Scheduler chịu trách nhiệm quyết định công việc nào sẽ được giao cho ai.
Ẩn dụ: Khi có một dự án mới (Pod cần chạy), Trưởng phòng Nhân sự sẽ rà soát danh sách nhân viên (Node) để tìm người phù hợp nhất:
- Nhân viên nào đang rảnh rỗi? (CPU/RAM còn trống).
- Dự án này cần kỹ năng đặc biệt gì? (Node Selector, GPU, SSD).
- Có yêu cầu tránh mặt ai không? (Taints & Tolerations).
Quy trình Điều phối:
- Sàng lọc (Filtering): Loại bỏ các Node không đủ điều kiện (hết RAM, sai hệ điều hành...).
- Chấm điểm (Scoring): Đánh giá các Node còn lại xem ai tối ưu nhất.
- Chỉ định (Binding): Ra quyết định gán Pod cho Node có điểm cao nhất.
┌──────────────────────────────────────────────────────────┐
│ 📋 SCHEDULER │
│ │
│ New Pod Request: "Cần chạy Nginx, 512MB RAM" │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────┐ │
│ │ FILTERING: Loại Node không đủ RAM │ │
│ │ Node-1: ✅ 2GB trống │ │
│ │ Node-2: ❌ 256MB trống (LOẠI) │ │
│ │ Node-3: ✅ 1GB trống │ │
│ └─────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────┐ │
│ │ SCORING: Chấm điểm tối ưu │ │
│ │ Node-1: 85 điểm (tài nguyên dư dả hơn) │ │
│ │ Node-3: 70 điểm │ │
│ └─────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ DECISION: Gán Pod cho Node-1 │
└──────────────────────────────────────────────────────────┘2.3 Controller Manager - Giám Sát Viên Robot (The Robot Supervisor)
Controller Manager là bộ phận đảm bảo trạng thái thực tế luôn khớp với trạng thái mong muốn.
Ẩn dụ: Hãy tưởng tượng một Giám sát viên Robot không bao giờ ngủ, liên tục đi tuần tra:
- "Chỉ thị là phải có 3 nhân viên trực quầy. Hiện tại có mấy người?"
- Nếu chỉ có 2 → Tuyển gấp thêm 1.
- Nếu lỡ có 4 → Cho nghỉ bớt 1.
- Nếu đúng là 3 → Tuyệt vời, tiếp tục giám sát.
Các Controller quan trọng:
| Controller | Nhiệm vụ |
|---|---|
| ReplicaSet Controller | Đảm bảo đủ số lượng bản sao (Replicas) của Pod theo quy định. |
| Node Controller | Theo dõi sức khỏe của các máy chủ Worker. |
| Service Controller | Quản lý Load Balancer để phân phối tải. |
| Endpoint Controller | Cập nhật danh sách IP của các Pods để Service biết đường gọi. |
💡 Cơ chế Cốt lõi
Đây là mô hình Vòng lặp Hòa giải (Reconciliation Loop) - trái tim của Kubernetes. Controller không "ra lệnh" một lần rồi thôi, mà liên tục "điều chỉnh" để thực tế (Reality) khớp với kỳ vọng (Expectation). Vì vậy, Kubernetes được gọi là một Hệ thống Khai báo (Declarative System).
2.4 ETCD - Bộ Não & Két Sắt (The Brain & Vault)
ETCD là Nguồn Chân lý Duy nhất (Single Source of Truth) - nơi lưu trữ TOÀN BỘ trạng thái của cluster.
Ẩn dụ: ETCD vừa là Bộ não (lưu giữ mọi ký ức, cấu hình) vừa là Két sắt (bảo vệ thông tin nhạy cảm). Nếu ETCD mất trí nhớ, cả tập đoàn sẽ tê liệt vì không ai biết mình phải làm gì.
ETCD lưu trữ những gì?
- Cấu hình Cluster.
- Thông tin trạng thái các Node.
- Thông số kỹ thuật của Pods.
- Mật khẩu (Secrets) và Cấu hình ứng dụng (ConfigMaps).
- Quyền truy cập (RBAC).
┌─────────────────────────────────────────────────────────┐
│ 🧠 ETCD │
│ "Nguồn Chân lý Duy nhất (Single Source of Truth)"│
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Key │ Value │ │
│ ├─────────────────────────────────────────────────┤ │
│ │ /registry/pods/nginx-1 │ {spec: ..., status: ...}│ │
│ │ /registry/nodes/node-1 │ {capacity: ..., ...} │ │
│ │ /registry/secrets/db │ {data: encrypted...} │ │
│ │ /registry/services/web │ {clusterIP: 10.0.0.5} │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ⚠️ Chỉ duy nhất API Server được phép đọc/ghi ETCD │
└─────────────────────────────────────────────────────────┘⚠️ Thành phần Trọng yếu
Mất dữ liệu ETCD đồng nghĩa với việc mất toàn bộ Cluster. Do đó, trong môi trường Production, ETCD luôn được chạy theo cụm (cluster 3 hoặc 5 nodes) với quy trình sao lưu (backup) cực kỳ nghiêm ngặt.
🏭 Phần 3: Worker Nodes - Các Nhà Máy Khổng Lồ
Nếu Control Plane là Tổng Hành Dinh ra quyết định, thì Worker Nodes chính là những Nhà máy Sản xuất, nơi công việc thực sự được thực thi.
3.1 Kubelet - Quản đốc Phân xưởng (The Foreman)
Kubelet là đại diện toàn quyền của Control Plane đặt tại mỗi Worker Node.
Ẩn dụ: Mỗi Nhà máy có một ông Quản đốc. Nhiệm vụ của ông là:
- Nhận lệnh sản xuất từ Tổng Hành Dinh (API Server).
- Chỉ đạo công nhân (Container Runtime) vận hành máy móc.
- Báo cáo tiến độ và tình trạng sức khỏe của nhà máy về cấp trên.
Nhiệm vụ cụ thể:
- Đăng ký Node với API Server.
- Lắng nghe API Server để nhận nhiệm vụ chạy Pod.
- Đảm bảo các container trong Pod luôn hoạt động ổn định (Healthy).
- Thực hiện kiểm tra sức khỏe định kỳ (Liveness/Readiness Probes).
┌─────────────────────────────────────────────────────────┐
│ WORKER NODE │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 👷 KUBELET │ │
│ │ "Quản đốc Phân xưởng" │ │
│ └─────────────────────────────────────────────────┘ │
│ │ ▲ │
│ │ Điều khiển │ Báo cáo │
│ ▼ │ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ Container Runtime│ │ API Server │ │
│ │ (Docker/containerd)│ │ (Control Plane) │ │
│ └──────────────────┘ └──────────────────┘ │
234: └─────────────────────────────────────────────────────────┘3.2 Kube-proxy - Bảo vệ Mạng (The Network Guard)
Kube-proxy quản lý các quy tắc giao thông mạng (network rules) trên mỗi Node.
Ẩn dụ: Hãy hình dung Kube-proxy như đội ngũ Bảo vệ & Điều phối giao thông tại cổng Nhà máy. Khi có xe hàng (Request) đến:
- "Anh muốn gặp bộ phận 'Web App' à? Để tôi chỉ đường dẫn anh đến đúng dây chuyền (Pod) đang rảnh."
- Bảo vệ nắm rõ bản đồ tất cả các "phòng ban" và đường đi lối lại trong toàn hệ thống.
Nhiệm vụ cụ thể:
- Duy trì các quy tắc mạng (iptables hoặc IPVS).
- Hiện thực hóa khái niệm Service (ClusterIP, NodePort, LoadBalancer).
- Cân bằng tải (Load balancing) traffic đến các Pods phía sau.
┌─────────────────────────────────────────────────────────┐
│ KUBE-PROXY │
│ │
│ External Request: "Gọi Service web-app:80" │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────┐ │
│ │ Service: web-app │ │
│ │ ClusterIP: 10.96.0.100:80 │ │
│ │ │ │
│ │ Endpoints (Danh sách địa chỉ thực): │ │
│ │ - Pod-1: 10.244.1.5:8080 │ │
│ │ - Pod-2: 10.244.2.8:8080 │ │
│ │ - Pod-3: 10.244.1.9:8080 │ │
│ └─────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Load Balance → Điều hướng tới Pod-2 (Round Robin) │
└─────────────────────────────────────────────────────────┘3.3 Container Runtime - Dây Chuyền Sản Xuất (The Machinery)
Container Runtime là động cơ thực tế để chạy các containers.
Ẩn dụ: Nếu Kubelet là Quản đốc ra lệnh, thì Container Runtime chính là hệ thống Máy móc Dây chuyền trực tiếp thực hiện công đoạn sản xuất. Quản đốc hô: "Chạy container Nginx!", Máy móc lập tức kéo nguyên liệu (Image) về và khởi động quy trình.
Các Container Runtime phổ biến:
| Runtime | Đặc điểm |
|---|---|
| containerd | Nhẹ, chuẩn công nghiệp, được Kubernetes khuyên dùng. |
| CRI-O | Thiết kế chuyên biệt cho Kubernetes, tối giản, hiệu năng cao. |
| Docker Engine | Công nghệ cũ (đã bị loại bỏ vai trò native runtime từ K8s 1.24), nhưng vẫn rất phổ biến ở máy dev. |
💡 Góc kỹ thuật
Kubernetes không giao tiếp trực tiếp với Docker hay containerd. Nó sử dụng Container Runtime Interface (CRI) - một lớp trừu tượng cho phép bạn lắp ghép bất kỳ runtime nào tuân thủ chuẩn CRI vào hệ thống.
🗺️ Phần 4: Bản đồ Kiến trúc Toàn cảnh (Visual Architecture)
Hãy ghép nối tất cả các mảnh ghép lại để thấy bức tranh toàn cảnh về cách một Cluster vận hành.
4.1 Sơ đồ Kiến trúc Kubernetes
Kubernetes Architecture
User / CI-CD
kubectl / API Client
🏛️ CONTROL PLANE (Tổng Hành Dinh)
API ServerNgười Gác Cổng
SchedulerTrưởng phòng HR
Controller ManagerGiám sát viên Robot
ETCDBộ não / Két sắt
🏭 WORKER NODE 1
Kubelet
Kube-proxy
Container Runtime
📦 Pod A
📦 Pod B
🏭 WORKER NODE 2
Kubelet
Kube-proxy
Container Runtime
📦 Pod C
📦 Pod D
4.2 Luồng xử lý: Hành trình của một Request
Khi bạn ra lệnh deploy một ứng dụng, điều gì thực sự diễn ra bên dưới?
Hành trình của một Request
1
👤 User
kubectl apply -f deployment.yaml
→
🚪 API Server
2-4
🚪 API Server
AuthN/AuthZ → Lưu vào ETCD
↔
🧠 ETCD
5-8
🤖 Controller Manager
Phát hiện Deployment mới → Tạo ReplicaSet → Tạo Pod specs
→
🧠 ETCD
9-12
📋 Scheduler
Lọc & Chấm điểm Nodes → Chỉ định Pod vào Node-1
→
🧠 ETCD
13-17
👷 Kubelet
Kéo Image → Chạy Container → Cập nhật trạng thái (Running)
→
⚙️ Container Runtime
🎯 Tổng kết (Key Takeaways)
Trước khi khép lại Module 1, hãy ghi nhớ những khái niệm cốt lõi này, chúng sẽ theo bạn suốt hành trình:
💡 Tóm tắt Kiến trúc
Control Plane (Tổng Hành Dinh) - Quản lý Trạng thái, KHÔNG chạy ứng dụng:
- API Server: Cửa ngõ duy nhất, nơi mọi mệnh lệnh bắt đầu.
- Scheduler: Người phân phối công việc thông minh.
- Controller Manager: Người bảo vệ sự ổn định, tự động sửa lỗi.
- ETCD: Bộ nhớ tuyệt đối, nơi lưu trữ mọi sự thật.
Worker Node (Nhà Máy) - Nơi ứng dụng thực sự chạy:
- Kubelet: Quản đốc mẫn cán, cầu nối giữa Node và Control Plane.
- Kube-proxy: Cảnh sát giao thông mạng.
- Container Runtime: Cỗ máy vận hành container.
⚠️ Thay đổi Tư duy (Mindset Shift)
Kubernetes là hệ thống Declarative (Khai báo), không phải Imperative (Mệnh lệnh).
- Imperative: "Hãy chạy server A, rồi chạy server B, rồi nối mạng..." (Cách cũ).
- Declarative: "Tôi muốn một hệ thống có 3 server web và 1 database." (Cách Kubernetes). Kubernetes sẽ tự động làm mọi việc cần thiết để biến mong muốn đó thành hiện thực và duy trì nó mãi mãi.
🚀 Bước tiếp theo
Bạn đã nắm vững Kiến trúc Tổng quan của Kubernetes - tấm bản đồ để không bị lạc lối trong thế giới container.
Ở Module tiếp theo, chúng ta sẽ bắt tay vào thực chiến với Workload Resources. Bạn sẽ học cách viết những dòng YAML đầu tiên để tạo Pod, Deployments và ReplicaSets. Đó là lúc bạn chính thức nắm quyền chỉ huy hạm đội của mình.
Hẹn gặp lại bạn ở Module 2: Workloads Deep Dive!