Я запускаю кластер Kubernetes с одним главным / узлом на виртуальной машине CentOS 7, и я понял, что systemd процесс (как PID 1) постоянно использует CPU.
[root@ip-10-0-0-66 ~]# ps aux | head -n2
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 7.7 0.0 129088 7720 ? Ss Jun21 639:41 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
Более того, systemd генерирует миллионы таких строк журнала:
[root@ip-10-0-0-66 ~]# tail -n 10 /var/log/messages
Jun 27 12:49:14 ip-10-0-0-66 systemd: Created slice libcontainer_6148_systemd_test_default.slice.
Jun 27 12:49:14 ip-10-0-0-66 systemd: Removed slice libcontainer_6148_systemd_test_default.slice.
Jun 27 12:49:15 ip-10-0-0-66 systemd: Created slice libcontainer_6155_systemd_test_default.slice.
Jun 27 12:49:15 ip-10-0-0-66 systemd: Removed slice libcontainer_6155_systemd_test_default.slice.
Jun 27 12:49:15 ip-10-0-0-66 systemd: Created slice libcontainer_6155_systemd_test_default.slice.
Jun 27 12:49:15 ip-10-0-0-66 systemd: Removed slice libcontainer_6155_systemd_test_default.slice.
Jun 27 12:49:15 ip-10-0-0-66 systemd: Created slice libcontainer_6162_systemd_test_default.slice.
Jun 27 12:49:15 ip-10-0-0-66 systemd: Removed slice libcontainer_6162_systemd_test_default.slice.
Jun 27 12:49:15 ip-10-0-0-66 systemd: Created slice libcontainer_6162_systemd_test_default.slice.
Jun 27 12:49:15 ip-10-0-0-66 systemd: Removed slice libcontainer_6162_systemd_test_default.slice.
В секунду регистрируется почти 50 строк журнала, которые переполняют /var/logs/messages файл:
[root@ip-10-0-0-66 ~]# sudo wc -l /var/log/messages
5992826 /var/log/messages
[root@ip-10-0-0-66 ~]# sudo cat /var/log/messages | grep 'systemd_test_default' | wc -l
5987033
В конце концов, kubelet процесс также регистрирует такие ошибки:
Jun 27 12:53:37 ip-10-0-0-66 systemd: Removed slice libcontainer_29206_systemd_test_default.slice.
Jun 27 12:53:37 ip-10-0-0-66 systemd: Created slice libcontainer_29206_systemd_test_default.slice.
Jun 27 12:53:37 ip-10-0-0-66 systemd: Removed slice libcontainer_29206_systemd_test_default.slice.
Jun 27 12:53:37 ip-10-0-0-66 kubelet: W0627 12:53:37.447052 5352 watcher.go:87] Error while processing event ("/sys/fs/cgroup/memory/libcontainer_29206_systemd_test_default.slice": 0x40000100 == IN_CREATE|IN_ISDIR): readdirent: no such file or directory
Jun 27 12:53:37 ip-10-0-0-66 kubelet: W0627 12:53:37.447117 5352 watcher.go:87] Error while processing event ("/sys/fs/cgroup/devices/libcontainer_29206_systemd_test_default.slice": 0x40000100 == IN_CREATE|IN_ISDIR): open /sys/fs/cgroup/devices/libcontainer_29206_systemd_test_default.slice: no such file or directory
Jun 27 12:53:37 ip-10-0-0-66 systemd: Created slice libcontainer_29225_systemd_test_default.slice.
Jun 27 12:53:37 ip-10-0-0-66 systemd: Removed slice libcontainer_29225_systemd_test_default.slice.
Jun 27 12:53:37 ip-10-0-0-66 systemd: Created slice libcontainer_29232_systemd_test_default.slice.
Jun 27 12:53:37 ip-10-0-0-66 systemd: Removed slice libcontainer_29232_systemd_test_default.slice.
Как я могу понять, что вызывает это systemd Использование ЦП и сообщения журнала?
Версии:
Конфигурация драйвера Cgroup:
$ docker info | grep -i cgroup
Cgroup Driver: systemd
$ cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS="--cgroup-driver=systemd"
Это известная ошибка в kubernetes. kubelet процесс и не ограничивается только системами на базе CentOS, но любой Linux (включая Ubuntu), где вы используете systemd как cgroup-драйвер для kubelet. Кажется, что он начал появляться в дикой природе после версии 1.14, но, возможно, просто не было такой распространенной проблемой до 1.14, как тогда, когда официальная рекомендация из документации kubernetes рекомендует используя systemd в качестве драйвера cgroup) по следующей причине:
Когда systemd выбран в качестве системы инициализации для дистрибутива Linux, процесс инициализации генерирует и использует корневую группу управления (cgroup) и действует как менеджер cgroup. Systemd имеет тесную интеграцию с контрольными группами и выделяет контрольные группы для каждого процесса. Можно настроить среду выполнения контейнера и кубелет для использования cgroupfs. Использование cgroupfs вместе с systemd означает, что тогда будет два разных менеджера cgroup.
Группы управления используются для ограничения ресурсов, выделяемых процессам. Единый менеджер cgroup упростит представление о том, какие ресурсы распределяются, и по умолчанию будет иметь более согласованное представление о доступных и используемых ресурсах. Когда у нас есть два менеджера, мы получаем два представления этих ресурсов. Мы видели случаи, когда узлы, настроенные на использование cgroupfs для kubelet и Docker, а systemd для остальных процессов, запущенных на узле, становились нестабильными из-за нехватки ресурсов.
Изменение настроек таким образом, чтобы ваша среда выполнения контейнера и kubelet использовали systemd в качестве драйвера cgroup, что стабилизировало систему. Обратите внимание на параметр native.cgroupdriver = systemd в настройке Docker ниже.
источник: https://kubernetes.io/docs/setup/cri/
До этого другой cgroup-драйвер cgroupfs похоже, был принятый подход / подход по умолчанию. Фактически, я переключился только потому, что эта рекомендация начала появляться во время kubeadm init'ing нового кластера 1.14.x несколько месяцев назад, что привело меня к эта проблема с github именно в этой ситуации.
По сути, это кажется ненадежным взаимодействием между обработкой kubelet systemd и зондированием cAdvisor, поэтому, возможно, код еще не совсем готов для прайм-тайма. Полное техническое объяснение доступно на этот комментарий:
«Отсутствующий» фрагмент созданный кодом runc systemd. Вот почему ошибка видна только тогда, когда systemd настроен как cgroup manager.
Ошибка исходит из когда cadvisor начинает попытки собирать и обрабатывать события из только что созданного «фрагмента / контейнера».
Предположительно, здесь присутствует состояние гонки, при котором cadvisor не знает, что «фрагмент / контейнер», для которого он пытается запустить средство отслеживания событий, был удален runc.
Вопрос открыт с апреля без особых признаков того, что его решают (поскольку он кажется низким).
Последний коммит, коснувшийся этого кода, - вот этот, однако, похоже, что в основном изменилось название файла / структура каталогов и макет кода, а также был введен код cadvisor задолго до.
Наконец, хотя переключение на использование cgroupfs - это вариант (как прокомментировал @hanx), он может приводит к ХУДШИМ проблемам (нестабильность под нагрузкой) и опять же НЕ рекомендуется официальными документами. Некоторые люди все еще выбирают этот маршрут, просто чтобы избавиться от (в основном добрый) Сообщения об ошибках.