Прим. перев.: свежая публикация в блоге Kubernetes — оперативный ответ на ту шумиху, что поднялась вокруг грядущего релиза K8s, в котором поддержка Docker будет объявлена устаревшей. Представляем вашему вниманию её перевод.
Начиная с версии v1.20, Kubernetes отказывается от Docker как от исполняемой среды контейнеров.
Но не паникуйте. Не все так страшно, как представляется на первый взгляд.
TL;DR. Kubernetes отказывается от Docker в пользу сред выполнения на базе Container Runtime Interface (CRI), разработанного специально для Kubernetes. Образы для Docker продолжат работать во всех средах выполнения как обычно.
Для конечных пользователей Kubernetes мало что изменится. Все это не означает, что Docker «умрет» или что его больше не следует/нельзя использовать для разработки. Docker по-прежнему останется отличным инструментом для сборки контейнеров, а образы, собранные с помощью
Если вы пользуетесь услугами managed Kubernetes вроде GKE или EKS, следует убедиться, что ваши worker'ы используют поддерживаемую версию исполняемой среды, и сделать это до того, как поддержка Docker будет убрана в будущей версии K8s. Если ваши узлы имеют специфичные настройки, скорее всего, придется обновить с учетом соответствующих требований к окружению и среде выполнения. Мы рекомендуем обратиться к поставщику услуг и обговорить все вопросы, связанные с тестированием и планированием обновления.
Если вы выкатываете кластеры самостоятельно, вам также придется внести соответствующие изменения, чтобы избежать проблем. При обновлении на v1.20 вы получите предупреждение об устаревании Docker. Полностью отказаться от Docker разработчики планируют в версии 1.23, релиз которой намечен на конец 2021 года. С ее выходом придется переключиться на одну из совместимых исполняемых сред — например, containerd или CRI-O. Просто убедитесь, что выбранная среда поддерживает используемые вами конфигурации Docker-демона (например, логирование).
На самом деле речь идет о двух совершенно разных средах, и это создает путаницу. Внутри кластера Kubernetes имеется так называемая исполняемая среда контейнеров (container runtime), которая отвечает за загрузку и запуск контейнерных образов. И Docker весьма популярен в качестве инструмента организации этой среды (также широко известны containerd и CRI-O). Однако Docker не был разработан для встраивания в Kubernetes, и это создает ряд проблем.
«Docker» — это не отдельный инструмент, а целый технологический стек, и один из его компонентов называется «containerd» (мы писали о нем подробнее здесь — прим. перев.) и выступает высокоуровневой исполняемой средой для контейнеров. Docker популярен и удобен благодаря огромному количеству дополнений для пользователей, сильно упрощающих процесс взаимодействия с данным инструментом во время разработки. Однако все эти UX-усовершенствования не нужны Kubernetes, ведь он не человек.
Из-за этого дружественного к пользователю уровня абстракции кластер Kubernetes вынужден использовать другой инструмент — Dockershim, — чтобы «достучаться» до того, что ему действительно необходимо: containerd. И это плохо, поскольку такую дополнительную прослойку приходится обслуживать и она тоже может «сломаться». В реальности же получается следующее: в Kubernetes v1.23 Dockershim будет убран из Kubelet'а — соответственно, Docker лишится поддержки как среда выполнения контейнеров. Возникает вопрос: если containerd уже включен в стек Docker, зачем Kubernetes нужен Dockershim?
Дело в том, что Docker не совместим с Container Runtime Interface (CRI). Если бы он был совместим, нам не нужна была бы дополнительная прослойка, и все было бы шикарно. Впрочем, это не конец света и не повод для паники. Просто замените исполняемую среду от Docker'а на другую, которая поддерживается.
Обратите внимание: если вы используете сокет Docker'а (
Это нашумевшее изменение касается совершенно другой среды, отличной от той, которую большинство людей используют для взаимодействия с Docker'ом. Инсталляция Docker'а для разработки никак не связана с исполняемой средой внутри кластера Kubernetes. Да, это сбивает с толку, я знаю…
Даже после нововведения Docker останется все тем же полезным инструментом для разработчиков. Создаваемые Docker'ом образы могут работать не только с ним. Это полноценные образы OCI. А любой OCI-совместимый образ будет выглядеть одинаково для Kubernetes независимо от инструмента, с помощью которого он собирался. containerd и CRI-O прекрасно умеют извлекать эти образы и запускать их. Именно для этого и создавался стандарт для контейнеров.
Итак, грядут перемены. Некоторые люди, конечно, столкнутся с определенными проблемами. Но здесь не о чем жалеть или переживать, ведь прогресс — это классная штука. В зависимости от того, как именно вы используете Kubernetes, для вас это может означать либо полное бездействие, либо необходимость приложить минимум усилий. В долгосрочной перспективе подобное нововведение только все упростит.
Если предстоящие перемены все еще сбивают вас с толку, то все в порядке. В Kubernetes множество движущихся частей, и никто не является экспертом в нем на 100%. Пожалуйста, задавайте любые вопросы, независимо от уровня опыта или сложности! Наша цель — максимально подготовить всех к предстоящим переменам. <3 Надеемся, этот материал ответил на большинство ваших вопросов и рассеял все опасения и тревоги!
Нужно больше ответов? Ознакомьтесь с FAQ об устаревании Dockershim.
В обсуждении этой темы на Reddit можно также найти развёрнутый ответ Tim Hockin — одного из разработчиков Kubernetes.
Читайте также в нашем блоге:
Начиная с версии v1.20, Kubernetes отказывается от Docker как от исполняемой среды контейнеров.
Но не паникуйте. Не все так страшно, как представляется на первый взгляд.
TL;DR. Kubernetes отказывается от Docker в пользу сред выполнения на базе Container Runtime Interface (CRI), разработанного специально для Kubernetes. Образы для Docker продолжат работать во всех средах выполнения как обычно.
Для конечных пользователей Kubernetes мало что изменится. Все это не означает, что Docker «умрет» или что его больше не следует/нельзя использовать для разработки. Docker по-прежнему останется отличным инструментом для сборки контейнеров, а образы, собранные с помощью
docker build, продолжат работать в K8s-кластере.Если вы пользуетесь услугами managed Kubernetes вроде GKE или EKS, следует убедиться, что ваши worker'ы используют поддерживаемую версию исполняемой среды, и сделать это до того, как поддержка Docker будет убрана в будущей версии K8s. Если ваши узлы имеют специфичные настройки, скорее всего, придется обновить с учетом соответствующих требований к окружению и среде выполнения. Мы рекомендуем обратиться к поставщику услуг и обговорить все вопросы, связанные с тестированием и планированием обновления.
Если вы выкатываете кластеры самостоятельно, вам также придется внести соответствующие изменения, чтобы избежать проблем. При обновлении на v1.20 вы получите предупреждение об устаревании Docker. Полностью отказаться от Docker разработчики планируют в версии 1.23, релиз которой намечен на конец 2021 года. С ее выходом придется переключиться на одну из совместимых исполняемых сред — например, containerd или CRI-O. Просто убедитесь, что выбранная среда поддерживает используемые вами конфигурации Docker-демона (например, логирование).
Из-за чего вся эта неразбериха и почему все так переживают?
На самом деле речь идет о двух совершенно разных средах, и это создает путаницу. Внутри кластера Kubernetes имеется так называемая исполняемая среда контейнеров (container runtime), которая отвечает за загрузку и запуск контейнерных образов. И Docker весьма популярен в качестве инструмента организации этой среды (также широко известны containerd и CRI-O). Однако Docker не был разработан для встраивания в Kubernetes, и это создает ряд проблем.
«Docker» — это не отдельный инструмент, а целый технологический стек, и один из его компонентов называется «containerd» (мы писали о нем подробнее здесь — прим. перев.) и выступает высокоуровневой исполняемой средой для контейнеров. Docker популярен и удобен благодаря огромному количеству дополнений для пользователей, сильно упрощающих процесс взаимодействия с данным инструментом во время разработки. Однако все эти UX-усовершенствования не нужны Kubernetes, ведь он не человек.
Из-за этого дружественного к пользователю уровня абстракции кластер Kubernetes вынужден использовать другой инструмент — Dockershim, — чтобы «достучаться» до того, что ему действительно необходимо: containerd. И это плохо, поскольку такую дополнительную прослойку приходится обслуживать и она тоже может «сломаться». В реальности же получается следующее: в Kubernetes v1.23 Dockershim будет убран из Kubelet'а — соответственно, Docker лишится поддержки как среда выполнения контейнеров. Возникает вопрос: если containerd уже включен в стек Docker, зачем Kubernetes нужен Dockershim?
Дело в том, что Docker не совместим с Container Runtime Interface (CRI). Если бы он был совместим, нам не нужна была бы дополнительная прослойка, и все было бы шикарно. Впрочем, это не конец света и не повод для паники. Просто замените исполняемую среду от Docker'а на другую, которая поддерживается.
Обратите внимание: если вы используете сокет Docker'а (
/var/run/docker.sock) в рамках обычного рабочего процесса, то после перехода на другую среду уже не сможете с ним работать. Подобный паттерн часто называется «Docker в Docker'е». Обойти эту проблему можно с помощью множества различных инструментов, в том числе kaniko, img и buildah.Как эта перемена отразится на разработчиках? Будем ли мы по-прежнему писать Dockerfile'ы? Будем ли собирать образы с помощью Docker'а?
Это нашумевшее изменение касается совершенно другой среды, отличной от той, которую большинство людей используют для взаимодействия с Docker'ом. Инсталляция Docker'а для разработки никак не связана с исполняемой средой внутри кластера Kubernetes. Да, это сбивает с толку, я знаю…
Даже после нововведения Docker останется все тем же полезным инструментом для разработчиков. Создаваемые Docker'ом образы могут работать не только с ним. Это полноценные образы OCI. А любой OCI-совместимый образ будет выглядеть одинаково для Kubernetes независимо от инструмента, с помощью которого он собирался. containerd и CRI-O прекрасно умеют извлекать эти образы и запускать их. Именно для этого и создавался стандарт для контейнеров.
Итак, грядут перемены. Некоторые люди, конечно, столкнутся с определенными проблемами. Но здесь не о чем жалеть или переживать, ведь прогресс — это классная штука. В зависимости от того, как именно вы используете Kubernetes, для вас это может означать либо полное бездействие, либо необходимость приложить минимум усилий. В долгосрочной перспективе подобное нововведение только все упростит.
Если предстоящие перемены все еще сбивают вас с толку, то все в порядке. В Kubernetes множество движущихся частей, и никто не является экспертом в нем на 100%. Пожалуйста, задавайте любые вопросы, независимо от уровня опыта или сложности! Наша цель — максимально подготовить всех к предстоящим переменам. <3 Надеемся, этот материал ответил на большинство ваших вопросов и рассеял все опасения и тревоги!
Нужно больше ответов? Ознакомьтесь с FAQ об устаревании Dockershim.
P.S. от переводчика
В обсуждении этой темы на Reddit можно также найти развёрнутый ответ Tim Hockin — одного из разработчиков Kubernetes.
Читайте также в нашем блоге:
- «Зрелая исполняемая среда для контейнеров: containerd стал „выпускником“ CNCF»;
- «Red Hat заменяет Docker на Podman»;
- «Интеграция containerd с Kubernetes, заменяющая Docker, готова к production»;
- «CRI-O — альтернатива Docker для запуска контейнеров в Kubernetes».
