Комментарии 24
Я как-то думал что k8s уже давно напрямую с containerd взаимодействует.
Про подобную схему читал вроде как пару лет назад:
Ах. похоже картинко не про то.
видимо docker shim это лишнее звено между contanerd и чистым Докер рантаймом? Наверняка в Опен шифт от этой схемы уже давно ушли
В OpenShift по умолчанию CRI-O (https://www.redhat.com/en/blog/red-hat-openshift-container-platform-4-now-defaults-cri-o-underlying-container-engine), про который мы писали (см. ссылки в конце этого перевода).
Собственно в том же посте была картинка про это
уже давно напрямую с containerd взаимодействуетон может, если это указать. Собственно о том и новость — если щас дефолт на докер, а хочешь напрямую containerd — можешь прописать, то скоро дефолт будет уже на него, а докер просто выкинут.
Совсем запутался.
Вот стоит у меня докер, который представляет собой containerd+dockerd+docker-proxy. Как объяснил creker ниже, теперь просто кубер будет использовать тот же containerd напрямую. То есть внутри кубера остаётся только часть докера. Не весь, но и полностью не вырезается.
containerd — часть докера, вынесенная в отдельный проект в рамках рефакторинга docker engine, чтобы его могли использовать другие проекты, а не только docker.
Если ничего не путаю, то только три года назад был технически и выделен и только год назад передан в управление CNCF из под управления Docker inc. И основные контрибьюторі на первый взгляд просто переключились с реп докера на новую. Де-юре это год как отдельный проект, де-факто мне сложно его таким сейчас считать.
Использую minikube native. Причём и контейнеры без кубера запущены. И слушают sock для всяких сервисных штук типа изменений в dnsmasq в том числе для кубера. Теперь мне как-то два containerd на одной машине надо будет подружить и учиться слушать с хоста события новогр?
Он же сейчас в докере спрятан, как-то так, что кубер напрямую достучаться до него не может.
Вот
Просто замените исполняемую среду от Docker'а на другую, которая поддерживается.
Исполняемая среда от Docker — containerd. Его нужно заменить на какой-то другой containerd. Но мне хочется иметь полноценный Докер на той же машине где поднят кубер. Значит придётся как то два containerd одновременно без конфликтов держать поднятым.
В комплекте с докером поставляется containerd, поверх которого докер давно и работает, который все и так умеет. Нужно всего лишь подправить ему настройки. Лично я это не делал конечно, но объективных причин невозможности я не вижу. Судя по всему, достаточно удалить строчку disabled_plugins = [«cri»] и натравить кублет на /var/run/docker/containerd/containerd.sock
Вот тут описано про компоненты.
Сначало containerd-shim стал необходим что-бы запуск контейнеров вообще от docker cli и проичего отвязать как я понимаю. тогда интерфейсы CRI, CNI только недавно появились… и докер распилили.
П.С. Хронологию точно не пытаюсь передать.
Значит придётся как то два containerd одновременно без конфликтов держать поднятым.Да ну нет же! Docker ходит в containerd, и k8s ходит в containerd. Какие контейнеры запущены первым — знаете вы, какие запущены кубом — он знает сам. Вы просто попробуйте перенастроить куб на containerd и дальше поймете всё намного быстрее, чем в комментариях ;)
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.
Не паникуйте: Kubernetes и Docker