Kubernetes и kswapd0 злая парочка?

Такое поведение kswapd0 является намеренным и объяснимым.

Хотя вы отключили и удалили файл подкачки и установили для swappiness значение 0, kswapd следит за доступной памятью. Это позволяет вам использовать почти всю память, не предпринимая никаких действий. Но как только доступная память упадет до критически низкого значения (низкие страницы для зоны Нормальный в /proc/zoneinfo, ~ 4000 страниц размером 4 КБ на моем тестовом сервере) вмешивается kswapd. Это приводит к высокой загрузке ЦП.

Вы можете воспроизвести проблему и изучить ее более детально следующим образом. Вам понадобится инструмент, позволяющий контролировать потребление памяти, например скрипт, предложенный Романом Евстифеевым: ramhog.py

Сценарий заполняет память фрагментами кода ASCII "Z" размером 100 МБ. Для честности эксперимента скрипт запускается на хосте Kubernetes, а не в поде, чтобы k8s не участвовали. Этот скрипт следует запускать на Python3. Он немного изменен, чтобы:

• быть совместимым с версиями Python до 3.6;
• установите блок распределения памяти меньше 4000 страниц памяти (нижние страницы для зоны Normal в / proc / zoneinfo; я установил 10 МБ), чтобы в конечном итоге снижение производительности системы было более заметным.

from time import sleep

print('Press ctrl-c to exit; Press Enter to hog 10MB more')

one = b'Z' * 1024 * 1024  # 1MB hog = []

while True:
    hog.append(one * 10)  # allocate 10MB
    free = ';\t'.join(open('/proc/meminfo').read().split('\n')[1:3])
    print("{}\tPress Enter to hog 10MB more".format(free), end='')
    input()
    sleep(0.1)

Вы можете установить 3 терминальных соединения с тестовой системой, чтобы наблюдать за тем, что происходит:

• запустить скрипт;
• запустить верхнюю команду;
• получить / proc / zoneinfo

Запускаем скрипт:

$ python3 ramhog.py

После нескольких нажатий клавиши Enter (из-за того, что мы установили небольшой фрагмент памяти (10 МБ)), вы заметите, что

в MemAvailable становится все меньше, и ваша система становится все менее и менее отзывчивой: ramhog.py вывод

Бесплатные страницы упадут ниже нижнего водяного знака: бесплатные страницы

Следовательно, kswapd проснется, как и процессы k8s, и загрузка ЦП увеличится до 100%: верхняя

Обратите внимание, что сценарий выполняется отдельно от k8s, и SWAP отключен. Следовательно, и Kubernetes, и kswapd0 в начале теста простаивали. Ходовые стручки не тронули. Хотя со временем нехватка доступной памяти, вызванная третьим приложением, вызывает высокую загрузку процессора: не только kswapd, но и k8s. Это означает, что основная причина - нехватка памяти, но не сами k8s или kswapd.

Как видно из /proc/meminfo вы предоставили MemAvailable становится достаточно низким, из-за чего kswapd просыпается. Пожалуйста, посмотрите на /proc/zoneinfo на вашем сервере тоже.

На самом деле основная причина не в конфликте или несовместимости между k8s и kswap0, а в противоречии между отключенным свопом и нехваткой памяти, что, в свою очередь, вызывает активацию kswapd. Перезагрузка системы временно решит проблему, но рекомендуется добавить больше ОЗУ.

Хорошее объяснение поведения kswapd находится здесь: kswapd использует много циклов процессора

Kubernetes позволяет нам определить, сколько оперативной памяти мы должны оставить для системы Linux, используя evictionHard.memory.available параметр. Этот параметр устанавливается в ConfigMap под названием kubelet-config-1.XX. Если объем оперативной памяти превышает допустимый конфигурацией уровень, Kubernertes начинает убивать поды, чтобы уменьшить их использование.

В моем случае evictionHard.memory.available параметр был установлен слишком низким (100Mi). Таким образом, для системы Linux недостаточно места в ОЗУ, поэтому kswapd0 начинает беспорядок, когда используется слишком много ОЗУ.

После некоторых тестов, чтобы избежать роста kswapd0, я установил evictionHard.memory.available к 800Mi. Процесс kswapd0 больше не мешал.