☸️ Kubernetes workflow learning dashboard

Khi bạn chạy kubectl apply -f manifest.yaml, chuyện gì thật sự diễn ra?

Hãy hình dung Kubernetes như một bộ máy điều phối rất kỷ luật: bạn không nói “hãy chạy container này ngay”, bạn nói “đây là trạng thái tôi muốn”, rồi cả hệ thống cùng phối hợp để biến mong muốn đó thành Running Pod.

Mục tiêu học

Nắm được luồng từ kubectl đến Running Pod, hiểu ai gửi gì, ai phản hồi gì, và vì sao Kubernetes vận hành theo kiểu declarative.

7 bước Từ YAML đến Pod
6 thành phần Phối hợp qua API và watch
1 control loop Luôn kéo thực tế về desired state
Core idea State is stored, controllers keep chasing it

1. Visual flow diagram

Sơ đồ tổng thể của hành trình request. Bấm vào từng khối để xem giải thích nhanh.

Interactive diagram
⌨️

kubectl

Gửi request từ manifest YAML

🛂

API Server

Validate, authorize, persist

🗃️

etcd

Lưu desired state nhất quán

🧭

Scheduler

Chọn Node phù hợp

🧰

kubelet

Thi hành Pod spec trên Node

📦

Container Runtime

Tạo container thực tế

🟢

Running Pod

Trạng thái mong muốn thành hiện thực

kubectl

Đây là điểm bắt đầu. Người dùng áp dụng manifest YAML, và kubectl gửi HTTP request đến kube-apiserver.

Dấu vết giao tiếp

Type: REST API call
Data: YAML được chuyển thành JSON object
Response: Xác nhận object đã được tạo hoặc cập nhật
Click node để xem chi tiết Run Workflow để xem luồng sáng dần Kubernetes chủ yếu vận hành bằng API + watch

2. Giải thích bằng ví dụ đời thực

Hãy xem Kubernetes như một chuỗi vận hành trong một trung tâm xử lý hồ sơ.

Analogy
kubectl = người gửi đơn

Bạn điền manifest YAML như một lá đơn mô tả bạn muốn gì. Bạn không tự chạy vào phòng máy, bạn nộp yêu cầu đúng cửa.

API Server = lễ tân / trung tâm điều phối

Nơi này kiểm tra đơn có hợp lệ không, bạn có quyền nộp không, rồi đưa hồ sơ vào hệ thống chính thức.

etcd = kho lưu trữ hồ sơ

Mọi hồ sơ chuẩn hóa được lưu ở đây. Đây là nguồn sự thật trung tâm để cả hệ thống cùng nhìn vào.

Scheduler = người phân công công việc

Thấy một Pod chưa có nơi chạy, Scheduler nhìn tài nguyên, ràng buộc, policy rồi quyết định giao cho Node nào.

kubelet = quản lý tại chỗ

Khi Node được giao việc, kubelet giống quản lý hiện trường. Nó đọc Pod spec và đảm bảo công việc được làm đúng trên Node đó.

Container Runtime = công nhân thực thi

Đây là phần lao động tay chân: pull image, tạo container, khởi động tiến trình. Kết quả cuối cùng là Running Pod.

3. Nhập vai hội thoại

Một đoạn hội thoại ngắn để thấy các thành phần “nói chuyện” với nhau.

Role play
kubectl “Tôi gửi một request với manifest YAML. Mong muốn là tạo Pod mới.”
API Server “Để tôi kiểm tra schema, admission, authorization. Ổn rồi, tôi ghi desired state vào etcd.”
Scheduler “Tôi đang watch các Pod chưa có Node. Tôi thấy Pod này, và Node A là lựa chọn hợp lý.”
kubelet “Tôi nhận Pod spec đã gán cho Node của tôi. Tôi sẽ gọi Container Runtime để tạo container.”
Container Runtime “Image đã pull xong, container đã start.”
Pod “Tôi đang ở trạng thái Running.”

4. Thực tế kỹ thuật từng bước

Mỗi bước đều có loại giao tiếp, dữ liệu truyền đi và phản hồi quay về.

Real workflow
1

kubectl gửi YAML đến API Server

kubectl apply -f manifest.yaml

▾

kubectl đọc file YAML phía client, chuyển nó thành object phù hợp và gửi lên kube-apiserver bằng HTTP request.

Request typeREST API call như POST, PATCH hoặc PUT tùy tình huống apply/create/update.
Data sentObject spec, metadata, labels, container image, ports, replicas hoặc Pod template.
Response returnedAPI Server trả về object đã được chấp nhận, gồm metadata như resourceVersion, UID, creationTimestamp.
2

API Server validate và ghi vào etcd

Schema, authn/authz, admission, persistence

▾

API Server là cửa chính của control plane. Nó kiểm tra request có đúng định dạng, người gửi có quyền hay không, rồi mới ghi desired state vào etcd.

