Я тестирую классы времени выполнения K8s и успешно запустил несколько модулей с помощью containerd и gVisor.
Для этого я изменил /etc/containerd/config.toml ниже, затем перезапустил службу
disabled_plugins = ["перезагрузить"]
[плагины.linux]
shim_debug = истина
[plugins.cri.containerd.runtimes.runsc]
runtime_type = "io.containerd.runsc.v1"
Это удаляет default_runtime_name = "выполнить" config из конфигурации по умолчанию, которая была в /etc/containerd/config.toml (который изначально был сгенерирован с использованием Конфигурация containerd по умолчанию до того, как кластер был построен с помощью kubeadm)
Затем я создал класс среды выполнения для использования runsc и использовал его в манифесте модуля с помощью runtimeClassName: gvisor
версия API: node.k8s.io/v1beta1
вид: RuntimeClass
метаданные:
имя: гвизор
обработчик: runsc
а затем, наконец, запустите модуль, чтобы использовать новый класс среды выполнения
апиВерсия: v1
вид: стручок
метаданные:
имя: gvisor-стручок
спецификация:
runtimeClassName: gvisor
контейнеры:
- имя: nginx
изображение: nginx
Но конечно если я потом сделаю нормальный kubectl запустить pod1 --image nginx (т.е. без указания runtimeClassName: gvisor в манифесте, чтобы он использовал мой новый класс среды выполнения), он по-прежнему отлично запускается с помощью runc shim.
А за документы
Если runtimeClassName не указано, будет использоваться RuntimeHandler по умолчанию,
что эквивалентно поведению, когда функция RuntimeClass отключена.
Мой вопрос в том, что без default_runtime_name = "выполнить" в файле конфигурации containerd, как kubelet/containerd все еще знает, что нужно использовать runc, когда пользовательский класс/обработчик среды выполнения не указан в манифесте модуля? то есть где это обработчик времени выполнения по умолчанию настроен?
