company_banner

Docker is deprecated — и как теперь быть?

    Kubernetes объявил Docker устаревшим и планирует прекратить его использование примерно через год, в версии 1.22 или 1.23. Эта новость вызвала много вопросов и непонимания. В блоге Kubernetes появилось целых две статьи, разъясняющих смысл записи в Changelog (раз и два). Если все обобщить, то для разработчиков (те, которые Dev) ничего не меняется — они все так же могут продолжать использовать docker build для сборки своих контейнеров, а вот для инженеров, ответственных за эксплуатацию кластера (Ops), пришла пора разобраться и освоить несколько новых инструментов.

    Но для начала давайте вернемся в 2016 год, когда Kubernetes представил Container Runtime Interface (CRI). До версии Kubernetes 1.3 kubelet умел работать только с Docker, а в 1.3 анонсировали поддержку rkt Container Engine (этот проект уже прекратил свое существование). При этом код, отвечающий за взаимодействие с Docker и rkt, был глубоко и широко интегрирован в исходники kubelet. Процесс добавления поддержки rkt показал, что для добавления новых container runtime необходимо хорошо разбираться в устройстве и алгоритмах работы kubelet, а результат получился очень сложным для поддержки и развития.

    Поэтому решили все упростить, и добавили новую абстракцию — Container Runtime Interface. Весь код, реализующий высокоуровневый интерфейс работы с Docker, был убран из kubelet, а вместо него kubelet стал использовать CRI. Но тут возникла небольшая проблемка — Docker не умеет в CRI. Чтобы ее решить, в Kubernetes написали программу-прокладку между kubelet и Docker. С одной стороны она принимает запросы от kubelet через CRI, а с другой — транслирует их в docker-демон.

    И назвали эту программу dockershim, и вот как раз ее и хотят убрать к версии 1.23.

    Возвращаемся назад, в конец 2020 года, и смотрим чего у нас новенького по сравнению с 2016 в плане развития Container Runtime Interface.

    • Проект rkt закрыт.

    • RedHat создали и всячески продвигают свой собственный движок для запуска контейнеров CRI-O.

    • Монолитный Docker разделили на containerd, dockerd и docker-cli.

    В итоге у нас сейчас есть два движка для запуска контейнеров, которые умеют в CRI — это containerd и cri-o. Естественно, все эти события произошли не прямо в 2020 году, но массовый интерес к ним возник именно после объявления Kubernetes о прекращении поддержки Docker.

    Сборка

    Давайте же разберемся, чем нам это грозит. Начнем с наиболее частого вопроса: «Как же собирать образ контейнера с помощью containerd или cri-o?»

    И ответ очень простой: «Никак». Потому что containerd и cri-o предназначены только для запуска контейнеров из готовых образов. Плюс они умеют еще несколько вещей, необходимых для эксплуатации:

    • загрузка образов из интернета;

    • просмотр информации о запущенных подах и контейнерах;

    • удаление образов, подов и контейнеров;

    • подключение внутрь контейнера (запуск внутри контейнера процесса с bash).

    Но они не умеют ни собирать новый образ, ни пушить его в какой-либо registry. И как теперь быть?

    Начнем с того, что в 2015 году «Docker и остальные лидеры индустрии контейнеризации» основали Open Container Initiative (OCI) и опубликовали в ее рамках спецификацию формата хранения образов контейнеров. Эту спецификацию поддерживают Docker, containerd и cri-o, так что образ, собранный с помощью docker build на машине разработчика, должен без проблем запуститься с помощью containerd или cri-o. И так и происходит в подавляющем большинстве случаев, но время от времени попадаются «нюансы реализации». Эти нюансы, конечно, исправляются, но иногда не так быстро, как хотелось бы.

    Если вы за стабильность и минимальные изменения — запускайте новые кластеры с containerd в качестве движка контейнеризации. А на машинах разработчиков и CI runners сборки смело оставляйте Docker.

    Если вы выбрали безопасность из коробки, кровавый enterpise и платную поддержку, то наверняка используете Openshift (платформа на базе Kubernetes), в котором для запуска контейнеров применяется cri-o. А для сборки образов RedHat создала отдельную утилиту, которую назвала buildah. В отличие от Docker, этой утилите для сборки образов не нужен запущенный движок контейнеризации.

    Из альтернатив можно еще посоветовать kaniko — утилиту для сборки образов от Google. Она поставляется в виде образа контейнера, так что для запуска ей нужен движок контейнеризации, но для сборки — уже нет.

    Эксплуатация

    С разработкой разобрались, теперь пора перейти к самому интересному: что делать инженеру, который зашел на узел, чтобы разобраться, почему статус узла стал NotReady, набрал привычную команду docker ps, а в ответ получил docker: command not found.

    Фундаментальная проблема тут в том, что Docker изначально ориентировался на взаимодействие с человеком, и к последним версиям у него появился очень классный и удобный консольный интерфейс, а вот компоненты, реализующие CRI — они by design ориентированы на взаимодействие с программой-оркестратором, а не с человеком.

    Но внезапно оказалось, что человек тоже хочет взаимодействовать с CRI, и для этого была написана отдельная утилита crictl, которая представляет собой CLI-консоль к CRI-движку. То есть одна и та же утилита crictl позволяет посмотреть список контейнеров запущенных с помощью containerd или cri-o.

    Очень часто встречается информация, что можно просто заменить docker на crictl и вместо docker ps набирать crictl ps. Сказка заканчивается, когда вы попробуете запустить контейнер с помощью crictl run , и внезапно оказывается, что сначала надо создать манифест для PodSandbox, а уже потом написать манифест, описывающий контейнер, который будет запущен в этом поде.

    С другой стороны надо помнить, что CRI был придуман командой разработки Kubernetes и для Kubernetes, и поэтому, на мой взгляд, правильнее было бы его назвать Pod Runtime Interface.

    И crictl оптимизирован для работы с контейнерами, созданными kubelet. Например, в выводе не показываются служебные PODSandbox контейнеры, а имена контейнеров показываются в более понятном виде, чем в Docker. Да и возможности по работе с CLI постоянно улучшаются.

    Еще одна вещь, с которой часто возникают проблемы понимания. Многие путают docker (бинарник из пакета docker-cli) и dockerd (демон, управляющий контейнерами). Пытаются сделать crictl image save/load и внезапно оказывается, что в crictl таких команд нет. А на созданный issue авторы устало отвечают, что crictl — консоль для CRI runtime, который должен только запускать контейнеры, ну еще образ скачать из registry. А про манипуляции с образами в спецификации ничего нет.

    Но выход есть! Для манипуляции с образами контейнеров можно воспользоваться дополнительной утилитой skopeo, если вы используете cri-o, или утилитой ctr из комплекта containerd.

    И в завершение дам ответ на идею, которая наверняка возникнет после прочтения этой статьи:

    «Подождите, но ведь есть containerd, с которым умеет работать kubelet и dockerd! Давайте поставим Docker (три пакета docker-cli, docker, containerd), kubelet настроим на работу с containerd напрямую, и у нас при этом останется старая добрая команда docker».

    Вот только docker ps не покажет контейнеров, запущенных kubelet через CRI. Произойдет это из-за того, что containerd умеет работать в многопользовательском режиме, и docker с kubelet запускают контейнеры в различных containerd namespacesmoby и k8s.io соответственно (не надо путать их с kubernetes namespaces). Посмотреть на контейнеры в разных неймспейсах можно с помощью утилиты ctr -n <ns_name> container ls.

    Southbridge
    Обеспечиваем стабильную работу highload-проектов

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

      +32

      Отлично, освоил какое-то время назад докер, а теперь ещё и со внутренностями и дополнительными сущностями придётся разбираться! :(


      В статье также не хватает информации о podman, чтобы жизнь была ещё ярче.

        +2
        И хорошо что освоили, сам докер то никуда не исчезает. Он исчезает только из кубов.
          +5
          «Освоил докер» это же хорошо.
          Просто тут речь про «освоил мейнтенс и траблшутинг куб кластера».
          Если это не ваша работа или не ваш интерес в плане развития, то на эти изменения вам можно глубоко наплевать :)
            0

            Первое и возможно главное что надо знать о podman это то что эго консольный интерфейс на 99% совместим с docker.
            podman на моей рабочей федоре стоит месяца, я периодически строю и запускаю контейнеры, разницы в команндах не обнаружил пока.


            Конечно есть ньюансы и они делаю podmanинтереснее. К примеру нет никакого демон процесса как у dockerи не нужен root.

              +1

              Сразу же при знакомстве с buildah и podman я был сильно разочарован: на странице установки мне предлагают ставить пакеты для сборки и самостоятельно собирать эти продукты из исходников.


              Да, есть и бинарные пакеты для некоторых дистрибутивов, но, к примеру, нет пакетов под актуальные Ubuntu и Debian. На мой взгляд это не готовое решение, а полуфабрикат, который требуется приводить к состоянию продукта самостоятельно. В отличие от докера.

                0
                Такие вещи обычно делаются вот так hub.docker.com/r/buildah/buildah
                  +2

                  Для того, чтобы запустить podman, мне нужен установленный podman (или docker).
                  Я до сих пор не понял, это шутка от его разработчиков по мотивам winrar.rar или нет.

                    0

                    Если говорить о сборке образов, то я не вижу проблем, потому что речь о том, что в K8s не будет докера, но при этом там отлично будет работать buildah.

                  0

                  Не знаю о чем вы говорите, гоняю CI на podman и Ubuntu уже годами.
                  Не надо ничего приводить к состоянию продукта, вы что-то путаете.
                  https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable

              +39

              Тот момент когда радуешься, что забил на k8s много лет назад и тебе теперь не надо переучиваться :)

                0
                И что выбрали?
                  +2
                  Nomad очень хорош, особенно начиная с версии 1.0 с HCL2
                    +3
                    Terraform + ansible + docker.
                      0
                      и где это запускается?
                        +4

                        AWS, Google и голое железо

                        0

                        Terraform + ansible + docker podman

                    +27
                    Однажды из html отпочковались css/js. Программистам пришлось делиться на фронт\бэк-эндеров.

                    Однажды «по мотивам» С создали С++ (потом еще и Delphi/Java/.NET выросли). В мире программирования снова добавилось специализаций.

                    Сейчас «разрастается» технопарк контейнеров. Вновь предлагаются\принимаются стандарты, вынужденно меняются привычные инструменты, используются временные решения и протекают абстракции.

                    Впереди волшебные «обратная совместимость», «критичные зависимости», «Docker легаси», «переписывание конфигов на новую модную универсальную облачную технологию», и, наконец, «простой в освоении и легковесный инструмент для быстрого создания\развертывания образов типичных бизнес-приложений».
                      +7
                      Непонятно, при чем тут это все. Docker вовремя отдал все свои наработки в OCI и провел рефакторинг, благодаря чему мы сейчас имеем экосистему здорового человека — множество решений, совместимые между собой с четким делением функционала и абстракциями. На машине разраба докер, в CI докер или buildah, в кубере любой CRI совместимый рантайм вроде cri-o. И все это прекрасно сосуществует.
                        +4
                        Как и с любыми другими абстракциями — «сосуществование» ограничено мэйнстрим-сценариями. Архитектура, в которой код пишется в одной среде, строится в другой и работает в третьей — это не CI/CD, а среднее между лотереей и «русской рулеткой».
                          +5
                          Архитектура, в которой код пишется в одной среде, строится в другой и работает в третьей — это не CI/CD, а среднее между лотереей и «русской рулеткой».
                          Окружение, в котором код пишется, и в котором он работает в продакшене и так всегда разное, и рантайм для контейнеров тут не причём(и уж тем более CI/CD тут не причём).
                            0
                            Вообще-то он должен быть максимально похожим, собственно за это докер и любят
                              +1
                              Вообще не должен.
                              Докер это про изолированность и решение проблемы с совместимостью в пару кликов.
                              Но никак не за максимальную похожесть, особенно если речь идет о производительности.
                                +1
                                Оо
                                Докер — это прежде всего доставка кода! А потом уже изолированность. С совместимостью есть проблемы (когда ядра на хост машине сильно отличаются)
                              +3
                              Окружение, в котором код пишется, и в котором он работает в продакшене и так всегда разное

                              Не то, что бы я сильно понимал в докере, но разве это не рецепт по созданию на проде совершенно глупых багов?

                                –1
                                нет, можно вообще ничего не разворачивать у себя, либо по минимуму — ну там постгрес поставть локально. Все через тесты проверять, потом деплоить на дев, потом уже на прод.
                                  –1

                                  Вы на сервер IDE ставите? А доступ на запись в репозиторий git серверу даёте? Не получится у вас полностью идентичного окружения, ну вот никак.

                                    +1
                                    А причем тут IDE и запись в git? Ну, если мы говорим не о разработке плагина для IDE. Приложение на рабочей станции разработчика билдится в докер-образ для теста, потом билдится в такой же докер-образ на CI и запускается в тесте и проде, получаем одинаковое окружение приложения(одинаковые библиотеки, как минимум) на всех этапах. Отличаются только настройки, данные в БД\хранилище и нагрузка, да и то не всегда.
                                      +3
                                      Приложение на рабочей станции разработчика билдится в докер-образ для теста

                                      вот делать мне еще нечего как на своей машине докеры билдить. Код пишется в IDE, там же билдится, запускается, отлаживается. Близкое окружение только у CI и прода, потому что СI, собственно, контейнеры и билдит.

                                      А проблемы разного окружения просто решаются нормальными инструментами и языками, которые от любого чиха не разваливаются. Читай, дают reproducible builds из коробки.
                                        0
                                        Да, согласен, тут зависит от языка и инструментов. Не всегда и не все могут гарантировать что приложение, работающее из-под IDE с одними версиями библиотек заведется на версиях библиотек, лежащих в репозиториях из которых собирается образ. Поэтому нередко у нас разработчики интегрируют IDE с Docker и отлаживают сборку сразу в докере.
                                          –1
                                          Вы наверное никогда не сталкивались с багами серии: не знаю что там на проде, у меня всё работает.

                                          Всегда должна быть возможность воспроизвести на локальной машине близко к продакшену окружение
                                            0
                                            А проблемы разного окружения просто решаются нормальными инструментами

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

                                            0

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

                                      0
                                      Это называется спецификации и переносимость.
                                        +1
                                        Проведя в общей сложности 10 лет в разработке телеком и медицинских систем — где стандарты на спецификации и переносимость не только есть, но и соблюдаются — имею вам сказать что и то и другое покрывает только самые очевидные и простые взаимодействия. В телекоме даже специальные конференции проводят — «Test Fest» называются — куда разные компании привозят свое оборудование/ПО и в течении 5 дней пытаются заставить то, что в теории должно быть «плаг энд плей», хоть как-то заработать вместе.
                                          0
                                          Железо и ПО — таки несколько разные вещи.
                                            0
                                            Я имел в виду именно ПО в IP-сетях операторов/на телефонах. На уровне «железа» не приходилось работать, но думаю что там процессы принципиально не отличаются.
                                            Кстати, в медицине то же самое — если у CT разных производителей формат DICOM более-менее похож, то у MR могут совпадать только данные пациента и дата сканирования.
                                              0
                                              Если спецификации протоколов соблюдены, то всё должно работать. Собственно, на то протоколы и придуманы :)
                                                0
                                                У нас под рукой есть отличный пример — интернет. Живет полностью на RFC с тучей реализаций на самых разных языках. И ничего, все работает какой бы сложности не было применение. Таких примеров много, в том числе в железе — USB, PCI, UEFI. Тут тоже самое. Спеки есть, их видимо соблюдают, раз у нас столько разных реализаций между собой не конфликтуют. То, что в каких-то индустриях так не получается, ну это их проблемы. Лучше надо было работать, если хотелось все таки стандарты иметь.
                                                  +2
                                                  Это вы прикалываетесь так? «Все работает» более-менее только с хостами от Intel и девайсами от 5-6 ведущих производителей. Тот же Raspberry Pi (сделанный на чипе от Broadcom, далеко не последней фирмы) — нещадно глючит, например, если к нему подключить хаб или low- и high-speed устройства одновременно. А спецификации USB 2.0 уже 20 лет.
                                        +6
                                        Эту спецификацию поддерживают Docker, containerd и cri-o, так что образ, собранный с помощью docker build на машине разработчика, должен без проблем запустится с помощью containerd или cri-o. И так и происходит в подавляющем большинстве случаев, но время от времени попадаются «нюансы реализации». Эти нюансы, конечно, исправляются, но иногда не так быстро, как хотелось бы.
                                        Видимо, сосуществование не вполне прекрасное.

                                        Не поймите меня неправильно: я рад Docker-у и OCI. Своевременная передача наработок из Докера в OCI — это здорово, это лучше 99% других подобных случаев. Google, Docker, RedHat и прочие внесшие лепту заслуживают только уважения.

                                        Но мой внутренний пессимист настойчиво нашептывает на ухо: «это крупный проект, в котором замешаны интересы нескольких игроков. Сама история показывает, что через пару лет начнется раздрай, начнутся споры об обратной совместимости, обвинения в EEE и т.д.»

                                        Будет замечательно, если пессимист ошибётся, если участники OCI смогут сообща развивать технопарк контейнеров. Но, боюсь, пессимист не ошибется.
                                          –1
                                          Docker вовремя отдал все свои наработки в OCI

                                          Если бы отдал вовремя, не появился бы containerd
                                            +1

                                            А разве containerd — не та самая отданная "наработка" докера?

                                              0
                                              containerd это вырезанный и отданный в CNCF кусок докера www.docker.com/blog/containerd-joins-cncf
                                          0

                                          |Неясно следующее. Я в Dockerfile формирую среду выполнения, например устанавливаю дополнительные библиотеки и т.п. В каком файле теперь это будет происходить если мы говорим о к8s?

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

                                            А если вы делаете сборку в среде k8s то наверное надо смотреть в сторону Builda
                                            habr.com/ru/company/redhatrussia/blog/467105
                                              +2
                                              Насколько я понимаю, разницы в создании контейнеров нет — только в запуске
                                                0
                                                Если я правильно понял — да. Единственное что сломается точно — Docker in Docker. Но он, к счастью, нечасто нужен в кластере, а на машине девелопера он продолжит работать.
                                                  0

                                                  Если воркеры CI/CD развёрнуты в кластере… Ждём Docker in K8s)

                                                    +1

                                                    У нас сборка образов как раз в CI K8s делается. Так что даже любопытно стало, как это будет решаться.

                                                      +3
                                                      Очень просто. Переходите на buildah или makisu какой-нить и забываете про докер в CI. Мы помню перешли банально, чтобы ускорить билды. Тащить за собой докер только для того, чтобы образ собрать, формат которого стандартизирован, это все таки изврат.
                                                        0

                                                        У нас buildah проиграл DOCKER_BUILDKIT=1 docker build по скорости

                                                          0
                                                          Пробовали werf для сборки? Много фич, чтобы сильно ускорить её.
                                                            0

                                                            Пробовал, даже баг-репорт есть по результатам проб

                                              +10

                                              Когда так и не успел освоить докер, а он уже всё.

                                                +26

                                                Прямо как с JS-фреймворками :)


                                                +5
                                                Так докер совсем не всё, стоит его все-таки освоить.
                                                  0
                                                  Старая армейская мудрость
                                                  Не спеши выполнять приказ — подожди, пока его отменят
                                                  0
                                                  del
                                                    –1
                                                    Не проще ли добавить CRI в Docker?
                                                      0
                                                      Но выход есть! Для манипуляции с образами контейнеров можно воспользоваться дополнительной утилитой skopeo
                                                      Хех, спасительница
                                                        +7
                                                        Ох уж эти кликбейтные заголовки, по факту только унифицируются cli
                                                          +2
                                                          Вы не совсем правы. Тут скорее о том, что попытка сделать похожий cli совершенно другому инструменту привела к сложностям в понимании назначения и освоении
                                                            +18
                                                            Заголовок кликбейтный. Более того — вводит в заблуждение. Упоминание kubernetes не хватает как минимум. За место того чтобы разводить эту чуму — могли бы наоборот с ней бороться, как делают нормальные авторы. Хотя б назвали бы «Docker — не deprecated, хватит хайпить!». Вроде и вызывающе, но уже не вводит в заблуждение. Содержание более-менее, но заголовок меня в бешенство вводит
                                                              +7

                                                              "Я хотел воспользоваться докером — но оказалось, что он уже deprecated"

                                                                0

                                                                Мы добавили в свой PaaS поддержку BlobFuse Flex volume. Едва анонсировали для пользователей — появилось слово deprecated” в git репозитории к этому драйверу, как альтернатива — объявлен CSI драйвер (и только он будет поддерживаться с k8s 1.21), который “preview, not for production” сейчас, и “мы не уверены, что депрекейтед BlobFuse Flex volume поддерживается Майкрософтом” (смысл ответа на запрос к MS «что теперь делать?»).
                                                                И такое не редко. Наверное в современном мире успешнее не те, кто «старше, значит опытнее», а скорее те, кто «опытнее, значит более динамичные и гибкие» (это я о нас — тех, кто все эти компоненты и фреймворки использует).

                                                          0
                                                          habr.com/ru/search/?target_type=posts&q=docker&order_by=date
                                                          habr.com/ru/search/?target_type=posts&q=kubernetes&order_by=date
                                                          1K статей посвящено каждой. Прошло ВСЕГО 4 года, с 2016 по 2020. И в завершение что-то сломали?
                                                          Сорян, но на этом месте можно ставить R.I.P. Дальше читать FAQ не вижу смысла.
                                                            +2

                                                            То есть один containerd для dockerd и kubelet будет работать нормально, просто docker и kubectl не будут видеть контейнеры друг друга и могут быть сложности с пониманием почему не запускается что-то, хотя ресурсов вроде хватает — не хватает, просто не видно всех одновременно. Правильно?

                                                              +1
                                                              Правильно, так уже давно работает. В k8s кластере у вас только containerd, kubelet работает напрямую с ним, docker там ставить нет смысла. На локальной тачке у вас docker + containerd, но о существовании второго вы и не догадыватесь, для пользователя работа с containerd происходит прозрачно через docker. Так что у вас не должно быть ситуации «не видно всех», т.к. одновременно вы не будете kubelet и docker ставить на тачку
                                                                0
                                                                Ну почему, разные требования бывают. На винде вон кроме докера нативного ничего нет. Собственно, без решения этого кубер вряд ли сможет отказаться от его поддержки вообще и в соответствующей баги народ там уже жалуется на разрабов. Если очень прямо надо докер сокет, чтобы торчал в куберовский под (тот же CI), то можно прокинуть. И тут тот факт, что docker ps не видит куберовский контейнеры, уже не имеет значения.
                                                                  +1
                                                                  одновременно вы не будете kubelet и docker ставить на тачку

                                                                  Почему? Пускай без извращений гетерогенных контейнеров в одном проекте, а просто один проект на k8s в minikube nativ, а другой в docker-compose или тупо bash алиас к docker run для каких-то команд

                                                                –2
                                                                Уууу, повбывав бы падлюк…
                                                                  0
                                                                  Мне вот что не понятно теперь (без Docker) должно значительно уменьшится количество iptables правил и теоретически стабильнее будет работать при овер 100 подов на ноде?

                                                                  Или изменения на этого никак не коснуться?
                                                                    0
                                                                    Нет. в k8s докеру вообще запрещено что-то с iptables делать. Так что в этом плане ничего не изменится.
                                                                    iptables создают kube-proxy и CNI plugin
                                                                    Уменшить их количество можно переключив kube-proxy на режим ipvs
                                                                    или выбрать CNI plugin типа cilum, который использует eBPF — но тут надо понимать что вы делаете, а не бездумно следовать советам из интернета
                                                                    0
                                                                    Эти crio(1.20) и cri-tools — прям боль. Документации нет, информации нет. Что-то не работает, приходится сидеть голову ломать по нескольку дней.
                                                                    Думаю, дай для эксперимента исключу кубер и создам контейнер «alpine» напрямую, через crictl. И тут выясняется, что тот огрызок информации, что хранится в репе на гите, не соответствует действительности. Выясняется, что информации по возможным параметрам конфига нет нигде, а запуск pod'a с конфигом из 5 строк из examples выдаст ошибку. Pod запустится, но в Ready не перейдет. Ошибку, которую не понять, потому что «не найден контейнер с ID <id pod'a>», и, внезапно, даже не нагуглить.
                                                                      0
                                                                      Путем экспериментов выяснилось, что это кубер не дает создать контейнер. На чистой машине без кубера все заработало. Но опять же, это надо еще догадаться.

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

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