Kubernetes Node là gì? Bóc tách thành phần Node trong K8s

Kubernetes Node là nơi các Pod thực sự được khởi chạy và vận hành trong cluster. Thay vì quản lý container rời rạc trên từng máy chủ, Kubernetes sử dụng Node như lớp hạ tầng thực thi để phân bổ tài nguyên, giám sát workload và duy trì trạng thái hoạt động của ứng dụng. Bài viết dưới đây sẽ giúp bạn hiểu rõ Kubernetes Node là gì, cách hoạt động và những lỗi phổ biến khi quản lý Node. 

Kubernetes Node là gì?

Kubernetes Node là một máy chủ trong cụm Kubernetes, được dùng để triển khai và chạy các Pod chứa container ứng dụng. Mỗi Node cung cấp tài nguyên như CPU, RAM, lưu trữ và mạng để Kubernetes phân bổ workload và duy trì hoạt động của ứng dụng trong toàn cụm.

Có thể hiểu đơn giản, Control Plane là bộ phận điều phối và ra quyết định trong cụm, còn Node là nơi workload được chạy thực tế. Control Plane quyết định Pod nên được triển khai trên Node nào, sau đó Node sẽ dùng tài nguyên của mình để khởi chạy và vận hành các Pod đó.

Trong một cụm K8s tiêu chuẩn, các Node được chia làm hai loại chính:

• Master Node (Control Plane): Chứa các thành phần quản lý như API Server, Scheduler, Controller Manager, và etcd. Nhiệm vụ của nó là duy trì trạng thái mong muốn của cụm.
• Data Plane (Worker Node): Chứa các công cụ cần thiết để quản lý mạng (networking) giữa các Pod và chạy các container thực tế. Đây là nơi các ứng dụng của doanh nghiệp sinh sống và vận hành.

Thành phần chính của một Node

Một Kubernetes Node cần chạy các thành phần cốt lõi để nhận lệnh từ Control Plane, khởi chạy Pod và duy trì trạng thái vận hành. Cụ thể, một Node gồm các thành phần chính sau: 

• Kubelet: Agent chính chạy trên mỗi Node, giao tiếp với API Server để nhận PodSpec, đảm bảo container trong Pod được khởi chạy đúng cấu hình, theo dõi trạng thái Node/Pod và báo cáo về Control Plane.
• Container Runtime: Môi trường thực thi container, chịu trách nhiệm kéo image, tạo và chạy container bên trong Pod. Các runtime phổ biến gồm containerd và CRI-O. Docker không còn được hỗ trợ trực tiếp từ Kubernetes v1.24, nhưng image build bằng Docker vẫn dùng được nhờ tuân thủ chuẩn OCI.
• Kube-proxy: Thành phần mạng trên mỗi Node, giúp Service định tuyến traffic đến đúng Pod. Tùy cấu hình cụm, kube-proxy có thể dùng iptables, IPVS hoặc nftables để xử lý traffic và hỗ trợ cân bằng tải nội bộ.

Ngoài ra, Kubernetes Node còn có thể có CNI plugin như Calico, Flannel, Cilium để quản lý mạng container và storage plugin để kết nối với hệ thống lưu trữ.

Cơ chế hoạt động của Kubernetes Node

Việc nắm vững kiến trúc tổng quan của Node mới chỉ là bước khởi đầu. Để tối ưu hóa và làm chủ quá trình vận hành, kỹ sư hệ thống cần hiểu cách thức Node thực thi và chuyển hóa các tệp cấu hình thành các ứng dụng thực tế. Dưới đây là quy trình vận hành chi tiết của một Kubernetes Node trong Cluster:

Bước 1: Đăng ký Node vào Cluster 

Khi một máy chủ được khởi động và Node bắt đầu chạy, Node sẽ tự động đăng ký vào cụm Kubernetes nếu được cấu hình với tùy chọn --register-node=true (mặc định). Kubelet gửi yêu cầu đến API Server, tạo đối tượng Node trong cơ sở dữ liệu etcd cùng với thông tin phần cứng (CPU, RAM, dung lượng ổ cứng), phiên bản hệ điều hành và dung lượng tài nguyên khả dụng.

Lưu ý: Bên cạnh cơ chế tự động (self-registration), quản trị viên vẫn có thể tạo Kubernetes Node thủ công qua file YAML, nhưng cách này ít được sử dụng trong môi trường production.

Bước 2: API Server ghi nhận Node object

Sau khi nhận yêu cầu đăng ký, API Server ghi nhận Node object vào etcd. Tuy nhiên, việc Node object đã tồn tại chưa đồng nghĩa Node sẵn sàng nhận workload. Kubernetes Node chỉ được đánh dấu Ready khi Kubelet thiết lập kết nối ổn định, thực hiện health check nội bộ và gửi báo cáo trạng thái (Node Status) đầu tiên thành công.

Bước 3: Scheduler lập lịch và gán Pod cho Node

Khi bạn triển khai ứng dụng thông qua Deployment, StatefulSet hoặc Pod manifest, API Server sẽ ghi nhận yêu cầu và tạo Pod ở trạng thái Pending, tức là Pod đã tồn tại trong cluster nhưng chưa được gán vào Node cụ thể.

Lúc này, kube-scheduler sẽ phát hiện Pod mới thông qua cơ chế theo dõi và bắt đầu quá trình lập lịch. Quá trình này thường gồm hai giai đoạn chính:

• Filtering: Loại bỏ các Node không đáp ứng điều kiện chạy Pod, chẳng hạn không đủ CPU/RAM, không khớp node selector, vi phạm taints/tolerations hoặc không thỏa mãn affinity/anti-affinity.
• Scoring: Chấm điểm các Node còn lại dựa trên mức độ phù hợp, tài nguyên còn trống, topology và khả năng phân bổ workload cân bằng trong cluster.

Sau khi hoàn tất đánh giá, Kubernetes Node có điểm số phù hợp nhất sẽ được chọn. Scheduler sau đó cập nhật thông tin gán Node cho Pod, thường thông qua trường nodeName trong Pod spec. Quá trình này được gọi là Binding.

Bước 4: Kubelet nhận PodSpec và tạo container 

Sau khi Pod được gán vào Node, Kubelet trên Node đó sẽ phát hiện Pod thuộc trách nhiệm của mình thông qua API Server. Kubelet đọc PodSpec, sau đó yêu cầu Container Runtime như containerd hoặc CRI-O kéo image, tạo container và khởi chạy Pod.

Từ Kubernetes v1.24, dockershim đã bị loại bỏ. Điều này không có nghĩa image Docker không dùng được nữa; các image được build bằng Docker vẫn hoạt động bình thường nếu tuân thủ chuẩn OCI.

Bước 5: Kubelet giám sát Pod và gửi Heartbeat

Trong suốt vòng đời của Pod, kubelet liên tục giám sát trạng thái container thông qua các cơ chế kiểm tra sức khỏe. Nếu container bị lỗi, kubelet có thể tự khởi động lại theo restartPolicy. Đồng thời, kubelet định kỳ gửi heartbeat, thông tin tài nguyên và trạng thái Node/Pod về API Server.

Bước 6: Kube-proxy thiết lập quy tắc mạng

Kube-proxy trên mỗi Node theo dõi thông tin Service và EndpointSlice từ API Server, sau đó cập nhật các quy tắc mạng để traffic từ Service được chuyển đến đúng Pod backend. 

Các trạng thái thường gặp của Kubernetes Node 

Khi chạy lệnh kubectl get nodes, người dùng có thể bắt gặp những trạng thái phổ biến sau: 

