Узел Kubernetes с высокой загрузкой диска из-за наложения докеров

У меня проблема с узлами Kubernetes, развернутыми на AWS. (Кластер с 3 узлами и 1 мастером, работающим на экземплярах m3.large, каждый размером около 25 ГБ)

Через (примерно 3 дня) на диске остается 0 КБ, и кластер зависает.

Все хранилище (более или менее) используется / var / lib / docker / overlay /. Внутри этой папки находится около 500 или более таких файлов:

drwx------ 3 root root 4096 Jun 20 15:33 ed4f90bd7a64806f9917e995a02974ac69883a06933033ffd5049dd31c13427a
drwx------ 3 root root 4096 Jun 20 15:28 ee9344fea422c38d71fdd2793ed517c5693b0c8a890964e6932befa1ebe5aa63
drwx------ 3 root root 4096 Jun 20 16:17 efed310a549243e730e9796e558b2ae282e07ea3ce0840a50c0917a435893d42
drwx------ 3 root root 4096 Jun 20 14:39 eff7f04f17c0f96cff496734fdc1903758af1dfdcd46011f6c3362c73c6086c2
drwx------ 3 root root 4096 Jun 20 15:29 f5bfb696f5a6cad888f7042d01bfe146c0621517c124d58d76e77683efa1034e
drwx------ 3 root root 4096 Jun 20 15:26 f5fa9d5d2066c7fc1c8f80970669634886dcaccc9e73ada33c7c250845d2fe8c
drwx------ 3 root root 4096 Jun 20 14:38 f8fd64fb1e0ab26708d5458dddd2d5a70018034237dfed3db48ada5666fcf77f
drwx------ 3 root root 4096 Jun 20 14:46 faa143ebd7a4079eaa45ddbf17dcfc9163e3035983f2e334e32a60e89452fa94
drwx------ 3 root root 4096 Jun 20 14:48 fb93c0c64e0d4935bf67fc8f70df2b8a4cffe59e294ee8a876dfdf6b57486da5
drwx------ 3 root root 4096 Jun 20 14:46 fd0a420d5655fb7d022c397effdb95968ff7e722c58fcc7915f97e8df47cd080

Кластер работает на Kubernetes 1.6.4 и Docker 1.12.6.

Вроде проблема со сборщиком мусора кубернетов. Запуск cAdvisor / validate дает мне следующее сообщение

 None of the devices support 'cfq' I/O scheduler. No disk stats can be reported.
     Disk "xvda" Scheduler type "none".

Выполнение этого оператора journalctl -u kubelet | grep -i garbage также дает сообщение об ошибке: Jun 20 14:35:21 ip-172-21-4-239 kubelet[1551]: E0620 14:35:21.986898 1551 kubelet.go:1165] Image garbage collection failed: unable to find data for container /

Есть идеи, как снова заставить сборщик мусора работать?


person nrhode    schedule 22.06.2017    source источник
comment
Это каталоги, какого размера каждый? du -sh /var/lib/docker/overlay/* и сам каталог? du -sh /var/lib/docker/overlay/   -  person Robert    schedule 22.06.2017
comment
Размер файла не всегда одинаков. (Есть много файлов размером в несколько килобайт, но есть также много файлов размером 710 МБ, 197 МБ, 17 МБ и так далее ...) (в сумме 14 ГБ) Папка также имеет размер 14 ГБ.   -  person nrhode    schedule 23.06.2017
comment
Вы работаете с копсом? И если да, то какой версии? В некоторых старых версиях kops настроены не все настройки сборщика мусора, поэтому вам может потребоваться просто обновить kops. Если вы сообщите мне, какую версию kops вы используете, я могу подтвердить, есть ли исправления в более поздних версиях.   -  person justinsb    schedule 06.07.2017


Ответы (1)


Мне удалось решить аналогичную проблему с повторяющимся высоким вводом-выводом на узлах из-за du -s /var/lib/docker/overlay/, отредактировав kops cluster.spec с помощью kops edit cluster [cluster_name]. Я добавил в спецификации следующее:

docker:
    logDriver: json-file
    logLevel: warn
    storage: overlay2

Похоже, что по умолчанию kops настраивает докер для использования оверлея в качестве драйвера хранилища по умолчанию, в то время как докер рекомендует использовать overlay2 как более новый, более стабильный и быстрый.

person Mark Hilton    schedule 21.05.2018