RuntimeClass

На этой странице описывается ресурс RuntimeClass и механизм выбора исполняемой среды.

RuntimeClass позволяет выбрать конфигурацию исполняемой среды для контейнеров. Используется для настройки исполняемой среды в Pod'е.

Мотивация

Разным Pod'ам можно назначать различные RuntimeClass'ы, соблюдая баланс между производительностью и безопасностью. Например, если часть рабочей нагрузки требует высокого уровня информационной безопасности, связанные с ней Pod'ы можно запланировать так, чтобы они использовали исполняемую среду для контейнеров на основе аппаратной виртуализации. Это обеспечит повышенную изоляцию, но потребует дополнительных издержек.

Также можно использовать RuntimeClass для запуска различных Pod'ов с одинаковой исполняемой средой, но с разными настройками.

Подготовка

1. Настройте реализацию CRI на узлах (зависит от используемой исполняемой среды);
2. Создайте соответствующие ресурсы RuntimeClass.

1. Настройте реализацию CRI на узлах

Конфигурации, доступные с помощью RuntimeClass, зависят от реализации Container Runtime Interface (CRI). Для настройки определенной реализации CRI обратитесь к соответствующему разделу документации (ниже).

Каждой конфигурации соответствует обработчик, на который ссылается RuntimeClass. Имя обработчика должно соответствовать синтаксису для меток DNS.

2. Создайте соответствующие ресурсы RuntimeClass

К каждой конфигурации, настроенной на шаге 1, должно быть привязано имя обработчика (handler), которое ее идентифицирует. Для каждого обработчика создайте соответствующий объект RuntimeClass.

На данный момент у ресурса RuntimeClass есть только 2 значимых поля: имя RuntimeClass (metadata.name) и обработчик (handler). Определение объекта выглядит следующим образом:

# RuntimeClass определен в API-группе node.k8s.io
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  # Имя, которое ссылается на RuntimeClass
  # ресурс RuntimeClass не включается в пространство имен
  name: myclass 
# Имя соответствующей конфигурации CRI
handler: myconfiguration 

Имя объекта RuntimeClass должно удовлетворять синтаксису для поддоменных имен DNS.

Использование

После того как RuntimeClasses настроены для кластера, использовать их очень просто. Достаточно указать runtimeClassName в спецификации Pod'а. Например:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass
  # ...

kubelet будет использовать указанный RuntimeClass для запуска этого Pod'а. Если указанный RuntimeClass не существует или CRI не может запустить соответствующий обработчик, Pod войдет в фазу завершения работы Failed. Полное сообщение об ошибке можно получить, обратившись к соответствующему событию (event).

Если имя runtimeClassName не указано, будет использоваться RuntimeHandler по умолчанию (что эквивалентно поведению, когда функция RuntimeClass отключена).

Настройка CRI

Для получения более подробной информации о настройке исполняемых сред CRI обратитесь к разделу Установка CRI.

containerd

Обработчики исполняемой среды настраиваются в конфигурации containerd в файле /etc/containerd/config.toml. Допустимые обработчики прописываются в разделе runtimes:

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]

Дополнительная информация доступна в документации по конфигурации containerd.

CRI-O

Обработчики исполняемой среды настраиваются в файле конфигурации CRI-O (/etc/crio/crio.conf). Допустимые обработчики прописываются в таблице crio.runtime:

[crio.runtime.runtimes.${HANDLER_NAME}]
  runtime_path = "${PATH_TO_BINARY}"

Более подробную информацию см. в документации по конфигурации CRI-O.

Scheduling

Поле scheduling в RuntimeClass позволяет наложить определенные ограничения, гарантировав, что Pod'ы с определенным RuntimeClass'ом будут планироваться на узлы, которые его поддерживают. Если параметр scheduling не установлен, предполагается, что данный RuntimeClass поддерживается всеми узлами.

Чтобы гарантировать, что Pod'ы попадают на узлы, поддерживающие определенный RuntimeClass, эти узлы должны быть связаны общей меткой, которая затем выбирается полем runtimeclass.scheduling.nodeSelector. nodeSelector RuntimeClass'а объединяется с nodeSelector'ом admission-контроллера, на выходе образуя пересечение подмножеств узлов, выбранных каждым из селекторов. Если возникает конфликт, Pod отклоняется.

Если поддерживаемые узлы объединены неким taint'ом, чтобы предотвратить запуск на них Pod'ов с другими RuntimeClass'ами, можно к нужному RuntimeClass'у добавить tolerations. Как и в случае с nodeSelector, tolerations объединяются с tolerations Pod'а admission-контроллера, фактически образуя объединение двух подмножеств узлов с соответствующими tolerations.

Чтобы узнать больше о настройке селектора узлов и tolerations, см. раздел Назначаем Pod'ы на узлы.

Pod Overhead

Можно указать overhead-ресурсы, необходимые для работы Pod'а. Это позволит кластеру (и планировщику) учитывать их при принятии решений о Pod'ах и управлении ресурсами.

В RuntimeClass дополнительные ресурсы, потребляемые Pod'ом, указываются в поле overhead. С помощью этого поля можно указать ресурсы, необходимые Pod'ам с данным RuntimeClass'ом, и гарантировать их учет в Kubernetes.

Что дальше

• Описание RuntimeClass;
• Описание RuntimeClass Scheduling;
• Концепция Pod Overhead;
• Описание функции PodOverhead.