Сейчас и docker и podman являются фактически обертками над runc, который собственно занимается созданием нужных неймспейсов. Разница в том, что в docker runc «впилен» в сам пакет докера, а в podman этот рантайм идет отдельно — и его можно заменять (к примеру, в Fedora 31 можно использовать crun).
Кроме того, общение с runc происходит по стандартному протоколу, который регулируется runtime spec. С недавних пор этот протокол поддерживает systemd-nspawn, а значит его можно использовать вместо run
Более развернутый ответ — для того чтобы использовать программу как container engine в kubernetes эта программа должна иметь отдельный сокет для работы по интерфейсу CRI. Чтобы управлять этим сокетом программа должна быть запущена как демон. Потому придется превратить podman обратно в демон, как docker.
Потому существует строгое разделение — podman для работы на пользовательских машинах (где демон только мешает и в большинстве случаев требует привелегий) и CRI-O — легковесный демон для работы с Kubernetes и специально заточенный под него. В итоге обе программы используют общий набор библиотек (libpod, containers/images) для работы.
Основная «цена» отказа от демона — нельзя сериализировать пуллы, потому что нет демона который бы приоритезировал их. Остальное решается грамотной расстановкой локов
> Как поддерживается изменённое состояние и как оно проверяется на дрифт?
Состояние хранится в репозитории en.wikipedia.org/wiki/OSTree. Если файл не совпадает с ожидаемым, значит пользователь использовал другие инструменты проме MCO. Тогда оператор попытается привести файл к ожидаемому виду и перезапишет его.
>Что-то похожее в чистом Kubernetes вам не встречалось?
MCO (как и большинство стандартных операторов OCP4) работает с «чистым» Kubernetes
Продукт не стоит ни копейки, заказчики платят компании за поддержку и оперативное устранение ошибок.
Например, по вашей ссылке тред начался August 2 2017 at 8:39 AM, первый ответ от поддержки 2 August 2017 11:38 AM и фикс был протестирован и выпущен за немногим более чем 24 часа — 3 August 2017 11:53 PM
>заботливо разложенным ведущим вендором
Вы подразумеваете что это было сделано специально?
Операторы имеет более богатый API — не только создать/удалить сервис как у APB, но и реагировать на изменения CRD для переконфигурации готового сервиса, приводить сервис к требуемому виду при внешних измениях. Кроме того, для установки оператора не требуется сторонние расширения вроде APB/Service Catalog. Опциональным аналогом APB для операторов является OLM — он дает возможность устанавливать/обновлять операторы из Operator Hub, просматривать и удалять установленные
Кроме того, общение с runc происходит по стандартному протоколу, который регулируется runtime spec. С недавних пор этот протокол поддерживает systemd-nspawn, а значит его можно использовать вместо run
Более развернутый ответ — для того чтобы использовать программу как container engine в kubernetes эта программа должна иметь отдельный сокет для работы по интерфейсу CRI. Чтобы управлять этим сокетом программа должна быть запущена как демон. Потому придется превратить podman обратно в демон, как docker.
Потому существует строгое разделение — podman для работы на пользовательских машинах (где демон только мешает и в большинстве случаев требует привелегий) и CRI-O — легковесный демон для работы с Kubernetes и специально заточенный под него. В итоге обе программы используют общий набор библиотек (libpod, containers/images) для работы.
podman system prune(как и в докере)Основная «цена» отказа от демона — нельзя сериализировать пуллы, потому что нет демона который бы приоритезировал их. Остальное решается грамотной расстановкой локов
Да
> команды запускать,
Нет, для этого есть DaemonSet и\или systemd units
> Как поддерживается изменённое состояние и как оно проверяется на дрифт?
Состояние хранится в репозитории en.wikipedia.org/wiki/OSTree. Если файл не совпадает с ожидаемым, значит пользователь использовал другие инструменты проме MCO. Тогда оператор попытается привести файл к ожидаемому виду и перезапишет его.
>Что-то похожее в чистом Kubernetes вам не встречалось?
MCO (как и большинство стандартных операторов OCP4) работает с «чистым» Kubernetes
Продукт не стоит ни копейки, заказчики платят компании за поддержку и оперативное устранение ошибок.
Например, по вашей ссылке тред начался August 2 2017 at 8:39 AM, первый ответ от поддержки 2 August 2017 11:38 AM и фикс был протестирован и выпущен за немногим более чем 24 часа — 3 August 2017 11:53 PM
>заботливо разложенным ведущим вендором
Вы подразумеваете что это было сделано специально?