Как многие уже знают, 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 в разработке.
Подведём итог статьи наглядной блок-схемой:
Спасибо за внимание! Надеюсь, статья вам понравилась.
Читайте также:
- Airflow и Kubernetes - лучшее решение для конвейеров данных Geoblink
- Устранение неполадок в Kubernetes - стратегический подход
- Kubernetes: сэкономьте до 50% с вытесняемыми объектами
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Gaurav Agarwal: Kubernetes Is Deprecating Docker
