Я создал развертывание, которое может содержать от 2 до ~ 25 контейнеров, все из которых работают над частью более крупной логической единицы работы. Контейнеры будут использовать максимум 700–4 ГБ оперативной памяти, и мой первоначальный подход заключался в запросе 1 ГБ с ограничением 4G. В худшем случае (когда 4 ГБ больше, чем 700 МБ), это снимает узел (или не планируют с самого начала), даже если 3 или 400% бесплатных совокупных ресурсов доступны где-то еще.
Наблюдение за тем, как один или два контейнера медленно ползут в ОЗУ и отключается от узла, вместо того, чтобы планировщик вырывал контейнер и перемещал его, кажется довольно явной проблемой для стабильности.
Выкопавшись буквально за годы обсуждений git, документации и самого кода. Неясно, на каком уровне абстракции после абстракции планировщик даже распределяет контейнеры при запуске, и есть ли какие-либо упреждающие шаги, которые K8S беспокоит после развертывания работы.
Если ReplicaSet (я считаю, что это новый, улучшенный ReplicationController) будет реанимировать только контейнеры до тех пор, пока не будет уничтожен хост, вам придется создавать жесткие запросы сценариев наихудшего случая для каждого модуля, находящегося в его компетенции. Для более крупных заданий, которые мы выполняем как развертывание, это вводит 50% + потери ОЗУ из-за избыточного выделения ресурсов «на всякий случай».
Разве сохранение избыточно выделенных ресурсов не является одной из проблем, которые мы здесь пытаемся решить?
Я использовал довольно много планировщиков / менеджеров ресурсов на протяжении многих лет и не припомню случая, чтобы один шаг задания - контейнер - независимо от аналогии мог бы скомпрометировать сам хост, а не принудительно мигрировать или просто пометить не подлежит планированию ..
Несмотря на то, что документы отговаривают эту идею, голые стручки или 1 стручок: 1 набор реплик кажется единственным способом сохранить распределенную работу (при условии, что контейнеры проходят контрольную точку и совершают самоубийства достаточно часто, чтобы общая картина ресурсов была пересмотрена).
Я также должен упомянуть, что это размещенный Google Container Engine (v1.2.2), и, учитывая то, что выглядело как несколько страниц флагов, с которыми можно запускать K8S, неясно, является ли это внутренней проблемой, ошибка пользователя или просто как GCE настроил K8S. Я очень надеюсь на ошибку пользователя на этом.
Чтобы ответить на мой собственный вопрос, основанный на некоторых весьма полезных людях на канале Kubernetes Slack.
- Мой опыт сбоя узла из-за OOM контейнера, вероятно, связан с вторичным эффектом, поскольку диспетчер ресурсов предназначен для предотвращения этого. Предполагаемая причина заключалась в том, что подсистема ввода-вывода была перегружена до точки дестабилизации узла, что после некоторых измерений выглядит весьма вероятным.
В GKE ОС, Docker, K8S и любые временные каталоги, запрашиваемые модулями, находятся в одной нелокальной файловой системе ext4 размером 100 ГБ (по умолчанию, как мне кажется).
Большинство подов, которые мы создали, запрашивали и записывали во временные каталоги, и коллективный ввод-вывод перегружал систему до такой степени, что она перестала отвечать и в нашем случае блокировала саму ОС.
- Первоначальный тест, настройка моего собственного K8S с ОС на собственном диске ext4, докер и эфемерное пространство в их собственных пулах ZFS и те же манифесты развертывания вызывают стресс, но не приближаются к сбою ОС.
- Обходной путь, который был предложен, но еще не протестирован, заключается в использовании заданий и управлении зависимостями между ними с помощью некоторого координирующего процесса, предположительно, поскольку это распределит отдельные контейнеры по кластеру. Это может сработать, но мне кажется, что это скрывает основную проблему.
Хотя я еще не измерял назначение постоянных дисков для временного пространства, для которого мы использовали emptyDir, я предполагаю, что это также уменьшит нагрузку на основной диск и может быть достаточно, чтобы замаскировать проблему.
К сожалению, настройка GKE по умолчанию предполагает, что sda сможет обрабатывать всю нагрузку ОС, журналы K8S, Docker и рабочее пространство, что, по-видимому, должно работать для большинства людей, поскольку я не мог найти другую проблему, подобную нашей.
Исходя из «чистого металла», я надеялся избежать некоторых деталей низкого уровня при управлении кластером, но и dataproc, и GKE пока что, по крайней мере, заставили меня сильно склоняться к построению кластеров самостоятельно.
Надеюсь, это поможет кому-то, чья рабочая нагрузка поддается шаблону Job или в основном использует подготовленные диски.
Я удивлен, что любой передовой опыт так много ожидал бы от загрузочного диска и отметит это с помощью поддержки, поскольку даже «обычный» вычислительный движок, похоже, препятствует этому, учитывая размеры загрузочного диска по умолчанию.