Как стать автором
Обновить

Комментарии 10

Так и не смог понять какие преимущества дают cri-o и cri-containerd перед уже существующей реализацией. Просто стандартизация и нативная интеграция с kubernetes?
Насколько я понимаю, люди просто хотят выкинуть докер, т.к. он тащит своё полиси и это мешает альтернативной оркестрации.

Все лучше — модульность, надежность, стабильность, разработчики, поддержка крупных компаний.
В принципе, те работал с докером на крупных инсталляциях не задают вопрос зачем, а спрашивают когда?

Это не аргументы, а маркетинговый булшит.
to: fear86
С точки зрения Kubernetes — Docker по умолчанию несет в себе много ненужного, например встроенный инструментарий swarm или автоматическое конфигурирование правил iptables.
Когда выходит новая версия docker, совершенно не факт что Kubernetes будет нормально с ней работать.

В случае же с CRI-O это будет отдельный компонент, отвечающий только за контейнирезацию. Больше не нужно будет думать что разработчики Docker изменят в следующем релизе, что поломает текущее взаимодействие с Kubernetes.
Ну мне и раньше не нужно было думать о «что разработчики Docker изменят в следующем релизе», это проблемы kubernetes девелоперов. В общем они хотят облегчить себе жизнь и избавится от 3rd party софта. В этом конечно есть смысл.
Я имел ввиду девелоперы Kubernetes вынуждены говорить вам при установке: «вы должны использовать Docker не старше такой-то версии»
А вы в свою очередь имеете шанс столкнуться с некоторыми проблемами если не запретите Docker рулить iptables, т.к. этим уже занимается Kubernetes.
Это все должно было быть в статье, что бы не приходилось вытягивать все клещами.
Всё это по сути проистекает из фактического vendor lock-in в случае Docker (пусть оно даже при этом и Open Source…), который устраняется переходом на проект с открытой политикой управления (open governance) и модульностью by design, о чём в статье написано.
Вышел CRI-O v1.0.0 (обновил в тексте статьи).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий