Разработчики Kubernetes: «Все ли готовы к отказу от Docker?»
В прошлом году стало известно, что Kubernetes отказывается от Docker как среды исполнения контейнеров в пользу containerd и CRI-O. В настоящий момент ожидается, что компонент dockershim, ответственный за взаимодействие с Docker, будет удален из кодовой базы Kubernetes в релизе v1.24 (апрель 2022 года). Решение позиционируется как очередной шаг избавления от функций, вечно находящихся в бета-версии, и одновременно как возможность дать пользователям больше гарантий стабильности и совместимости.
Однако, понимая важность этого изменения, на днях разработчики K8s решили выяснить, насколько пользователи готовы к удалению Docker, и призвали всех желающих поучаствовать в опросе на эту тему.
По словам авторов опроса, хотя данные некоторых исследований (Datadog, Sysdig) и показывают, что переход на containerd набирает обороты, dockershim по-прежнему очень популярен. Не готовы к миграции и многие поставщики сторонних решений — в частности, для телеметрии (логирования) и безопасности.
Трудности перехода
В частности, авторы хотят понять, почему пользователям непросто отказаться от Docker. Судя по первым двум вопросам, в сообществе не уверены, что пользователи в полной мере проинформированы:
«Вы знаете, что поддержка dockershim прекратится в K8s 1.24?»
«Считаете ли вы, что у вас достаточно информации о вариантах миграции, и вы готовы к удалению dockershim?»
Меж тем разработчиками K8s уже был подготовлен целый ряд документов для упрощения перехода:
руководство по миграции с dockershim, из которого можно узнать, какой CRI используется на узлах сейчас, как повлияет отказ от dockershim на приложения и т. д.;
инструкция по использованию containerd и CRI-O в документации K8s;
FAQ с ответами на популярные вопросы об отказе от dockershim и о возможных последствиях.
Наши наблюдения
«Флант» обслуживает в production около 200 Kubernetes-кластеров, в которых развернуты тысячи приложений — в основном, конечно, с помощью Docker. Нам видится, что на текущий момент есть две важных проблемы с переходом на containerd — обе связаны с особенностями реализации containerd и Kubernetes. Проблемы решаемы, хотя и требуют некоторых усилий от DevOps/SRE-инженеров:
1. Изменение формата логов. Во многих проектах с использованием Docker настроены сборщики логов. У containerd собственный, текстовый формат логов. При переходе с Docker на containerd формат меняется, и сборщики приходится перенастраивать вручную. Сейчас это едва ли не основное препятствие для перехода на containerd, потому что перенастройка может занимать значительное время (в зависимости от масштаба инфраструктуры).
2. Блокировка Ceph RBD. Provisioner для сетевого хранилища Ceph RBD — старое решение, но оно до сих пор используется во многих проектах. Когда, например, приложение меняет узел, сетевой диск, который был подключен к старому узлу, должен вслед за приложением переключиться на новый узел. В случае с containerd это иногда не происходит: сетевой диск не переключается, и приложение перестает работать. Причина бага неясна, но проявляется он исключительно в связке provisioner — containerd. Один из вариантов избежать проблемы — использовать CSI-драйвер для Ceph RBD вместо provisioner«а.
Готовность платформы Deckhouse
Наша Kubernetes-платформа поддерживает и Docker, и containerd. При первоначальной настройке NodeGroup достаточно указать соответствующий тип CRI.
Также есть возможность автоматической миграции с Docker на containerd: в кластерах типа multi-master это можно сделать бесшовно, в single master — с простоем. Если простой критичен, single master можно временно перенастроить в multi-master (но для этого понадобятся дополнительные узлы). Обновление происходит плавно: по одному узлу в каждой NodeGroup.
P.S.
Читайте также в нашем блоге:
