Какой процесс является родительским процессом containerd-shim?

Я установил 2 среды k8s с помощью minikube. Один с флагом --container-runtime=docker и один с флагом --container-runtime=containerd. Вот отличия, которые я вижу.

Когда я устанавливаю container-runtime=docker , происходят такие вещи

  1. есть работающая служба dockerd
  2. Служба dockerd порождает containerd как собственный дочерний элемент.
  3. Есть /usr/bin/containerd-shim-runc-v2 процессов, которые запускают настоящие контейнеры, и родительский элемент каждого из этих containerd-shim-runc-v2 имеет PID 1 в системе.

Когда я устанавливаю container-runtime=containerd, происходят такие вещи

  1. нет dockerd службы, там нет двусмысленностей.
  2. есть процесс containerd, который принадлежит PID 1. Опять же, никаких сюрпризов.
  3. Существует containerd-shim процессов, которые запускают настоящие контейнеры, и родителем каждого из этих containerd-shim процессов является containerd.

Итак, вот мои вопросы

  1. В чем разница между containerd-shim и containerd-shim-runc-v2 ? Кажется, они берут в основном похожие флаги и т. Д.
  2. Почему в сценарии 1 прокладки являются дочерними элементами PID 1, тогда как в сценарии 2 прокладки являются дочерними элементами containerd?

РЕДАКТИРОВАТЬ: Просто подумал о редактировании. В поле Ubuntu 20, если я устанавливаю docker, dockerd — это отдельный процесс, родительский процесс которого имеет PID 1, containerd — это отдельный процесс, родительский процесс которого имеет PID 1, а все контейнеры являются дочерними элементами container-shim-runc-v2, чей PID равен 1. ?!?! Почему containerd не ребенок dockerd? Где это настраивается?


minikube docker-daemon containerd runc
person Hari Sundararajan    schedule 18.05.2021    source источник
comment
Привет @HariSundararajan. Не могли бы вы сказать нам, какую версию Minikube вы используете?   -  person Wytrzymały Wiktor    schedule 19.05.2021
comment
@WytrzymałyWiktor последний. v1.20.0   -  person Hari Sundararajan    schedule 19.05.2021

Ответы (1)


arrow_upward
0
arrow_downward

Я копался в этой теме и пришел к следующим выводам и источникам.

<сильный>1. В чем разница между containerd-shim и containerd-shim-runc-v2? Кажется, они используют в основном похожие флаги и т. д.

Это просто разные версии, containerd-shim-runc-v2 — самая новая версия containerd-shim. См. исходный код здесь.

Похоже, что докор по-прежнему использует containerd-shim вместо containerd-shim-runc-v2. Базовая функциональность по-прежнему будет той же функцией, что и оболочка, заключающаяся в том, что оболочка отслеживает контейнеры runc, чтобы сообщить containerd, когда runc завершил время выполнения.

Если вас беспокоят различия в API, обратитесь к исходному коду. Но по функциональности это просто разные версии shim API.

<сильный>2. Почему в сценарии 1 прокладки являются дочерними элементами PID 1, тогда как в сценарии 2 прокладки являются дочерними элементами containerd?

В конечном счете, они оба являются дочерними элементами PID 1, где прокладки являются дочерними элементами containerd, который является дочерним элементом PID 1.

Это сообщение в блоге дает хороший обзор времени выполнения на k8s и рабочих узлах. В частности, разделы, посвященные Docker, containerd и shims, помогут вам лучше понять ваши вопросы.

Прокладка находится между диспетчером контейнеров и средой выполнения, чтобы облегчить обмен данными и предотвратить проблемы интеграции, которые могут возникнуть. Это позволяет использовать контейнеры без демонов. По сути, он является родителем процессов контейнера для облегчения связи и устраняет длительные процессы выполнения для контейнеров. Отростки прокладки и контейнера скреплены наглухо; однако они полностью отделены от процесса менеджера контейнеров.

Вот более подробный ресурс о containerd, shims и их взаимодействии с Linux.

И этот ресурс посвящен runc, containerd и их PID в Linux. .

person Wytrzymały Wiktor    schedule 25.05.2021
comment
Привет @HariSundararajan. Отвечает ли это на ваш вопрос? - person Wytrzymały Wiktor; 26.05.2021