Web-разработка

Kubernetes избавляется от Docker

05.01.2021

Как многие уже знают, Kubernetes с версии v1.20 прекращает использование Docker в качестве среды выполнения. Выбор сделан в пользу тех сред, что задействуют Container Runtime Interface (CRI), например containerd и CRI-O.

Однако причин для паники нет. Выпущено только указание о нежелательности применения Docker. Соответствующие предупреждения вы начнёте получать с версии v1.20, так что сразу вас это не затронет. Впереди ещё целый год, чтобы что-нибудь придумать, ведь поддержка Docker будет прекращена в версии v1.22, которую выкатят в конце 2021 года.

Но даже если к этому времени вы не будете готовы, у вас есть возможность не обновляться до версии v1.22: Kubernetes продолжит исправлять существующие версии с помощью разнообразных обновлений для системы безопасности.

Прежде чем подробно рассказывать о проведении миграции, давайте разберёмся, какие произойдут изменения и кого они затронут.

Что меняется?

Итак, какие произойдут изменения? Изменится только среда выполнения Kubernetes. Если Docker нужен вам для создания образов и тестирования в конвейере CI/CD во время разработки, то можете продолжать его использовать. Для запуска контейнеров докер используется containerd.

Но если задействуется containerd, зачем тогда вообще использовать Docker? Docker — это не просто среда запуска контейнеров. Она лишь формирует его сердцевину, которую Docker выделил в отдельный проект, называемый containerd. Наряду с этой сердцевиной, в Docker имеется множество слоёв пользовательского взаимодействия, которые позволяют разработчикам легко выполнять с ней те или иные действия.

Однако эти слои ничего не значат для машины. Более того, Kubernetes не может напрямую взаимодействовать с Docker из-за несовместимости последнего с CRI Kubernetes. Поэтому ему необходим ещё один слой, называемый dockershim, который добавляет сложности и без того сложной среде запуска контейнеров (см. изображение ниже):

Не слишком ли много их стало? Поэтому в Kubernetes решили постепенно отказаться от поддержки Docker, ведь он взаимодействует с containerd опосредованно, а Kubernetes делает это напрямую. Кроме того, Kubernetes нет дела ни о каком пользовательском интерфейсе: это всего лишь машина.

Кого затронут перемены?

Что же теперь, совсем отказаться от использования Docker? Ни в коем случае! У Docker есть и другой функционал. Помимо того, что это среда запуска контейнеров, Docker также предоставляет удобный для разработчиков контейнерный движок. Поэтому, если вы задействуете его для создания образов контейнеров и внутри конвейера CI/CD, можете продолжать его использовать.

Docker создаёт образ контейнера на основе стандарта OCI. Это означает, что докерный образ может отлично запускаться в любой соответствующей стандарту OCI среде запуска контейнеров, в том числе containerd и CRI-O.

Рассмотрим теперь слой оркестровки. Если вы используете Docker в качестве среды запуска контейнеров внутри кластера Kubernetes, перемены вас затронут. Придётся заменить его на поддерживаемую среду запуска контейнеров — containerd или CRI-О. Контейнеры докер прекрасно запускаются в обеих средах.

Если вы используете управляемые сервисы типа GKE, EKS или AKS, можете проверить параметры кластера и узнать, какая среда запуска контейнеров там задействуется. Во всех трёх по умолчанию используется containerd, и перемены вас, скорее всего, не коснутся, если вы не вносили никаких изменений.

Если вы по какой-то причине используете Docker, вам придётся связаться с облачным провайдером и убедиться, что вы получаете правильные, проверенные обновления в поддерживаемую среду выполнения. Облачные провайдеры предоставят пути миграции и всю необходимую помощь.

Если вы создали собственные кластеры или у вас необлачная установка, придётся немного повозиться и быть готовым к вынужденной приостановке работы. Нужно будет поменять среду запуска контейнеров и запустить её снова, корректируя файл crictl.yaml и указывая новую среду запуска контейнеров или разрешая kubeadm автоматически определять новую среду выполнения, и применить конфигурацию.

Если же вы не хотите допускать вынужденной приостановки работы, примените канареечный подход: разворачиваете дублирующий кластер с поддерживаемой средой запуска контейнеров и переносите туда свои рабочие нагрузки, а затем сворачиваете существующий.

Если у вас нет возможности или желания настраивать кластер Kubernetes самостоятельно на своем железе, можете купить его в готовом виде как сервис в облаке Mail.ru Cloud Solutions

Затронут ли перемены контейнерные рабочие нагрузки?

Было бы лучше знать ответ на этот вопрос до того, как пытаться мигрировать на новую среду выполнения. Если у вас есть конвейер CI/CD, работающий в Kubernetes и использующий подход Docker-in-Docker (DinD) через подключение сокет-файла /var/run/docker.sock — значит, перемены вас коснутся.

Запускать Docker в кластере Kubernetes вы не будете, поэтому придётся заменить его. Отличным решением будет Kaniko, так как он не использует Docker-демон для создания образов контейнеров.

Любые другие рабочие нагрузки перемены не затронут, так что можете запускать их в любой поддерживаемой среде запуска контейнеров.

Заключение

Хотя в Kubernetes решили отказаться от Docker в пользу сред запуска контейнеров с поддержкой CRI, паниковать не стоит. Слухи о смерти Docker оказались преувеличенными: перемены затронут только среды запуска контейнеров в кластере Kubernetes. А значит можно продолжать и дальше использовать Docker в разработке.

Подведём итог статьи наглядной блок-схемой: