Мое понимание вашей проблемы заключается в том, что вы пытаетесь сделать две вещи:
- Правильно распланируйте рабочие нагрузки графического процессора на узлы с доступными графическими процессорами
- Убедитесь, что модули не нужны графические процессоры не запланированы на узлы, которые имеют графические процессоры.
Вы делаете (1) с плагином устройства NVidia, который, кажется,правильный путь, поскольку он использует концепцию Расширенные ресурсы .
Для выполнения (2), Taints и Tolerations действительно рекомендуются.Документы даже явно говорят о случае использования графического процессора - Цитирование документации:
Узлы со специальным оборудованием: В кластере, где небольшое подмножество узловЕсли у вас есть специализированное оборудование (например, графические процессоры), желательно, чтобы блоки, которые не нуждаются в специализированном оборудовании, были удалены от этих узлов, таким образом оставляя место для модулей, которые поступают позже и нуждаются в специальном оборудовании.Это можно сделать, портя узлы, которые имеют специализированное оборудование (например, узлы-имена узлов kubectl special = true: NoSchedule или узлы-имена узлов kubectl special = true: PreferNoSchedule) и добавляя соответствующий допуск для модулей, использующих специальное оборудование.Как и в случае использования выделенных узлов, возможно, проще всего применить допуски с помощью настраиваемого контроллера допуска).Например, рекомендуется использовать Расширенные ресурсы для представления специального оборудования, связать узлы специального оборудования с расширенным именем ресурса и запустить контроллер допуска ExtendedResourceToleration.Теперь, поскольку узлы испорчены, на них не запланированы никакие модули без допусков.Но когда вы отправляете модуль, который запрашивает расширенный ресурс, контроллер допуска ExtendedResourceToleration автоматически добавит в него правильный допуск, и этот модуль будет планировать на специальных аппаратных узлах.Это гарантирует, что эти специальные аппаратные узлы предназначены для модулей, запрашивающих такое оборудование, и вам не нужно вручную добавлять допуски к вашим модулям.
Только те пользователи, которым явно нужны Графическим процессорам нужно добавить допуск для этого в своей спецификации pod, и это довольно просто сделать.Это выглядит так (ref: Advanced Scheduling в Kubernetes ):
tolerations:
- key: "gpu"
operator: "Equal"
value: "true"
effect: "NoSchedule"
Так что обычно это приемлемый компромисс.
Однако, если вы абсолютно не хотят разрешить пользователям добавлять этот допуск.Вам нужен контроллер доступа .
Контроллер доступа - это фрагмент кода, который перехватывает запросы к серверу API Kubernetes до сохранения объекта, но после запросааутентифицирован и авторизован.
В частности, вам нужен специальный контроллер AdmissionController, известный как MutatingAdmissionWebhook.
Ваш пользовательский MutatingAdmissionWebhook может взглянуть на спецификацию модуля, ищите:
resources:
limits:
nvidia.com/gpu: 2
, а затем автоматически добавьте требуемый «Допуск» в спецификацию модуля, и все это, не сообщая об этом пользователю.Вы по-прежнему используете Taints и Tolerations, пользователи просто их больше не видят.Вы не должны написать для этого новый планировщик.
Вот пример того, как написать webhook контроллера доступа,доступно в официальном репозитории kubernetes как часть тестов e2e.