Комментарии 22
Вместо вопроса «сможет ли podman заменить kubernetes», который довольно тривиален (нет, не сможет), интереснее задаться вопросом «сможет ли podman заменить docker». И тут уже намного больше нюансов. Для меня ответ - да, но я не разработчик, а энтузиаст self-hosted
Согласен, Podman не заменит полноценный Kubernetes, но ведь такой цели у него и нет. Хотелось скорее показать, что некоторые вещи можно попробовать и без целого кластера.
А вот сравнение с Docker действительно интересная тема. Думаю, стоит как-нибудь попробовать перенести обычный проект посерьезнее с Docker на Podman и посмотреть, какие проблемы возникнут. Спасибо за идею!
Добротная статья: Podman - современная альтернатива Docker
По сути Podman закрывает те же задачи, что и Docker - сборка образов, запуск контейнеров, работа с реестрами - но с прицелом на другие сценарии использования:
локальная разработка и тестирование контейнеризованных приложений;
запуск контейнеров и подов на серверах и в homelab, особенно там, где хочется обойтись без демона;
эксплуатация контейнеров без root-доступа, что критично для multi-tenant окружений;
генерация Kubernetes-манифестов прямо из работающих контейнеров - удобно, если Kubernetes только планируется;
замена Docker в CI/CD, где Podman может запускаться внутри самого CI-раннера без привилегированного демона.
На практике чаще всего Podman выбирают для домашних лабораторий и небольших серверов с повышенными требованиями к безопасности, для edge-устройств с ограниченными ресурсами, и там, где Kubernetes уже используется или явно стоит в планах - генерация манифестов сильно упрощает миграцию.
Удивлен. Вроде как наоборот - в RedHat (нацелена на Enterprize) как раз podman штатный. И для дистрибуции мне как раз приходиось переделывать с моего докера на их rootless podman.
Ну т.е. разрабатываю, собираю контейнеры с помощью docker. А им сделал скрипт, который эти контейнеры деплоит через podman.
Как раз локальная разработка - docker (Docker Desktop), а прод - виртуалка с podman.
Это мнение автора статьи. Red Hat активно продвигает Podman Desktop. Open source Podman Desktop(лицензия Apache 2.0.) В Linux связка Podman и Podman Desktop работает нативно, без использования скрытых виртуальных машин (в отличие от Docker Desktop). Добротная документация.
Надо читать официальные доки installation.md, чтобы не запускать полную строку с docker.io/library/alpine:3.21 и не менять Dockerfile для docker ради совместимости с podman.
В конце мая 2024 года Docker Hub временно вводил полную геоблокировку российских IP-адресов.
Готовый пример для $HOME/.config/containers/registries.conf
# Очередность поиска реестров при вводе коротких имён образов
unqualified-search-registries = [
"docker.io",
"quay.io",
"registry.fedoraproject.org",
"container-registry.oracle.com",
"registry.access.redhat.com"
]
# Режим обработки коротких имён (защита от подмены образов)
short-name-mode = "disabled"
# Локальный реестр (для локальной разработки, HTTP)
[[registry]]
location = "localhost:5000"
insecure = true
# Docker Hub и его зеркала
# Порядок зеркал = порядок попыток: первое → второе → … → docker.io
[[registry]]
prefix = "docker.io"
location = "docker.io"
[[registry.mirror]]
location = "dockerhub.timeweb.cloud"
[[registry.mirror]]
location = "dockerhub1.beget.com"
[[registry.mirror]]
location = "dh-mirror.gitverse.ru"
insecure = true
[[registry.mirror]]
location = "cr.yandex/mirror"
[[registry.mirror]]
location = "mirror.gcr.io"Спасибо за дополнение! Про registries.conf знаю, но в статье специально использовал полные имена, чтобы всё работало независимо от настроек у читателя. Так проще повторить примеры и не гадать, откуда подтягивается образ.
А вот с зеркалами хороший момент, особенно с учётом ограничений Docker Hub. Думаю, многим пригодится, спасибо за конфиг!
Проверка:
podman info --format '{{index .Registries "search"}}'
podman pull nginx:alpineФич хватает. Для нескольких подов в одном файле — несколько --ip:
podman kube play --network static-net --ip 10.90.0.100 --ip 10.90.0.101 multi-pod.yamlСпасибо за дополнение! :) А давно Podman пользуетесь? Интересно, как он вам в целом. Часто ли получается им заменять привычный Docker?
Я всё ещё не очень понимаю зачем в Подмане нужны поды.
Какбе технически да, это такие же поды как в кубере по реализации. Но зачем мы используем поды в кубере? Чаще всего просто чтобы запустить в нём один контейнер. Иногда инит контейнеры и сайдкары, которые чаще всего нужны для внешних интеграции — вот тут из Vault'а ключи достать, вот тут метрики Prometheus выставить.
И вот тут возникает проблема, что такой юзкейс какбе бесполезен без кубера. Остаётся что поды в Подмане это такой лёгкий и не особо удобный аналог композа, на который при этом надо переучиваться.
Зачем это нужно, когда поднять kind/minikube/k3s и иметь нормальный кубер с нормально работающим примитивами мне не очень понятно.
Тут скорее зависит от задачи. Если нужно проверить именно работу Kubernetes, то kind, конечно, удобнее. А если хочется просто запустить несколько контейнеров из готового YAML, проверить их взаимодействие, сеть и тома, то Podman позволяет сделать это без поднятия целого кластера и лишних компонентов, соответственно, и накладных расходов на них.
Но согласен, если kind уже настроен и активно используется, особой выгоды от Podman может и не быть. Мне скорее хотелось показать, что такая возможность вообще есть и в каких случаях она может пригодиться :)
Ну накладные расходы в оверхед пары сотен мегабайт это не что-то большое...
У меня претензии скорее к самой концепции. Поды есть, но подман особо не раскрутил концепцию в что-то хорошо юзабельное и по причинам, которые я сказал, поды подмана к подам кубернетаса кроме технической реализации имеют мало отношения. Мне ОЧЕНЬ СЛОЖНО придумать ситуацию когда я захочу в кубере запускать под, подобный которому я могу запустить в подмане.
Подману стоило бы раскрутить концепцию в что-то более юзабельное. Может быть свой композ-лайк спек для подов или тулзы вокруг них. А так... Ситуация как с Nspawn в Systemd - прикольно, круто что оно есть, но зачем и как его использовать обосновать сложно из-за отсутвия тулинга.
По сути Pods в Podman — это “локальный Kubernetes” для разработки, тестирования и edge-сценариев, где не хочется поднимать полноценный кластер. Creating a local Minikube-powered Kubernetes cluster. Creating a local Kind-powered Kubernetes cluster.
Кстати, это очень плохой официальный пример, который лишний раз показывает что сами разрабы подмана не очень могут обосновать зачем там нужны поды. Запускать редис с аппом в одном поде это, мягко говоря, анти-паттерн и никто так к кубере делать не будет.
А почему антипаттерн? Только по тому, что редис будет прибит, если наше приложение закрешится и мы потеряем прогретый кеш? С другой строны, если мы запускаем редис и аппку в рамках одного пода, они гарантированно запустятся на одной ноде и точно не окажутся работающими на стойках в разных концах ДЦ. Меньше сетевых ошибок и выше скорость. Возможно, какому-нибудь HFT это может быть очень важным, возможно, важнее потери прогретого кеша.
не хочется поднимать полноценный кластер
А почему не хочется? Однонодовый кубер поднимается одной командой.
Поды в Podman, как и в Kubernetes нужны для выборочной изоляции namespace. Если у вас на домашнем сервере крутятся контейнеры с self-hosted сервисами, желательно изолировать их друга и от хоста. И тут podman с rootless из коробки и подами подходит замечательно. Плюс механизм запуска контейнеров и подов через systemctl (quadlet) лично мне кажется удобнее podman/docker compose, хотя и приходится конвертировать синтаксис и сталкиваться с различными проблемами совместимости.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Kubernetes без Kubernetes: запускаем Pod с помощью Podman