company_banner

Не паникуйте: Kubernetes и Docker

Автор оригинала: Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan Papandrea, Jeffrey Sica, Davanum Srinivas
  • Перевод
Прим. перев.: свежая публикация в блоге Kubernetes — оперативный ответ на ту шумиху, что поднялась вокруг грядущего релиза K8s, в котором поддержка Docker будет объявлена устаревшей. Представляем вашему вниманию её перевод.



Начиная с версии 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.

Читайте также в нашем блоге:

Флант
DevOps-as-a-Service, Kubernetes, обслуживание 24×7

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

    +1

    Я как-то думал что k8s уже давно напрямую с containerd взаимодействует.


    Про подобную схему читал вроде как пару лет назад:
    imagehttps://github.com/containerd/cri/raw/master/docs/cri.png

      0

      Ах. похоже картинко не про то.
      видимо docker shim это лишнее звено между contanerd и чистым Докер рантаймом? Наверняка в Опен шифт от этой схемы уже давно ушли

        0

        В OpenShift по умолчанию CRI-O (https://www.redhat.com/en/blog/red-hat-openshift-container-platform-4-now-defaults-cri-o-underlying-container-engine), про который мы писали (см. ссылки в конце этого перевода).

          0
          dockershim это звено между самим докер демоном и кубером. Именно это звено убирают. Т.к. докер демон сам работает поверх containerd, то можно просто ставить на кубер ноду докер, включать CRI плагин в его комплектном containerd и натравливать на него кубер. Все, докер и кубер спокойно продолжают жить вместе. Немного по-другому (docker CLI больше не будет видеть контейнеры кубера), но продолжают.

          Собственно в том же посте была картинка про это
          Заголовок спойлера
          image
            0

            Ну тоесть изменение находится в месте стрелочки <--> которя между containerd и dockerd.
            если я вас правильно понял. После второго прочита я это тоже так понял.

          0
          уже давно напрямую с containerd взаимодействует
          он может, если это указать. Собственно о том и новость — если щас дефолт на докер, а хочешь напрямую containerd — можешь прописать, то скоро дефолт будет уже на него, а докер просто выкинут.
          +2
          Так я не понял, докер остается и мы не переживаем?
            0
            Внутри кубера — нет. В разработке можете использовать и дальше.
              0

              Совсем запутался.


              Вот стоит у меня докер, который представляет собой containerd+dockerd+docker-proxy. Как объяснил creker ниже, теперь просто кубер будет использовать тот же containerd напрямую. То есть внутри кубера остаётся только часть докера. Не весь, но и полностью не вырезается.

                0
                containerd не является частью докера. Докер, как и кубер, просто использует containerd, в своих целях.
                  +1

                  containerd — часть докера, вынесенная в отдельный проект в рамках рефакторинга docker engine, чтобы его могли использовать другие проекты, а не только docker.

                    0
                    Ну так оно уже давно отдельная сущность. А то так можно договориться до того, что FreeBSD раньше было BSD Unix, например.
                      0

                      Если ничего не путаю, то только три года назад был технически и выделен и только год назад передан в управление CNCF из под управления Docker inc. И основные контрибьюторі на первый взгляд просто переключились с реп докера на новую. Де-юре это год как отдельный проект, де-факто мне сложно его таким сейчас считать.

                        0
                        То, что она отдельная, не меняет того факта, что это часть докера как продукт. docker состоит из нескольких частей — как минимум cli, докер демон и containerd. Благодаря этой модульности и можно продолжать использовать докер с кубером. Собственно, к этому и стремились.
              0

              Использую minikube native. Причём и контейнеры без кубера запущены. И слушают sock для всяких сервисных штук типа изменений в dnsmasq в том числе для кубера. Теперь мне как-то два containerd на одной машине надо будет подружить и учиться слушать с хоста события новогр?

                0
                Зачем второй containerd?
                  0

                  Он же сейчас в докере спрятан, как-то так, что кубер напрямую достучаться до него не может.

                    0
                    В смысле «не может»? Очень даже может, если сокет containerd кубу указать. Куб давным-давно умеет работать с containerd, это описано в документации и настраивается элементарно.
                      0

                      Вот


                      Просто замените исполняемую среду от Docker'а на другую, которая поддерживается.

                      Исполняемая среда от Docker — containerd. Его нужно заменить на какой-то другой containerd. Но мне хочется иметь полноценный Докер на той же машине где поднят кубер. Значит придётся как то два containerd одновременно без конфликтов держать поднятым.

                        +3
                        В этом вся проблема этих постов последних — никто толком не упоминает что такое docker-shim, какое отношение containerd имеет к докеру, что вообще есть современный докер и т.д. В итоге народ разводит панику, а все на самом деле куда проще и ничего страшного с докером не произошло.

                        В комплекте с докером поставляется containerd, поверх которого докер давно и работает, который все и так умеет. Нужно всего лишь подправить ему настройки. Лично я это не делал конечно, но объективных причин невозможности я не вижу. Судя по всему, достаточно удалить строчку disabled_plugins = [«cri»] и натравить кублет на /var/run/docker/containerd/containerd.sock
                          0

                          Вот тут описано про компоненты.
                          Сначало containerd-shim стал необходим что-бы запуск контейнеров вообще от docker cli и проичего отвязать как я понимаю. тогда интерфейсы CRI, CNI только недавно появились… и докер распилили.


                          П.С. Хронологию точно не пытаюсь передать.

                          +2
                          Значит придётся как то два containerd одновременно без конфликтов держать поднятым.
                          Да ну нет же! Docker ходит в containerd, и k8s ходит в containerd. Какие контейнеры запущены первым — знаете вы, какие запущены кубом — он знает сам. Вы просто попробуйте перенастроить куб на containerd и дальше поймете всё намного быстрее, чем в комментариях ;)
                            +1

                            Расходимся ))

                  0
                  В блоге Docker тоже появилось пояснение ситуации: «What developers need to know about Docker, Docker Engine, and Kubernetes v1.20». Их TL;DR можно свести к такому:

                  You can continue to build and run Docker images locally and in your Kubernetes cluster as this deprecation will not impact that experience.

                  [..]

                  Today, and in Kubernetes v1.20, Kubernetes administrators can continue to use docker commands and kubectl commands to manage their Kubernetes clusters.

                  In a future release of Kubernetes, a few minor releases from now, when support for dockershim is eventually removed, you will no longer be able to use docker commands to inspect your cluster.

                  Many of these commands have similar commands in kubectl and ctr (the containerd CLI). While the commands to inspect your cluster in Kubernetes may change in the future, Developers will still be able to use Docker tools to docker build, docker push and docker run containers and container images on Kubernetes.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое