Hướng dẫn khắc phục lỗi FailedScheduling Kubernetes hiệu quả

FailedScheduling trong Kubernetes là trạng thái cho biết scheduler không thể tìm được node phù hợp để đặt Pod, khiến Pod bị giữ ở trạng thái Pending thay vì chuyển sang Running. Đây là một trong những tình huống gây đau đầu nhất vì khiến các dịch vụ mới không thể khởi động, gây gián đoạn quy trình triển khai. Bài viết này được mình tổng hợp từ kinh nghiệm vận hành hàng trăm hệ thống Cloud Native, giúp bạn nhanh chóng chẩn đoán chính xác nguyên nhân và áp dụng các biện pháp xử lý triệt để nhất, thay vì chỉ giải quyết phần ngọn của vấn đề.

Những điểm chính

• Quan điểm của mình: FailedScheduling là một cơ chế bảo vệ thông minh của Kubernetes nhằm đảm bảo sự ổn định của cụm, ngăn chặn việc triển khai các ứng dụng vào những môi trường không đủ điều kiện vận hành.
• Khái niệm FailedScheduling: Hiểu rõ FailedScheduling là lỗi khi scheduler không tìm được node phù hợp, giúp bạn nhanh chóng xác định nguyên nhân khiến Pod bị kẹt ở trạng thái Pending.
• Nguyên nhân phổ biến: Nắm vững các nguyên nhân phổ biến từ thiếu tài nguyên đến các ràng buộc không khớp, giúp bạn có một danh sách kiểm tra hiệu quả để khoanh vùng và chẩn đoán sự cố một cách chính xác.
• Cách chẩn đoán: Nắm vững các lệnh kubectl cần thiết, giúp bạn thu thập thông tin và xác định chính xác lý do tại sao Pod không được lên lịch.
• Cách khắc phục: Tìm hiểu các giải pháp hiệu quả, giúp bạn có những hành động cụ thể để giải quyết triệt để sự cố và đưa Pod vào trạng thái Running.
• Giới thiệu Vietnix: Biết đến Vietnix là nhà cung cấp dịch vụ Enterprise Cloud Server giúp bạn có một nền tảng hạ tầng vững chắc để loại bỏ các rủi ro về hạ tầng cho Kubernetes.
• Câu hỏi thường gặp: Giải đáp các thắc mắc liên quan đến FailedScheduling Kubernetes.

FailedScheduling Kubernetes là gì?

FailedScheduling trong Kubernetes là lỗi xảy ra khi scheduler không tìm thấy node phù hợp để đặt Pod mới, dẫn đến Pod ở trạng thái Pending kéo dài. Lỗi này xuất hiện trong phần Events của Pod khi kiểm tra bằng lệnh kubectl describe pod <pod-name>, thường hiển thị thông báo như “0/X nodes are available: X Insufficient cpu, Y Insufficient memory” hoặc các lý do liên quan đến ràng buộc.

Nguyên nhân phổ biến gây lỗi FailedScheduling

Lỗi FailedScheduling trong Kubernetes xuất hiện khi scheduler không tìm được node phù hợp do thiếu tài nguyên hoặc các ràng buộc cấu hình không khớp. Các nguyên nhân chính có thể kể đến như:

• Thiếu hụt tài nguyên: Đây là nguyên nhân hàng đầu. Mỗi Pod khi khởi tạo đều khai báo mức tài nguyên requests (CPU và Memory) cần thiết. Nếu tổng số tài nguyên trống trên mọi Node đều thấp hơn mức Pod yêu cầu, Pod sẽ không được lập lịch.
• Node Selector hoặc Node Affinity không khớp: Quản trị viên thường dùng nodeSelector hoặc affinity để ép Pod chạy trên các Node có gán nhãn cụ thể (ví dụ: disktype=ssd). Nếu không có Node nào mang nhãn tương ứng, lỗi FailedScheduling sẽ xuất hiện.
• Pod không vượt qua được Taints và Tolerations: Các node trong cụm đang được gắn nhãn Taint để từ chối những Pod không mong muốn. Nếu Pod của bạn không có Toleration tương ứng thì sẽ bị từ chối lên lịch.
• Node bị vô hiệu hóa: Khi quản trị viên đang bảo trì một Node bằng lệnh kubectl cordon, Node đó sẽ bị đánh dấu là Unschedulable. Pod mới sẽ không được phép chạy trên Node này.
• Lỗi ràng buộc Persistent Volume: Nếu Pod yêu cầu một ổ cứng ảo (PVC) đang nằm ở một Zone cụ thể, nhưng Node trống lại nằm ở Zone khác thì Kubernetes sẽ không thể đặt Pod lên Node đó và gây lỗi
• Xung đột cổng mạng: Pod yêu cầu sử dụng một HostPort cố định trên node, nhưng cổng mạng này đã bị một Pod khác trên cùng node đó chiếm dụng.