Request typeNội bộ trong control plane sau khi nhận REST request từ client.
Data sentObject đã chuẩn hóa, có default values và các biến đổi từ admission webhooks nếu có.
Response returnedClient nhận xác nhận object đã được tạo/cập nhật; hệ thống có một desired state mới trong etcd.
3

Scheduler watch các Pod chưa được gán Node

Pod mới xuất hiện nhưng chưa có nơi chạy

▾

Scheduler không cần ai gọi trực tiếp. Nó hoạt động theo mô hình watch, liên tục quan sát các object trong cluster để phát hiện Pod chưa có nodeName.

Request typewatch hoặc list-watch tới API Server.
Data sentThông tin Pod pending, resource requests/limits, affinity/anti-affinity, taints/tolerations, topology constraints.
Response returnedLuồng event cho biết có Pod mới cần scheduling.
4

Scheduler chọn Node và gán Pod

Từ nhiều Node, chọn một nơi phù hợp nhất

▾

Sau khi lọc và chấm điểm các Node, Scheduler chọn đích đến rồi cập nhật kết quả lên API Server. Từ đây Pod đã có “địa chỉ thi hành”.

Request typeREST API update/bind operation tới API Server.
Data sentTên Pod, namespace, Node được chọn, binding information.
Response returnedAPI Server xác nhận Pod đã được bind với một Node cụ thể.
5

kubelet lấy Pod spec dành cho Node của mình

Node agent bắt đầu thi hành desired state

▾

kubelet trên mỗi Node cũng đang watch API Server. Khi thấy Pod được gán cho Node của mình, nó tải Pod spec và chuẩn bị dựng workload.

Request typewatch/list tới API Server và cập nhật status ngược lại.
Data sentPod spec, volume mounts, secrets/config, image refs, probes, environment variables.
Response returnedkubelet gửi lại Pod status như Pending, ContainerCreating, Running.
6

Container Runtime tạo container

Biến spec thành process thực thi

▾

kubelet gọi Container Runtime như containerd hoặc CRI-O thông qua CRI. Runtime sẽ pull image, tạo sandbox, khởi động containers.

Request typeCRI calls giữa kubelet và Container Runtime.
Data sentImage name, container config, command/args, cgroup settings, networking and sandbox info.
Response returnedRuntime trả container ID, trạng thái khởi động, lỗi pull image nếu có.
7

Pod trở thành Running

Desired state bắt đầu khớp với actual state

▾

Khi containers đã start và kubelet cập nhật status, Pod có thể chuyển sang Running. Từ đây các controller vẫn tiếp tục quan sát để đảm bảo trạng thái này được duy trì.

Request typeStatus update từ kubelet lên API Server.
Data sentPod phase, container statuses, readiness/liveness condition, start time.
Response returnedCluster state phản ánh rằng Pod đang chạy; người dùng có thể thấy qua kubectl get pods.

5. Mở rộng kiến thức

Những ý rất đáng biết để hiểu Kubernetes sâu hơn, không chỉ thuộc luồng.

Advanced insight
Declarative vs Imperative

Imperative là nói hệ thống phải làm từng động tác cụ thể. Declarative là khai báo trạng thái mong muốn, ví dụ “tôi muốn có 3 replicas”. Kubernetes thiên về declarative: bạn mô tả đích đến, control plane tự lo đường đi.

Control loop là trái tim của Kubernetes

Controllers luôn so sánh desired state với actual state. Nếu lệch nhau, chúng tạo hành động để kéo thực tế quay về mục tiêu. Vì vậy cluster giống một bộ máy tự chỉnh hơn là một script chạy một lần rồi thôi.

Vì sao etcd consistency quan trọng

etcd là nơi giữ state cốt lõi của cluster. Nếu dữ liệu ở đây không nhất quán, các thành phần khác sẽ nhìn thấy “sự thật” khác nhau, và cả dàn nhạc điều phối sẽ lệch nhịp. Tính nhất quán giúp quyết định scheduling, status và reconciliation đáng tin cậy.

Nếu kubelet fail thì sao?

Nếu kubelet trên một Node ngừng báo cáo, Node có thể chuyển sang trạng thái không khỏe. Sau ngưỡng timeout, control plane có thể đánh giá Node gặp vấn đề, và workloads có thể được tạo lại ở nơi khác tùy controller và policy liên quan.

Watch mechanism giúp hệ thống phản ứng nhanh

Thay vì liên tục hỏi đi hỏi lại “có gì mới chưa?”, nhiều thành phần dùng watch với API Server để nhận event khi object thay đổi. Cách này giảm polling thừa và giúp cluster phản ứng như một bảng điều khiển có dây thần kinh sống.

Gói gọn trong một câu: Kubernetes không chỉ “chạy container”, nó là hệ thống điều hòa trạng thái bằng API, persistence, scheduling và reconciliation.