Bạn có nên đặt giới hạn CPU Kubernetes không?

Quản lý các tài nguyên có sẵn cho Pod và bộ chứa của bạn là bước thực hành tốt nhất để quản trị Kubernetes. Bạn cần ngăn các Pod ngốn CPU và bộ nhớ của cụm một cách tham lam. Việc sử dụng quá mức của một nhóm Pod có thể gây ra tranh chấp tài nguyên làm chậm các vùng chứa lân cận và làm mất ổn định máy chủ của bạn.

Mặc dù vậy, quản lý tài nguyên Kubernetes thường bị hiểu sai. Hai cơ chế được cung cấp để kiểm soát phân bổ: yêu cầu và giới hạn. Điều này dẫn đến bốn cài đặt có thể có cho mỗi Pod, nếu bạn đặt yêu cầu và giới hạn cho cả CPU và bộ nhớ.

Đi theo con đường đơn giản này thường không tối ưu: Tốt nhất nên bỏ qua các giới hạn CPU vì chúng gây hại cho hiệu suất và lãng phí dung lượng dự phòng. Bài viết này sẽ giải thích vấn đề để bạn có thể chạy một cụm hiệu quả hơn.

Cách thức hoạt động của Yêu cầu và Giới hạn

Yêu cầu được sử dụng để lập lịch trình. Các Pod mới sẽ chỉ được phân bổ cho các Nút có thể đáp ứng yêu cầu của chúng. Nếu không có Nút phù hợp, Pod sẽ ở trạng thái Đang chờ xử lý cho đến khi có tài nguyên.

Các giới hạn xác định mức sử dụng tài nguyên tối đa mà Pod được phép. Khi đạt đến giới hạn, Pod không thể sử dụng thêm bất kỳ tài nguyên nào, ngay cả khi có dung lượng dự phòng trên Node của nó. Hiệu quả thực tế của việc đạt đến giới hạn phụ thuộc vào tài nguyên có liên quan: vượt quá giới hạn CPU dẫn đến điều tiết, trong khi vượt quá giới hạn bộ nhớ sẽ khiến trình diệt Pod OOM chấm dứt các quy trình vùng chứa.

Trong ví dụ sau, một Pod với các ràng buộc này sẽ chỉ có lên lịch cho các Nút có thể cung cấp 500m (tương đương 0,5 lõi CPU). Mức tiêu thụ thời gian chạy tối đa của nó có thể lên tới 1000m trước khi điều tiết nếu Nút có sẵn dung lượng.

resources:
  requests:
    cpu: 500m
  limits:
    cpu: 1000m

Tại sao giới hạn CPU lại nguy hiểm

Để hiểu tại sao giới hạn CPU lại có vấn đề, hãy xem xét điều gì sẽ xảy ra nếu một Pod có cài đặt tài nguyên được hiển thị ở trên (yêu cầu 500m, giới hạn 1000m) được triển khai cho Nút lõi tứ với tổng dung lượng CPU là 4000m. Để đơn giản, không có Pod nào khác chạy trên nền tảng Node.

$ kubectl get pods -o wide
NAME            READY       STATUS      RESTARTS    AGE     IP              NODE
demo-pod        1/1         Running     0           1m      10.244.0.185    quad-core-node

Pod lên lịch ngay lập tức cho Node vì yêu cầu 500m được đáp ứng ngay lập tức. Pod chuyển sang trạng thái Running. Tải có thể thấp khi sử dụng CPU khoảng vài trăm milicore.

Sau đó, lưu lượng truy cập đột ngột tăng đột biến: các yêu cầu dồn dập đến và mức sử dụng CPU hiệu quả của Pod tăng vọt lên tới 2000m. Do giới hạn CPU, điều này được giảm xuống còn 1000m. Mặc dù vậy, Node không chạy bất kỳ Pod nào khác, vì vậy nó có thể cung cấp đầy đủ 2000m, nếu Pod không bị giới hạn bởi giới hạn của nó.

Dung lượng của Node đã bị lãng phí và hiệu suất của Pod bị giảm đi một cách không cần thiết. Bỏ qua giới hạn CPU sẽ cho phép Pod sử dụng toàn bộ 4000m, có khả năng đáp ứng tất cả các yêu cầu nhanh hơn gấp bốn lần.

Không có giới hạn vẫn ngăn chặn ăn cắp tài nguyên Pod

Việc bỏ qua các giới hạn CPU không ảnh hưởng đến tính ổn định, miễn là bạn đã đặt các yêu cầu thích hợp trên mỗi Pod. Khi nhiều Pod được triển khai, phần chia sẻ thời gian CPU của mỗi Pod sẽ được chia tỷ lệ theo yêu cầu của nó.

Dưới đây là một ví dụ về những gì xảy ra với hai Pod không giới hạn khi chúng được triển khai cho Nút 8 lõi (8000m) và mỗi Pod đồng thời yêu cầu mức tiêu thụ CPU 100%:

Nếu Nhóm 1 ở trong khoảng thời gian yên tĩnh hơn, thì Nhóm 2 có thể tự do sử dụng nhiều chu kỳ CPU hơn:

Yêu cầu CPU vẫn còn quan trọng

Những ví dụ này chứng minh tại sao các yêu cầu CPU lại quan trọng. Việc đặt các yêu cầu phù hợp sẽ ngăn chặn sự tranh chấp bằng cách đảm bảo các Nhóm chỉ lên lịch cho các Nút có thể hỗ trợ chúng. Nó cũng đảm bảo phân phối có trọng số của các chu kỳ CPU có sẵn khi nhiều Pod đang có nhu cầu gia tăng.

Giới hạn CPU không mang lại những lợi ích này. Chúng chỉ có giá trị trong các tình huống khi bạn muốn điều chỉnh Pod trên một ngưỡng hiệu suất nhất định. Đây hầu như luôn là hành vi không mong muốn; bạn đang khẳng định rằng các Pod khác của bạn sẽ luôn bận, trong khi chúng có thể không hoạt động và tạo ra các chu kỳ CPU dự phòng trong cụm.

Việc không đặt giới hạn cho phép các chu trình đó được sử dụng bởi bất kỳ khối lượng công việc nào cần chúng. Điều này dẫn đến hiệu suất tổng thể tốt hơn vì phần cứng sẵn có không bao giờ bị lãng phí.

Điều gì về bộ nhớ?

Bộ nhớ được quản lý trong Kubernetes bằng cách sử dụng các khái niệm giới hạn và yêu cầu giống nhau. Tuy nhiên, bộ nhớ là một tài nguyên vật lý khác với việc sử dụng CPU, đòi hỏi phương pháp phân bổ riêng. Bộ nhớ không thể nén được: không thể thu hồi bộ nhớ sau khi đã cấp phát cho một quy trình vùng chứa. Các quy trình chia sẻ CPU khi có sẵn nhưng chúng được cung cấp các phần bộ nhớ riêng lẻ.

Đặt yêu cầu và giới hạn giống hệt nhau là phương pháp thực hành tốt nhất để quản lý bộ nhớ Kubernetes. Điều này cho phép bạn dự đoán một cách đáng tin cậy tổng mức tiêu thụ bộ nhớ của tất cả các Nhóm trong cụm của bạn.

Có vẻ hợp lý khi đặt một yêu cầu tương đối thấp với giới hạn cao hơn nhiều. Tuy nhiên, việc sử dụng kỹ thuật này cho nhiều Nhóm có thể gây ra tác động gây mất ổn định: nếu một số Nhóm đạt yêu cầu vượt quá yêu cầu của chúng, dung lượng bộ nhớ của cụm của bạn có thể cạn kiệt. Trình diệt OOM sẽ can thiệp để chấm dứt các quy trình vùng chứa, có khả năng gây gián đoạn khối lượng công việc của bạn. Bất kỳ Pod nào của bạn đều có thể bị nhắm mục tiêu trục xuất, không chỉ Pod gây ra bộ nhớ cạn kiệt.

Việc sử dụng các yêu cầu và giới hạn bằng nhau sẽ ngăn Pod lên lịch trừ khi Nút có thể cung cấp bộ nhớ mà nó yêu cầu. Nó cũng thực thi rằng Pod không thể sử dụng nhiều bộ nhớ hơn mức phân bổ rõ ràng của nó, loại bỏ nguy cơ sử dụng quá mức khi nhiều Pod vượt quá yêu cầu của chúng. Việc sử dụng quá mức sẽ trở nên rõ ràng khi bạn cố gắng lên lịch cho một Nhóm và không có Nút nào có thể đáp ứng yêu cầu bộ nhớ. Lỗi xảy ra sớm hơn và dễ đoán hơn mà không ảnh hưởng đến bất kỳ Nhóm nào khác.

Bản tóm tắt

Kubernetes cho phép bạn phân biệt giữa số lượng tài nguyên mà một vùng chứa đòi hỏivà một giới hạn trên mà nó là cho phép để mở rộng quy mô nhưng không thể vượt quá. Tuy nhiên, cơ chế này ít hữu ích hơn trong thực tế so với cái nhìn đầu tiên.

Việc đặt giới hạn CPU ngăn quá trình của bạn sử dụng dung lượng CPU dự phòng khi có sẵn. Điều này làm giảm hiệu suất một cách không cần thiết khi một Pod có thể đang tạm thời sử dụng các chu kỳ mà không bên nào yêu cầu.

Sử dụng yêu cầu CPU hợp lý để ngăn Pod lập lịch trình cho các Nút vốn đã quá bận rộn để mang lại hiệu suất tốt. Không đặt trường giới hạn để các Nhóm có thể truy cập các tài nguyên bổ sung khi thực hiện các tác vụ đòi hỏi khắt khe vào những thời điểm khả dụng. Cuối cùng, gán cho mỗi Pod một yêu cầu và giới hạn bộ nhớ, đảm bảo sử dụng cùng một giá trị cho cả hai trường. Điều này sẽ ngăn chặn tình trạng cạn kiệt bộ nhớ, tạo ra một môi trường cụm ổn định hơn và có thể dự đoán được.