Evicted Pod là gì? Phân tích nguyên nhân và cách khắc phục triệt để

Khi chạy lệnh kubectl get pods và thấy một loạt Pod đang ở trạng thái Evicted dù ứng dụng không hề báo lỗi code, đừng vội hoảng hốt. Đây là dấu hiệu cho thấy chính Node đang cạn kiệt tài nguyên, không phải bản thân ứng dụng của bạn có vấn đề.

Bài viết dưới đây sẽ giải thích chi tiết Evicted Pod là gì, nguyên nhân phổ biến, cách chẩn đoán và hướng dẫn khắc phục triệt để theo từng trường hợp cụ thể.

Evicted Pod là gì?

Evicted Pod thực chất không phải là một trạng thái riêng biệt của Pod, nó là giá trị status.reason mà kubelet gán cho Pod khi buộc phải chấm dứt nó do node-pressure (Node chịu áp lực tài nguyên nghiêm trọng). Trạng thái thực tế của Pod lúc này vẫn được hệ thống ghi nhận là Failed, còn "Evicted" chỉ là dòng chú thích giải thích lý do thất bại.

Trên mỗi Node, tác nhân kubelet liên tục giám sát các chỉ số tài nguyên sống còn như:

- Bộ nhớ (RAM) khả dụng.

- Dung lượng ổ đĩa (Disk) còn trống.

- Số lượng tiến trình (PID) đang hoạt động.

Khi một trong các chỉ số này chạm ngưỡng nguy hiểm, kubelet sẽ chủ động chọn ra một (hoặc nhiều) Pod để "hy sinh" nhằm giải phóng tài nguyên. Quyết định này giúp ngăn chặn tình trạng sập toàn bộ Node, bảo vệ tính ổn định chung của cụm Cluster.

Sơ đồ này minh họa thuật toán Eviction của Kubernetes: 

Một sai lầm phổ biến là đánh đồng trạng thái này với OOMKiIled. OOMKiIled là đòn trừng phạt của nhân Linux giáng xuống một container cụ thể khi nó tiêu thụ bộ nhớ vượt quá giới hạn cấp phép của chính nó. Ngược lại, Evicted Pod là phán quyết của kubelet khi toàn bộ máy chủ Node chịu áp lực tổng thể, bất chấp việc từng container riêng lẻ có vi phạm giới hạn cá nhân hay không. 

Nguyên nhân phổ biến gây ra Evicted Pod

Áp lực bộ nhớ Memory Pressure

Đây là thủ phạm hàng đầu dẫn đến các cuộc đại thanh trừng Pod. Khi tổng lượng RAM mà tất cả các Pod trên một Node cộng dồn lại tiệm cận hoặc vượt qua giới hạn dung lượng vật lý, kubelet sẽ kích hoạt cờ cảnh báo MemoryPressure và bắt đầu dọn dẹp. Tình trạng này thường diễn biến tồi tệ hơn nếu hệ thống có ứng dụng bị lỗi rò rỉ bộ nhớ, khiến mức tiêu thụ RAM phình to liên tục theo thời gian mà không có điểm dừng.

Áp lực lưu trữ Disk Pressure

Máy chủ Node sẽ lâm nguy khi dung lượng ổ cứng trống hoặc số lượng định danh tệp tin inode giảm xuống dưới mức an toàn. Căn nguyên thường xuất phát từ việc các hình ảnh container cũ kỹ tích tụ lâu ngày không được xóa bỏ, hoặc do ứng dụng liên tục ghi nhật ký log mà thiếu đi cơ chế xoay vòng dữ liệu, dẫn đến việc nuốt chửng toàn bộ bộ nhớ lưu trữ cục bộ.

Áp lực tiến trình PID Pressure

Dù tần suất xuất hiện thấp hơn, lỗi này vẫn là một rủi ro lớn đối với các hệ thống sinh ra quá nhiều luồng tiến trình con. Khi số lượng tiến trình vượt quá sức chịu đựng của cấu hình máy chủ, kubelet buộc phải ra tay trục xuất bớt Pod để nhường lại không gian cho các tiến trình hệ thống lõi duy trì hoạt động.

Lỗi cấu hình tài nguyên và rủi ro Overcommit

Khi các Pod không được khai báo rõ ràng thông số tài nguyên yêu cầu, hoặc máy chủ được cấu hình cho phép chạy số lượng Pod vượt quá năng lực phần cứng thực tế, hệ thống sẽ cực kỳ dễ vỡ trước các đợt tăng tải đột ngột. Trong quá trình dọn dẹp, kubelet luôn ưu tiên loại bỏ các Pod đang xài lố tài nguyên so với mức đã cam kết, sau đó mới xét đến mức độ ưu tiên và tỷ lệ sử dụng thực tế.

Cách chẩn đoán Evicted Pod

Để truy quét toàn bộ các Pod đang nằm lại hệ thống với trạng thái bị trục xuất, kỹ sư có thể sử dụng câu lệnh lọc dữ liệu sau:

Sau khi khoanh vùng được nạn nhân, bước tiếp theo là kiểm tra tình trạng sức khỏe của chính máy chủ Node từng chứa Pod đó bằng lệnh kubectl describe node <tên-node>. Hãy cuộn đến phần Conditions. Nếu bạn nhìn thấy cờ MemoryPressure hoặc DiskPressure đang hiển thị trạng thái True, đó là bằng chứng không thể chối cãi cho thấy máy chủ đã hoặc đang chịu áp lực tài nguyên khủng khiếp.

Cần lưu ý rằng, một Pod bị trục xuất sẽ tồn tại trên hệ thống như một tấm bia mộ vô hồn. Nếu Pod đó thuộc quyền quản lý của một bộ điều khiển như Deployment hay ReplicaSet, hệ thống sẽ ngay lập tức sinh ra một bản sao thay thế trên máy chủ khác. Tuy nhiên, cái xác Pod cũ vẫn nằm lỳ trong không gian làm việc, chiếm dụng một suất trong giới hạn tài nguyên đếm số lượng đối tượng cho đến khi bị con người xóa bỏ. Với các Pod chạy tự do không có người quản lý, sẽ không có bất kỳ sự thay thế tự động nào diễn ra.

Cách khắc phục Evicted Pod hiệu quả

Xử lý tình trạng Disk Pressure

Đối phó với sự cố tràn ổ cứng, đội ngũ vận hành cần lập tức dọn dẹp các hình ảnh container dư thừa, thiết lập cơ chế xoay vòng nhật ký nghiêm ngặt để cấm log phình to vô hạn. Nếu sự cố vẫn tái diễn dù đã dọn rác định kỳ, doanh nghiệp bắt buộc phải cân nhắc nâng cấp dung lượng lưu trữ vật lý cho máy chủ.

Khắc phục lỗi Memory Pressure

Khi đối mặt với rào cản bộ nhớ, kỹ sư cần đánh giá lại toàn bộ thông số khai báo tài nguyên của các Pod đang chạy trên Node đó, đảm bảo tổng lượng yêu cầu không bao giờ vượt quá khả năng đáp ứng của phần cứng. Nếu biểu đồ giám sát chỉ ra một ứng dụng cụ thể đang bị rò rỉ bộ nhớ, lập trình viên phải sửa lỗi trực tiếp từ mã nguồn thay vì mù quáng đắp thêm RAM để che đậy vấn đề.

Ngăn chặn tình trạng Overcommit

Nguyên tắc vàng trong quản trị hạ tầng là luôn để dành một khoảng đệm tài nguyên hợp lý trên mỗi máy chủ, tuyệt đối không lấp đầy hệ thống đến sát giới hạn vật lý. Khoảng không gian dự trữ này đóng vai trò như một bộ giảm xóc, giúp máy chủ đủ sức chống đỡ các đợt bùng nổ lưu lượng truy cập mà không phải hoảng loạn trục xuất Pod.

Dọn dẹp các xác Pod tồn đọng

Vì các Pod bị trục xuất không có khả năng tự hủy, chúng sẽ tích tụ thành đống rác công nghệ, chiếm dụng hạn mức tài nguyên của không gian làm việc một cách vô ích. Kỹ sư hệ thống nên thiết lập các tác vụ tự động dọn dẹp định kỳ để duy trì sự gọn gàng và tối ưu cho cụm máy chủ.

