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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

Вот


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

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

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

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

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


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

Значит придётся как то два containerd одновременно без конфликтов держать поднятым.
Да ну нет же! Docker ходит в containerd, и k8s ходит в containerd. Какие контейнеры запущены первым — знаете вы, какие запущены кубом — он знает сам. Вы просто попробуйте перенастроить куб на containerd и дальше поймете всё намного быстрее, чем в комментариях ;)
В блоге 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.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
flant.ru
Численность
51–100 человек
Дата регистрации

Блог на Хабре