• Ready: Node đang hoạt động bình thường, toàn bộ thành phần đang chạy ổn định và Node sẵn sàng nhận Pod mới. 
• NotReady: Node không sẵn sàng chạy workload, thường do lỗi kubelet, container runtime, mạng hoặc mất kết nối với API Server.
• Unknown: Control Plane không xác định được trạng thái Node, thường do Node ngừng gửi heartbeat hoặc mất liên lạc với cụm.
• SchedulingDisabled: Node bị chặn không cho schedule Pod mới, thường dùng khi bảo trì hoặc xử lý sự cố. Pod đang chạy không bị dừng tự động.

Lỗi phổ biến liên quan đến Kubernetes Node 

Mặc dù có cơ chế tự phục hồi, Kubernetes vẫn có thể phát sinh một số sự cố khiến Node không còn sẵn sàng chạy workload. Dưới đây là những lỗi thường gặp liên quan đến Kubernetes Node và cách xử lý cơ bản.

Node NotReady

Node NotReady là một trong những lỗi phổ biến nhất khi vận hành Kubernetes Node. Trạng thái này cho biết Node không còn đủ điều kiện để nhận workload mới, thường do kubelet, container runtime, mạng hoặc tài nguyên hệ thống gặp vấn đề.

Nguyên nhân thường gặp:

• Kubelet trên Node bị crash hoặc không khởi động được
• Node bị mất kết nối mạng với Control Plane
• Container runtime (containerd, CRI-O) gặp sự cố
• Tài nguyên Node cạn kiệt (MemoryPressure hoặc DiskPressure kéo dài)

Cách xử lý: 

kubectl describe node <node-name>
systemctl status kubelet
journalctl -xeu kubelet
systemctl restart kubelet

Pod bị Pending

Pod ở trạng thái Pending nghĩa là Kubernetes đã nhận yêu cầu tạo Pod nhưng chưa thể đặt Pod lên bất kỳ Node nào. Đây là lỗi liên quan đến Kubernetes Node rất thường gặp khi cluster thiếu tài nguyên hoặc cấu hình scheduling chưa phù hợp.

Nguyên nhân thường gặp:

• Không có Node nào đủ tài nguyên (CPU/RAM) để đáp ứng yêu cầu của Pod
• Node Selector hoặc Affinity rules trong PodSpec quá chặt, không khớp với bất kỳ Node nào
• Cluster đang bị thiếu Node, cần scale out thêm Worker Node
• Taint trên Node không có Toleration tương ứng trong Pod definition

Cách xử lý:

kubectl describe pod <pod-name>
kubectl describe nodes | grep -A5 "Allocated resources"
kubectl describe node <node-name> | grep Taints

MemoryPressure/OOMKilled

MemoryPressure xảy ra khi Node sắp hết RAM, còn OOMKilled xảy ra khi container bị kill vì sử dụng bộ nhớ vượt quá giới hạn cho phép. Hai lỗi này thường đi cùng nhau trong các hệ thống có nhiều Pod chạy trên cùng một Kubernetes Node.

Nguyên nhân thường gặp: Pod không đặt requests/limits, memory limit quá thấp, ứng dụng bị rò rỉ bộ nhớ (memory leak) hoặc Node đang chạy quá nhiều workload so với tài nguyên thực tế.

Cách xử lý: 

Kiểm tra Pod tiêu thụ nhiều bộ nhớ, điều chỉnh memory requests/limits, tối ưu ứng dụng và bổ sung Node nếu tổng tài nguyên cluster không còn đủ.

kubectl top pods --all-namespaces
kubectl describe node <node-name>

DiskPressure và Eviction

DiskPressure xảy ra khi dung lượng ổ đĩa trên Node gần đầy. Khi đó, kubelet có thể chủ động evict một số Pod để bảo vệ Node khỏi mất ổn định. Dấu hiệu thường gặp là Pod bị xóa đột ngột hoặc trong event xuất hiện thông báo eviction.

Nguyên nhân thường gặp: 

