Tại sao vô hiệu hóa trao đổi trên kubernetes


35

Kể từ Kubernetes 1.8, có vẻ như tôi cần phải vô hiệu hóa trao đổi trên các nút của mình (hoặc được đặt --fail-swap-onthành false).

Tôi không thể tìm thấy lý do kỹ thuật tại sao Kubernetes khẳng định việc hoán đổi bị vô hiệu hóa. Đây có phải là lý do hiệu suất? Lý do an ninh? Tại sao lý do cho điều này không được ghi nhận?

Câu trả lời:


28

Ý tưởng của kubernetes là đóng gói chặt chẽ các trường hợp càng gần 100% được sử dụng càng tốt. Tất cả các triển khai nên được ghim với giới hạn CPU / bộ nhớ. Vì vậy, nếu bộ lập lịch gửi một nhóm đến một máy thì nó không bao giờ nên sử dụng trao đổi. Bạn không muốn trao đổi vì nó sẽ làm mọi thứ chậm lại.

Nó chủ yếu cho hiệu suất.


2
ya ý tưởng là nếu một nút chỉ có 3gig miễn phí để sử dụng .. và pod mới của bạn muốn 4 .. nó sẽ đi trên một nút khác.
Mike

Điều này không có ý nghĩa lắm đối với tôi, chắc chắn bạn có thể đóng gói các nút của mình thêm một chút bằng cách để os đưa một số trang bộ nhớ được sử dụng không thường xuyên vào trao đổi mà không làm tổn hại đến hiệu suất theo cách đáng chú ý?
Frederik Baetens

13

Lý do cho điều này, theo tôi hiểu, là vì kubelet không được thiết kế để xử lý các tình huống hoán đổi và nhóm Kubernetes không có kế hoạch thực hiện điều này vì mục tiêu là các pod phải phù hợp với bộ nhớ của máy chủ.

từ vấn đề này

Hỗ trợ cho trao đổi là không tầm thường. Vỏ được đảm bảo không bao giờ yêu cầu trao đổi. Các nhóm ổn định nên đáp ứng yêu cầu của họ mà không yêu cầu trao đổi. Vỏ BestEffort không có bảo đảm. Các kubelet ngay bây giờ thiếu thông minh để cung cấp đúng số lượng hành vi dự đoán ở đây trên các nhóm.


10

TL; DR không sử dụng hoán đổi đúng cách chỉ là một hack lười biếng thể hiện sự hiểu biết kém về các hệ thống con bộ nhớ và thiếu các kỹ năng quản trị hệ thống cơ bản. Thiết kế các dịch vụ cơ sở hạ tầng và không hiểu các hệ thống này chắc chắn sẽ kết thúc trong thất bại.

Vì vậy, tôi đã có một số bình luận về điều này, điều này có vẻ giống như sự lười biếng đối với tôi hơn là một tính năng hoặc yêu cầu. Hoàn toàn có thể xử lý trao đổi, phân tích bộ nhớ và xác định cách sử dụng đúng hệ thống con bộ nhớ mà không cần trao đổi. Có một loạt các công cụ được xây dựng xung quanh điều này và bạn có thể đảm bảo một quy trình sẽ không sử dụng trao đổi khá dễ dàng vì vậy điểm hiệu suất là không chính xác. Nó chỉ đơn giản là lười mã hóa để không đưa thiết bị này vào và nói chung, việc loại bỏ hoàn toàn trao đổi sẽ gây bất lợi cho hiệu năng hệ thống. Chìa khóa ở đây là sử dụng đúng cách. Tôi sẽ đồng ý rằng việc hoán đổi các nhóm sang đĩa sẽ ảnh hưởng đến hiệu suất, tuy nhiên có một số điều cần được hoán đổi sang đĩa.

Ngoài ra, nhân linux được thiết kế để sử dụng trao đổi và việc vô hiệu hóa hoàn toàn nó sẽ gây ra hậu quả tiêu cực. Cách tốt hơn để xử lý việc này là ghim các pod vào bộ nhớ chính và không cho phép chúng trao đổi vào đĩa, giảm áp suất bộ đệm vfs để nó không trao đổi trừ khi thực sự cần thiết và thậm chí sau đó bạn có thể gây ra các quá trình được ghim thất bại MALLOC trong trường hợp bộ nhớ chính bị cạn kiệt.

Tùy thuộc vào các quy trình trong các thùng chứa có sự thất bại nặng nề của container hoặc bị giết bởi sát thủ OOM có thể dẫn đến một số kết quả khá tai hại. Tuy nhiên, tôi hiểu rằng các quy trình chạy trong các thùng chứa này lý tưởng là không trạng thái và phù du, nhưng trong 20 năm hoạt động của các hệ thống, tôi chưa một lần thấy mọi người tuân theo thiết kế dự định 100% thời gian.

Hơn nữa, điều này không tính đến các công nghệ trong tương lai như bộ nhớ không bay hơi và các hệ thống bộ nhớ mới hơn như intel xpoint có thể được sử dụng để mở rộng bộ nhớ chính đáng kể bằng cách sử dụng các hệ thống đĩa / bộ nhớ lai. Với các loại hệ thống này, họ có thể sử dụng chúng trực tiếp làm bộ nhớ chính bổ sung hoặc sử dụng các tệp hoán đổi để mở rộng bộ nhớ chính với tác động hiệu suất không đáng kể.


2
Tôi rất nghi ngờ những người duy trì dự án kubernetes là lười biếng. Không có đối số nào có vẻ như nằm trong bối cảnh của một hệ sinh thái được đóng gói chạy trong kubernetes.
spuder

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.