Chẩn đoán lỗi FailedScheduling

Chẩn đoán lỗi FailedScheduling bắt đầu bằng việc kiểm tra trạng thái Pod qua kubectl get pods để xác định Pod ở trạng thái Pending kéo dài. Bạn sẽ thấu phần Events trong output cung cấp thông báo chi tiết về lý do scheduler loại trừ node. Đồng thời bạn hãy kết hợp kiểm tra node và tài nguyên cluster để xác nhận nguyên nhân cụ thể.

• Kiểm tra trạng thái pod: Chạy kubectl get pods <pod-name> để liệt kê tất cả Pod và xác định Pod nào bị kẹt ở trạng thái Pending lâu bất thường. Sau đó bạn dùng kubectl get pod <pod-name> -o yaml để xem đầy đủ spec của Pod (requests/limits, nodeSelector, affinity…), từ đó đối chiếu với tình trạng tài nguyên và cấu hình hiện tại của cluster.
• Phân tích events pod: Thực hiện kubectl describe pod <pod-name> và tập trung vào phần Events có thông báo FailedScheduling. Tại đây Kubernetes sẽ ghi rõ dạng thông báo như “0/4 nodes are available” kèm lý do cụ thể (ví dụ: “Insufficient cpu”, “node(s) had taint” hoặc “no nodes match pod affinity”), bạn có thể dựa vào số node bị loại bởi từng lý do để ưu tiên xử lý đúng vấn đề.
• Đánh giá tài nguyên node: Sử dụng kubectl describe nodes để xem tổng quan CPU, memory,… trên từng node, bao gồm mục Allocated resources và Available. Dựa vào đó, bạn so sánh requests của Pod với phần tài nguyên còn trống trên node để xác định có thật sự thiếu CPU/memory/storage hay không.
• Xem labels và Taints Node: Chạy kubectl get nodes --show-labels để liệt kê toàn bộ labels, rồi đối chiếu với nodeSelector/affinity trong Pod spec xem có khớp hay không. Tiếp theo bạn dùng lệnh kubectl describe node <node-name> để kiểm tra các taints và trạng thái như SchedulingDisabled=true. Nếu taint không có toleration tương ứng, node đó sẽ bị loại khỏi danh sách node đủ điều kiện.
• Kiểm tra PVC và storage: Nếu Pod gắn volume thì bạn hãy dùng kubectl describe pvc <pvc-name> để xem PVC có đang ở trạng thái Pending không và đọc phần Events kèm theo. Các lỗi thường gặp là không tìm được PV phù hợp với storageClass hoặc dung lượng, khiến PVC chưa được bind và scheduler không thể lên lịch Pod vì volume chưa sẵn sàng.

Bổ sung tài nguyên cho hệ thống

Nếu hệ thống báo lỗi thiếu CPU hoặc RAM, bạn cần cung cấp thêm không gian cho Pod. Bạn có thể mở rộng cụm bằng cách thêm node mới vào hệ thống. Nếu không thể nâng cấp hạ tầng ngay lập tức thì bạn hãy xóa bớt các Pod không còn sử dụng để giải phóng tài nguyên.

Giảm yêu cầu tài nguyên pod

Nếu ứng dụng thực tế không cần nhiều tài nguyên đến vậy thì bạn có thể chỉnh sửa Pod spec giảm requests/limits CPU, memory cho phù hợp với dung lượng node thực tế từ kubectl describe nodes. Bạn dùng lệnh kubectl top pods để xác định Pod tiêu thụ nhiều tài nguyên trên node và tối ưu hóa chúng trước, sau đó hãy áp dụng thay đổi bằng lệnh kubectl apply -f pod.yaml để scheduler tìm node phù hợp ngay lập tức.

Điều chỉnh Node Selector và Affinity

