Po co wyłączać swap na kubernetes


35

Od Kubernetes 1.8 wydaje się, że muszę wyłączyć swap na moich węzłach (lub ustawić --fail-swap-onna false).

Nie mogę znaleźć technicznego powodu, dla którego Kubernetes nalega na wyłączenie wymiany. Czy to ze względu na wydajność? Względy bezpieczeństwa? Dlaczego przyczyna tego nie jest udokumentowana?

Odpowiedzi:


28

Ideą kubernetes jest ciasne pakowanie instancji tak, aby maksymalnie wykorzystać 100%. Wszystkie wdrożenia powinny być przypięte limitami procesora / pamięci. Więc jeśli program planujący wysyła moduł do maszyny, nigdy nie powinien używać zamiany. Nie chcesz zamieniać, bo to spowolni.

Jest to głównie wydajność.


2
Tak, pomysł polega na tym, że węzeł ma do dyspozycji tylko 3 gigabajty ... a twój nowy kapsułka chce 4 ... pójdzie na inny węzeł.
Mike

Nie ma to dla mnie większego sensu, na pewno możesz spakować swoje węzły nieco dalej, pozwalając systemowi operacyjnemu zamienić niektóre rzadko używane strony pamięci w zamian, bez pogorszenia wydajności w zauważalny sposób?
Frederik Baetens

13

Powodem tego jest, jak rozumiem, to, że kubelet nie jest przeznaczony do obsługi sytuacji wymiany, a zespół Kubernetes nie planuje tego zaimplementować, ponieważ celem jest dopasowanie strąków do pamięci hosta.

z tego numeru

Obsługa wymiany nie jest trywialna. Gwarantowane strąki nigdy nie powinny wymagać wymiany. Pękające kapsułki powinny spełniać swoje żądania bez potrzeby wymiany. Strąki BestEffort nie mają gwarancji. W kubelku brakuje obecnie sprytów, aby zapewnić odpowiednią ilość przewidywalnego zachowania w różnych strąkach.


10

Nieprawidłowe użycie zamiany TL; DR to tylko leniwy hack, który pokazuje słabe zrozumienie podsystemów pamięci i brak podstawowych umiejętności administrowania systemami. Projektowanie usług infrastrukturalnych i niezrozumienie tych systemów zakończy się niepowodzeniem.

Mam więc komentarz na ten temat, wydaje mi się to raczej lenistwem niż cechą lub wymaganiem. Jest absolutnie możliwe, aby poprawnie obsługiwać swap, analizować pamięć i określać, jak właściwie korzystać z podsystemu pamięci bez uderzania w swap. Wokół tego zbudowana jest litania narzędzi i możesz zagwarantować, że proces nie wykorzysta swap dość łatwo, więc punkt wydajności jest nieprawidłowy. To po prostu leniwe kodowanie, aby nie wkładać tego oprzyrządowania, a ogólnie całkowite usunięcie swapów będzie ze szkodą dla wydajności systemu. Kluczem tutaj jest prawidłowe korzystanie z niego. Zgadzam się, że zamiana zasobników na dyski wpłynie na wydajność, jednak istnieje wiele rzeczy, które należy wymienić na dysk.

Ponadto jądro Linuksa zostało zaprojektowane tak, aby wykorzystywać swap, a całkowite wyłączenie go będzie miało negatywne konsekwencje. Lepszym sposobem na poradzenie sobie z tym byłoby przypięcie zasobników do pamięci głównej i niedopuszczenie do zamiany na dysk, zmniejszenie ciśnienia pamięci podręcznej VFS, aby nie zamieniało się, chyba że jest to absolutnie konieczne, a nawet wtedy można spowodować zawieść MALLOC w przypadku wyczerpania pamięci głównej.

W zależności od procesów w pojemnikach, w których uszkodzenie pojemnika lub jego zabicie przez zabójcę OOM może spowodować katastrofalne skutki. Rozumiem jednak, że procesy uruchomione w tych kontenerach powinny idealnie być bezstanowe i efemeryczne, ale w ciągu 20 lat działania systemów nie widziałem, by wszyscy w 100% stosowali zamierzony projekt.

Co więcej, nie uwzględnia to przyszłych technologii, takich jak pamięć nieulotna, oraz nowszych systemów pamięci, takich jak intel xpoint, które można wykorzystać do znacznego rozszerzenia pamięci głównej za pomocą hybrydowych systemów dyskowych / pamięci. W tego rodzaju systemach mogą używać ich bezpośrednio jako dodatkowej pamięci głównej lub wykorzystywać pliki wymiany w celu rozszerzenia pamięci głównej z niewielkim wpływem na wydajność.


2
Bardzo wątpię, że opiekunowie projektu kubernetes są leniwi. Żaden z argumentów nie wydaje się być w kontekście kontenerowego ekosystemu działającego w kubernetes.
spuder

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.