Комментарии 81
Отлично, освоил какое-то время назад докер, а теперь ещё и со внутренностями и дополнительными сущностями придётся разбираться! :(
В статье также не хватает информации о podman, чтобы жизнь была ещё ярче.
Просто тут речь про «освоил мейнтенс и траблшутинг куб кластера».
Если это не ваша работа или не ваш интерес в плане развития, то на эти изменения вам можно глубоко наплевать :)
Первое и возможно главное что надо знать о podman это то что эго консольный интерфейс на 99% совместим с docker.
podman на моей рабочей федоре стоит месяца, я периодически строю и запускаю контейнеры, разницы в команндах не обнаружил пока.
Конечно есть ньюансы и они делаю podmanинтереснее. К примеру нет никакого демон процесса как у dockerи не нужен root.
Тот момент когда радуешься, что забил на k8s много лет назад и тебе теперь не надо переучиваться :)
Однажды «по мотивам» С создали С++ (потом еще и Delphi/Java/.NET выросли). В мире программирования снова добавилось специализаций.
Сейчас «разрастается» технопарк контейнеров. Вновь предлагаются\принимаются стандарты, вынужденно меняются привычные инструменты, используются временные решения и протекают абстракции.
Впереди волшебные «обратная совместимость», «критичные зависимости», «Docker легаси», «переписывание конфигов на новую модную универсальную облачную технологию», и, наконец, «простой в освоении и легковесный инструмент для быстрого создания\развертывания образов типичных бизнес-приложений».
Архитектура, в которой код пишется в одной среде, строится в другой и работает в третьей — это не CI/CD, а среднее между лотереей и «русской рулеткой».Окружение, в котором код пишется, и в котором он работает в продакшене и так всегда разное, и рантайм для контейнеров тут не причём(и уж тем более CI/CD тут не причём).
Докер это про изолированность и решение проблемы с совместимостью в пару кликов.
Но никак не за максимальную похожесть, особенно если речь идет о производительности.
Окружение, в котором код пишется, и в котором он работает в продакшене и так всегда разное
Не то, что бы я сильно понимал в докере, но разве это не рецепт по созданию на проде совершенно глупых багов?
Вы на сервер IDE ставите? А доступ на запись в репозиторий git серверу даёте? Не получится у вас полностью идентичного окружения, ну вот никак.
Приложение на рабочей станции разработчика билдится в докер-образ для теста
вот делать мне еще нечего как на своей машине докеры билдить. Код пишется в IDE, там же билдится, запускается, отлаживается. Близкое окружение только у CI и прода, потому что СI, собственно, контейнеры и билдит.
А проблемы разного окружения просто решаются нормальными инструментами и языками, которые от любого чиха не разваливаются. Читай, дают reproducible builds из коробки.
Всегда должна быть возможность воспроизвести на локальной машине близко к продакшену окружение
А проблемы разного окружения просто решаются нормальными инструментами
Вот Докер и является одним из инструментов, созданного для решения проблемы разных окружений.
Ну вот на рабочей станции разработчика контейнер работает параллельно с IDE, а на проде — без IDE, и никакой проблемы тут нет. А если на рабочей станции запустить образ докером, а на проде — кубами, то кто-то считает это проблемой. Но в чём разница-то, почему IDE это одно, а программа, отдающая команду containerd запустить контейнер — это другое?
Кстати, в медицине то же самое — если у CT разных производителей формат DICOM более-менее похож, то у MR могут совпадать только данные пациента и дата сканирования.
Эту спецификацию поддерживают Docker, containerd и cri-o, так что образ, собранный с помощью docker build на машине разработчика, должен без проблем запустится с помощью containerd или cri-o. И так и происходит в подавляющем большинстве случаев, но время от времени попадаются «нюансы реализации». Эти нюансы, конечно, исправляются, но иногда не так быстро, как хотелось бы.Видимо, сосуществование не вполне прекрасное.
Не поймите меня неправильно: я рад Docker-у и OCI. Своевременная передача наработок из Докера в OCI — это здорово, это лучше 99% других подобных случаев. Google, Docker, RedHat и прочие внесшие лепту заслуживают только уважения.
Но мой внутренний пессимист настойчиво нашептывает на ухо: «это крупный проект, в котором замешаны интересы нескольких игроков. Сама история показывает, что через пару лет начнется раздрай, начнутся споры об обратной совместимости, обвинения в EEE и т.д.»
Будет замечательно, если пессимист ошибётся, если участники OCI смогут сообща развивать технопарк контейнеров. Но, боюсь, пессимист не ошибется.
Docker вовремя отдал все свои наработки в OCI
Если бы отдал вовремя, не появился бы containerd
А разве containerd — не та самая отданная "наработка" докера?
|Неясно следующее. Я в Dockerfile формирую среду выполнения, например устанавливаю дополнительные библиотеки и т.п. В каком файле теперь это будет происходить если мы говорим о к8s?
А если вы делаете сборку в среде k8s то наверное надо смотреть в сторону Builda
habr.com/ru/company/redhatrussia/blog/467105
Если воркеры CI/CD развёрнуты в кластере… Ждём Docker in K8s)
У нас сборка образов как раз в CI K8s делается. Так что даже любопытно стало, как это будет решаться.
Когда так и не успел освоить докер, а он уже всё.
Прямо как с JS-фреймворками :)
Тогда уж https://habr.com/ru/post/343100/ для незнакомых с ней.
Не спеши выполнять приказ — подожди, пока его отменят
Но выход есть! Для манипуляции с образами контейнеров можно воспользоваться дополнительной утилитой skopeoХех, спасительница
"Я хотел воспользоваться докером — но оказалось, что он уже deprecated"
Мы добавили в свой PaaS поддержку BlobFuse Flex volume. Едва анонсировали для пользователей — появилось слово deprecated” в git репозитории к этому драйверу, как альтернатива — объявлен CSI драйвер (и только он будет поддерживаться с k8s 1.21), который “preview, not for production” сейчас, и “мы не уверены, что депрекейтед BlobFuse Flex volume поддерживается Майкрософтом” (смысл ответа на запрос к MS «что теперь делать?»).
И такое не редко. Наверное в современном мире успешнее не те, кто «старше, значит опытнее», а скорее те, кто «опытнее, значит более динамичные и гибкие» (это я о нас — тех, кто все эти компоненты и фреймворки использует).
Аналогично, я уже несколько статей прочитал, для успокоения, начиная с этой:
habr.com/ru/search/?target_type=posts&q=kubernetes&order_by=date
1K статей посвящено каждой. Прошло ВСЕГО 4 года, с 2016 по 2020. И в завершение что-то сломали?
Сорян, но на этом месте можно ставить R.I.P. Дальше читать FAQ не вижу смысла.
То есть один containerd для dockerd и kubelet будет работать нормально, просто docker и kubectl не будут видеть контейнеры друг друга и могут быть сложности с пониманием почему не запускается что-то, хотя ресурсов вроде хватает — не хватает, просто не видно всех одновременно. Правильно?
одновременно вы не будете kubelet и docker ставить на тачку
Почему? Пускай без извращений гетерогенных контейнеров в одном проекте, а просто один проект на k8s в minikube nativ, а другой в docker-compose или тупо bash алиас к docker run для каких-то команд
Или изменения на этого никак не коснуться?
iptables создают kube-proxy и CNI plugin
Уменшить их количество можно переключив kube-proxy на режим ipvs
или выбрать CNI plugin типа cilum, который использует eBPF — но тут надо понимать что вы делаете, а не бездумно следовать советам из интернета
Думаю, дай для эксперимента исключу кубер и создам контейнер «alpine» напрямую, через crictl. И тут выясняется, что тот огрызок информации, что хранится в репе на гите, не соответствует действительности. Выясняется, что информации по возможным параметрам конфига нет нигде, а запуск pod'a с конфигом из 5 строк из examples выдаст ошибку. Pod запустится, но в Ready не перейдет. Ошибку, которую не понять, потому что «не найден контейнер с ID <id pod'a>», и, внезапно, даже не нагуглить.
Docker is deprecated — и как теперь быть?