Как последняя версия Kubernetes теперь справляется с нагрузками искусственного интеллекта - и многое другое

Помимо решения проблем контейнерного ПО с заданиями AI и ML, в Kubernetes 1.31 реализовано несколько ключевых улучшений безопасности.

Kubernetes, система оркестровки управления контейнерами, оказалась жизненно необходимой для современных вычислений, за исключением одной области: искусственного интеллекта (AI) и машинного обучения (ML). Проблема: AI/ML требует значительных ресурсов CPU, памяти и GPU, которыми нелегко управлять в Kubernetes.

Теперь, в последнем выпуске Kubernetes - Kubernetes 1.31, Elli - Cloud Native Computing Foundation (CNCF) решает эти проблемы.

Улучшение функций ИИ в Elli началось с альфа-поддержки изображений и артефактов Open Container Initiative (OCI) в качестве родного источника объема. Это может показаться незначительным, но это позволяет разработчикам менять большие языковые модели (LLM) так же легко, как и обычные образы контейнеров.

Elli также привносит в Kubernetes обновленный API и дизайн динамического распределения ресурсов. Эта функция поможет стандартизировать доступ и управление аппаратными ускорителями, такими как GPU, которые необходимы для AI и ML. Она также упрощает реализацию таких функций, как автомасштабирование кластеров, что, в свою очередь, облегчает выполнение заданий AI и ML на Kubernetes.

В прошлом Kubernetes использовала несколько способов доступа к базовому оборудованию хоста. Обновленное динамическое распределение ресурсов (DRA) обеспечивает более простой способ доступа к системным ресурсам. Старый стиль, использующий контроллер драйвера DRA, по-прежнему поддерживается через «классический DRA».

Оставляя AI позади, Kubernetes также теперь полностью поддерживает AppArmor, модуль безопасности ядра Linux, который позволяет системным администраторам ограничивать возможности программ с помощью профилей для каждой программы. Эта функция стала общедоступной и позволяет пользователям устанавливать профили AppArmor для контейнеров непосредственно через API Kubernetes. При правильной реализации поддержка AppArmour поможет сделать кластеры Kubernetes и рабочие нагрузки более безопасными.

Что касается безопасности, то новая опциональная функция позволяет администраторам настраивать конечные точки таким образом, чтобы анонимные запросы на доступ были заблокированы. Это поможет защитить кластеры от неправильной конфигурации управления доступом на основе ролей (RBAC), которая в противном случае может предоставить анонимным пользователям широкий доступ к кластеру.

Как постоянно развивающаяся программа с открытым исходным кодом, Kubernetes 1.31 также продолжает оптимизировать и модернизировать свою кодовую базу, отказываясь от устаревших функций. К ним относятся:

• Удаление интеграции с облачными провайдерами in-tree: Завершив процесс, начавшийся в версии 1.26, Kubernetes 1.31 удаляет все интеграции с облачными провайдерами in-tree. Этот шаг является частью постоянных усилий, направленных на то, чтобы Kubernetes оставалась нейтральной к поставщикам платформой. Вы по-прежнему можете интегрировать свои кластеры Kubernetes с определенным облачным провайдером. Однако вы не сможете сделать это изнутри Kubernetes. Придется использовать рекомендованный подход с помощью внешней интеграции.
• Утрата плагинов ограничения объема, не относящихся к CSI: В этом выпуске отменены все плагины планировщика ограничения объема, не относящиеся к CSI, в соответствии со стратегией Kubernetes по переходу на интерфейс Container Storage Interface (CSI) для всех функций, связанных с хранением данных.
• Отказ от Cgroups v1: Cgroups - это функция ядра Linux, которая позволяет распределять, устанавливать приоритеты и управлять системными ресурсами между процессами. С этого момента вы должны использовать cgroups v2.

Если сложить все это вместе, то можно сказать, что этот релиз - это нечто большее, чем просто создание Kubernetes AI-friendly. Ангелос Колайтис, старший инженер-программист Canonical и руководитель группы по выпуску Kubernetes 1.31, сказал, что новый выпуск предназначен для того, чтобы «убрать сложность и детали, связанные с реализацией, из кода Kubernetes, чтобы Kubernetes сосредоточился на желаемом состоянии и оставил все реализации, все дополнительные источники за его пределами».

Помимо новых возможностей, Колайтис сказал: «Вам не нужно ничего делать, но Kubernetes будет предпринимать дополнительные шаги, чтобы убедиться, что ваши рабочие нагрузки работают, надежны и на них можно рассчитывать, что ваши производственные сервисы не сломаются».

Новые функции - это хорошо, но стабильность - это золото. Только по этой причине я рекомендую как можно скорее перейти на Kubernetes 1.31.