Bạn kiểm tra labels node hiện có qua kubectl get nodes --show-labels và cập nhật nodeSelector trong Pod spec khớp chính xác key/value. Nếu sử dụng nodeAffinity, bạn sửa preferredDuringSchedulingIgnoredDuringExecution hoặc requiredDuringSchedulingIgnoredDuringExecution cho phù hợp node khả dụng. Với podAntiAffinity xung đột thì bạn cần nới lỏng weight hoặc podAffinityTerm để cho phép lập kế hoạch trên node có Pod tương tự.

Xử lý Taints và Tolerations

Khi Pod bị chặn bởi Taints, bạn cần đồng bộ lại cấu hình. Bạn thêm tolerations vào Pod spec với key, value, operator (Equal/Exists), effect khớp taints trên node từ kubectl describe node. Ví dụ: tolerations: - key: "node-role.kubernetes.io/master" operator: "Exists" effect: "NoSchedule" cho node master. Nếu taint không cần thiết, bạn xóa bằng kubectl taint nodes key=value:NoSchedule- để mở node cho Pod thông thường.

Kích hoạt lại node bị cordon

Bạn dùng kubectl get nodes kết hợp với kubectl describe node <node-name> để xác định node nào đang ở trạng thái SchedulingDisabled=true (bị cordon). Sau đó bạn chạy lệnh kubectl uncordon <node-name> để cho phép scheduler đặt Pod lên node này trở lại, rồi dùng lại kubectl get nodes kiểm tra node đã ở trạng thái Ready trước khi kỳ vọng Pod được lên lịch lại.

Giải quyết PVC Pending

Bạn chạy kubectl describe pvc <pvc-name> để xem chi tiết lý do PVC bị Pending, thường là do storageClassName không khớp hoặc dung lượng yêu cầu lớn hơn các PV hiện có. Từ đó, bạn có thể tạo PV thủ công phù hợp hoặc chỉnh sửa storageClassName trong PVC để cơ chế dynamic provisioning tạo PV mới, và khi PVC chuyển sang trạng thái Bound thì scheduler sẽ có đủ điều kiện để đặt lại Pod.

Mở rộng Cluster Capacity

Khi thực sự thiếu CPU/memory/storage trên toàn cụm, bạn cần bổ sung node mới vào cluster (qua cloud provider hoặc máy chủ on‑premise) để tăng tổng tài nguyên khả dụng. Sau đó có thể triển khai Cluster Autoscaler (ví dụ kubectl apply -f autoscaler.yaml) để tự động thêm/bớt node khi có nhiều Pod Pending và dùng kubectl get nodes theo dõi đến khi các node mới ở trạng thái Ready để Pod được reschedule tự động.

Enterprise Cloud Vietnix: Giải pháp điện toán đám mây cấp cao cho doanh nghiệp

Enterprise Cloud Vietnix là giải pháp IaaS thế hệ mới, mang đến sức mạnh vượt trội cho doanh nghiệp. Hệ thống trang bị 100% ổ cứng NVMe Enterprise cùng CPU AMD EPYC 7773x mạnh mẽ, đảm bảo xử lý dữ liệu siêu tốc và ổn định tuyệt đối. Với cơ chế nhân bản dữ liệu Replicas 3 và khả năng mở rộng linh hoạt, Vietnix giúp tối ưu chi phí vận hành, bảo mật đa lớp và sẵn sàng đồng hành cùng sự tăng trưởng bền vững của mọi dự án.

Thông tin liên hệ:

• Website: https://vietnix.vn/
• Hotline: 1800 1093
• Email: sales@vietnix.com.vn
• Địa chỉ: 265 Hồng Lạc, Phường Bảy Hiền, Thành Phố Hồ Chí Minh

Lỗi FailedScheduling là một tín hiệu quan trọng trong Kubernetes, cho thấy bộ lập lịch không thể tìm thấy một node phù hợp để triển khai Pod, thường do thiếu tài nguyên hoặc các ràng buộc cấu hình không được đáp ứng. Việc thiết lập các yêu cầu tài nguyên hợp lý, quản lý các ràng buộc một cách cẩn thận và có kế hoạch mở rộng cluster sẽ là chìa khóa để phòng tránh hiệu quả lỗi FailedScheduling, đảm bảo các ứng dụng luôn được triển khai một cách liền mạch và đáng tin cậy.