• Container image tích lũy qua nhiều lần deploy
• Log của container không được quản lý và rotate đúng cách
• Dữ liệu tạm thời của ứng dụng ghi vào ephemeral storage quá nhiều

Cách xử lý:

kubectl describe node <node-name>
df -h
du -sh /var/lib/containerd/*
crictl rmi --prune

Lỗi CNI Plugin 

Plugin mạng container (Container Network Interface - CNI) chịu trách nhiệm cấp network cho Pod. Khi CNI lỗi, Pod có thể khởi động nhưng không giao tiếp được với Pod khác, không truy cập được Service hoặc không kết nối được ra ngoài Internet.

Nguyên nhân thường gặp: CNI plugin (Flannel, Calico, Cilium...) chưa được cài đặt đúng, hoặc cấu hình network bị xung đột sau khi nâng cấp K8s.

Cách xử lý: 

kubectl get pods -n kube-system
kubectl logs -n kube-system <cni-pod-name>

Câu hỏi thường gặp: Các node trong Kubernetes

Một cụm Kubernetes có thể có tối đa bao nhiêu node?

Theo tài liệu chính thức của Kubernetes, một cluster được thiết kế để hỗ trợ tối đa 5.000 Node. Tuy nhiên, đây là ngưỡng kỹ thuật trong điều kiện lý tưởng, không phải con số Kubernetes Node mặc định mà mọi cụm Kubernetes đều đạt được.

Trong thực tế, quy mô cluster còn phụ thuộc vào nền tảng triển khai, cấu hình Control Plane, hiệu năng etcd và băng thông mạng. Trong môi trường production, phần lớn các cụm thường được triển khai ở quy mô vài chục đến vài trăm node thay vì đẩy sát tới ngưỡng tối đa. 

Một node có thể chứa tối đa bao nhiêu pod?

Theo khuyến nghị chính thức từ Kubernetes, mỗi node được thiết kế để chạy tối đa 110 pod. Tuy nhiên, con số này không phải là “giới hạn cuối cùng” bắt buộc với mọi môi trường. Thực tế, bạn hoàn toàn có thể điều chỉnh giới hạn này thông qua tham số --max-pods trong cấu hình của Kubelet. 

Tuy nhiên, trước khi tăng số lượng Pod trên một Node, cần đánh giá kỹ tài nguyên hệ thống, năng lực mạng và khả năng đáp ứng của CNI plugin để tránh quá tải khi vận hành.

Kubernetes Cluster, Node và Pod liên hệ với nhau như thế nào?

Kubernetes Cluster là toàn bộ cụm Kubernetes, bao gồm các máy chủ tham gia vào hệ thống. Bên trong Cluster có nhiều Node, mỗi Node là một máy chủ vật lý hoặc máy ảo dùng để chạy workload. Trên mỗi Kubernetes Node có thể chạy nhiều Pod, và bên trong mỗi Pod sẽ chứa một hoặc nhiều container ứng dụng.

Có thể hình dung theo thứ tự phân cấp như sau:

Hy vọng bài viết đã giúp bạn hiểu rõ Kubernetes Node là gì và vai trò của Node trong quá trình chạy Pod. Tóm lại, Node là lớp hạ tầng thực thi, nơi ứng dụng container thực sự được triển khai và vận hành. Hiểu rõ cách Node đăng ký, nhận Pod, giám sát trạng thái và xử lý mạng sẽ giúp đội ngũ vận hành dễ mở rộng cluster, xử lý sự cố và tối ưu tài nguyên hơn trong môi trường production.

VNPT Kubernetes Service (K8s) giúp doanh nghiệp đơn giản hóa quá trình triển khai Kubernetes, giảm áp lực vận hành và dễ dàng mở rộng theo nhu cầu thực tế. Liên hệ đội ngũ kỹ thuật VNPT Cloud để dùng thử và bắt đầu hành trình Cloud Native ngay hôm nay.