Sự thật về Pod Disruption Budget và Node Pressure

Một lầm tưởng cực kỳ tai hại trong giới vận hành là tin rằng việc thiết lập ngân sách gián đoạn Pod sẽ tạo ra tấm khiên bảo vệ ứng dụng khỏi lệnh trục xuất. Trên thực tế, cơ chế bảo vệ này chỉ có tác dụng đối với các hành động gián đoạn tự nguyện, ví dụ như khi quản trị viên chủ động bảo trì máy chủ. Đối với áp lực tài nguyên, đây là một tình huống gián đoạn cưỡng bức. Kubelet sẽ lạnh lùng tiêu diệt Pod bất chấp nó có nằm trong vùng bảo vệ hay không, bởi vì sự sống còn của toàn bộ máy chủ Node luôn được đặt lên hàng đầu.

Câu hỏi thường gặp về Evicted Pod

Pod bị trục xuất có tự động được hệ thống thay thế không? Có, nhưng điều kiện bắt buộc là Pod đó phải được giám sát bởi các bộ điều khiển như Deployment, ReplicaSet hoặc StatefulSet. Lúc này, bộ điều khiển sẽ lập tức ra lệnh tạo Pod mới trên một máy chủ an toàn hơn. Nếu Pod chạy hoàn toàn độc lập, nó sẽ chết vĩnh viễn mà không có người thừa kế.

Điểm khác biệt cốt lõi giữa Evicted và OOMKiIled là gì? OOMKiIled là đao phủ của nhân Linux, chém gục một container ngay giây phút nó tiêu thụ RAM vượt quá định mức cá nhân. Evicted là quyết định chiến lược của kubelet, chọn hy sinh một số Pod để giải cứu toàn bộ máy chủ đang chìm trong khủng hoảng tài nguyên, bất kể bản thân các Pod đó có sống đúng luật hay không.

Có bắt buộc phải xóa thủ công các Pod ở trạng thái Evicted không? Việc dọn dẹp là cực kỳ cần thiết. Những cái xác này không tự bốc hơi, chúng ở lại như một bản ghi lịch sử lỗi và âm thầm bòn rút hạn mức số lượng đối tượng của không gian làm việc. Xóa bỏ chúng giúp môi trường quản trị luôn sạch sẽ và chính xác.

Kết luận

Evicted Pod là hồi chuông cảnh báo về rủi ro ở cấp độ nền tảng máy chủ chứ không đơn thuần là lỗi của một đoạn mã lập trình. Việc khắc phục triệt để đòi hỏi kỹ sư phải có tầm nhìn bao quát về tổng thể tài nguyên thay vì chỉ chúi mũi vào cấu hình của một vùng chứa đơn lẻ. Hiểu rõ lằn ranh giữa Evicted và OOMKiIled, kết hợp với các hệ thống cảnh báo sớm về áp lực bộ nhớ và ổ đĩa, sẽ giúp đội ngũ vận hành dập tắt nguy cơ gián đoạn dịch vụ từ trong trứng nước.

Việc tự mình canh gác tài nguyên, tinh chỉnh ngưỡng an toàn và xử lý hậu quả trục xuất trên một cụm Kubernetes tự xây dựng là một bài toán ngốn rất nhiều nhân lực và chi phí. Viettel Dedicated Kubernetes Service vDKS là nền tảng quản trị Kubernetes đẳng cấp do Viettel IDC cung cấp, mang đến một hệ sinh thái hạ tầng được quản lý toàn diện. Với sức mạnh giám sát tài nguyên máy chủ theo thời gian thực và đội ngũ hỗ trợ kỹ thuật tinh nhuệ, giải pháp này giúp doanh nghiệp rũ bỏ hoàn toàn nỗi lo gián đoạn hạ tầng, dồn toàn lực kiến tạo những giá trị phần mềm đột phá.

Liên hệ dịch vụ của Viettel IDC tại https://viettelidc.com.vn/viettel-kubernetes-service