Почему K8s отказывается от Docker
Недавно в процессе изучения технологии контейнеров я увидел кое-что о том, что Kubernetes «отказывается от Docker», и я беспокоился о том, ценно ли изучение Docker сейчас, и должен ли я сейчас переключиться на containerd или другие среды выполнения.
При более глубоком понимании в этих сомнениях есть доля правды. Три года назад, когда Kubernetes выпустил новость «отказаться от Docker», это действительно вызвало «шум» в сообществе Kubernetes, и влияние даже распространилось за пределы сообщества, что также заставило Kubernetes написать несколько блогов, чтобы повторить «Объясните, почему вы это сделали». этот. Прошло три года, и хотя Kubernetes 1.24 достиг цели «deprecation», четкого понимания по этому поводу до сих пор нет, так что запишите всю историю этого инцидента.
Предыстория: эволюция Kubernetes
Чтобы понять, почему K8s «забросил Docker», мы должны просмотреть историю развития K8s.
Kubernetes — это среда оркестровки контейнерной инфраструктуры с открытым исходным кодом, выпущенная Google еще в 2014 году. Эта технология имеет теоретическую основу, а именно: Borg. Borg является частью всей инфраструктурной системы Google.Borg является частью всей инфраструктурной системы Google.Google также опубликовал ряд статей о Borg в качестве своей теоретической поддержки. Он содержит множество передовых технологий в отрасли, таких как MapReduce и BigTable. Поэтому система Borg всегда считалась самым мощным «секретным оружием» в Google, а также наименее вероятным проектом Google с открытым исходным кодом, и Kubernetes разработан на этой теоретической основе. На рисунке ниже показан стек общедоступной инфраструктуры Google, описанный в документе Google Omega.
Архитектура проекта Kubernetes (как показано на рисунке ниже) очень похожа на его прототип проекта Borg, который состоит из двух узлов, Master и Node, которые соответствуют управляющим узлам и вычислительным узлам соответственно.
-
Мастер-узел также является управляющим узлом, он является центром всего кластера и поддерживает состояние, он отвечает за поддержание состояния всего кластера Kubernetes. Он состоит из трех независимых компонентов: kube-apiserver для служб API, kube-scheduler для планирования и kube-controller-manager для оркестровки контейнеров. Постоянные данные всего кластера обрабатываются kube-api-server и сохраняются в Etcd. Чтобы обеспечить единую ответственность, главный узел обычно не развертывает контейнеры.
Руководство Borg для Kubernetes отражено в главном узле.Хотя детали реализации главных узлов Borg и Kubernetes могут различаться, их отправная точка одинакова, то есть как упорядочивать, управлять и планировать задания, отправляемые пользователями.
-
Узел Node также является вычислительным узлом, где фактически работает развернутый контейнер. Его ядром является компонент kubelet (на главном узле также будет компонент kubelet).Kubelet в основном отвечает за работу со средой выполнения контейнера (например, проект Docker) и использует интерфейс удаленного вызова CRI (Container Интерфейс времени выполнения). Этот интерфейс определяет основные операции среды выполнения контейнера, такие как все параметры, необходимые для запуска контейнера. Вот почему проекту Kubernetes все равно, какую среду выполнения контейнера вы используете.Пока среда выполнения контейнера может запускать стандартные образы контейнеров, ее можно подключить к проекту Kubernetes путем реализации CRI.
Конкретные среды выполнения контейнеров, такие как проект Docker, обычно взаимодействуют с базовой операционной системой Linux через спецификацию среды выполнения контейнера OCI, то есть преобразуют запросы CRI в вызовы операционной системы Linux, такие как вызов Namespace и Cgroups.
Кроме того, kubelet также взаимодействует с подключаемым модулем устройства через протокол gRPC.Этот подключаемый модуль является основным компонентом, используемым Kubernetes для управления физическими хост-устройствами, такими как графические процессоры.Это также функция, на которую следует обратить внимание при обучении машинному обучению и поддержка высокопроизводительных заданий на основе проектов Kubernetes.
Kubelet также может вызывать сетевые подключаемые модули и подключаемые модули хранилища для настройки сети и постоянного хранилища для контейнеров через интерфейсы CNI (контейнерный сетевой интерфейс) и CSI (контейнерный интерфейс хранилища) соответственно.
Название kubelet происходит от родственного компонента Borglet в проекте Borg. Однако проект Borg не поддерживает технологию контейнеров, а просто использует групповые группы Linux для ограничения процесса. Это означает, что «образы контейнеров», такие как Docker, не существуют в Borg, поэтому нет необходимости управлять образами контейнеров, но Google внутри использует инструмент управления пакетами под названием Midas Package Manager (MPM). Докер образ. Кроме того, компонентам Borglet не нужно думать о том, как взаимодействовать с Docker, и им не нужно поддерживать многие интерфейсы контейнерных технологий, такие как CRI, CNI и CSI. Можно сказать, что kubelet — это компонент, повторно реализованный для реализации возможностей управления контейнерами Kubernetes, и он не имеет прямого отношения наследования к Borg.
Проект Kubernetes не использовал Docker в качестве ядра всей архитектуры, как различные проекты «облака контейнеров» одновременно, а реализовал его только как среду выполнения контейнера самого низкого уровня. Это эквивалентно рассмотрению Docker как нового метода упаковки приложений, поэтому прошлый опыт Борга в крупномасштабном управлении заданиями и оркестровке можно напрямую применить к проекту Kubernetes.
ЦРИ
А в 2014 году Docker был в самом расцвете, K8s только родился, и хотя у него была поддержка Google и Borg, он все еще был относительно новым.
Поэтому K8s сначала выбрал поддержку Docker.
Перенесемся в 2016 год, через год после основания CNCF, и K8s также выпустила версию 1.0, которую можно официально использовать в производственных средах. Все это показывает, что K8s вырос.
Поэтому он объявил о присоединении к CNCF и стал первым хостинг-проектом CNCF. Он хочет использовать мощь фонда, чтобы объединиться с другими производителями, чтобы «победить» Докера.
В версии 1.5 в конце 2016 года K8s представила новый стандарт интерфейса: CRI: Container Runtime Interface интерфейс времени выполнения контейнера.
CRI использует ProtoBuffer и gPRC, чтобы указать, как kubelet должен вызывать среду выполнения контейнера для управления контейнерами и образами, но это новый набор интерфейсов, полностью несовместимых с предыдущими вызовами Docker.
Очевидно, что он больше не хочет быть привязанным к Docker и разрешает доступ к другим контейнерным технологиям (таким как rkt, kata и т. д.) на нижнем уровне и может «запустить» Docker в любое время.
Но в это время Docker очень зрелый, и инерция рынка тоже очень сильна. Крупные поставщики облачных услуг не могут сразу заменить Docker.
Поэтому K8s может одновременно предоставить только «компромиссное» решение, добавив «адаптер» между kubelet и Docker для преобразования интерфейса Docker в интерфейс, совместимый с CRI:
Поскольку этот «адаптер» зажат между kubeletDocker и Docker, его метко называют «shim», что означает «прокладка».
С CRI и прокладкой, хотя K8s по-прежнему использует Docker в качестве базовой среды выполнения, он также имеет условия для отделения от Docker, тем самым приоткрывая завесу «отказа от Docker».
Контейнер
Столкнувшись с проблемой, Docker принял стратегию «выжить со сломанной рукой», чтобы продвигать собственную реконструкцию, разделив исходный Docker Engine с одной архитектурой на несколько модулей, из которых часть демона Docker была передана в дар CNCF, и был сформирован containerd.
Как проект, размещенный на CNCF, containerd должен быть совместим с CRI. Однако по многим причинам Docker вызывается только containerd в Docker Engine, а внешний интерфейс остается неизменным, то есть он не совместим с CRI.
Из-за «упрямства» Докера в настоящее время в K8s есть две цепочки вызовов:
- Используйте интерфейс CRI для вызова dockershi, затем dockershi вызывает Docker, а Docker переходит к containerd
для управления контейнером. - Используйте интерфейс CRI для прямого вызова containerd для управления контейнером.
Очевидно, что из-за того, что containerd используется для управления контейнерами, конечный эффект от двух цепочек вызовов точно такой же, но второй метод удаляет две ссылки dockershim и Docker Engine, что более лаконично и понятно, и имеет лучшую производительность.
Когда в 2018 году был выпущен Kubernetes 1.10, containerd также был обновлен до версии 1.1, официально интегрирован с Kubernetes и опубликован [сообщение в блоге](https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration -gos-ga / "сообщение в блоге"), чтобы отобразить некоторые данные теста производительности:
Из этих данных видно, что по сравнению с Docker 18.03 на тот момент задержка запуска containerd1.1Pod сократилась примерно на 20%, использование ЦП уменьшилось на 68%, а использование памяти уменьшилось на 12%. %.Такой значительный прирост производительности выгоден поставщикам облачных услуг.Очень заманчиво сказать.
Устаревший Docker
В 2020 году K8s 1.20 наконец-то официально «объявляет войну» Docker: kubelet прекратит поддержку Docker и будет полностью удален в будущих версиях.
Но поскольку Docker стал почти синонимом технологии контейнеров, а K8s использует Docker уже много лет, объявление быстро «запахло» по мере его распространения, а фраза «kubelet прекратит поддержку Docker» превратилась в нечто более привлекательное «K8s будет устаревшей». Докер".
Это, естественно, вызвало панику в ИТ-индустрии, и «люди, которые не знали правды», выразили свой шок:
Докер, которым так долго пользовались, вдруг нельзя использовать.
Почему K8s так относится к Docker?
Сойдут ли предыдущие вложения в Docker в ноль? Как насчет большого количества существующих изображений?
На самом деле, если вы разбираетесь в упомянутых выше двух проектах CRI и containerd, то будете знать, что в этом переезде K8s нет ничего удивительного, все «естественно»: по сути, это просто «отказ от докеров», то есть выселение докеров. kubelet не является программным продуктом, который «отказывается от Docker».
Таким образом, «отказ от Docker» мало влияет на K8s и Docker, потому что они изменили нижний уровень на containerd с открытым исходным кодом, а исходные образы и контейнеры Docker по-прежнему могут нормально работать. Единственное изменение заключается в том, что K8s обходит Docker и напрямую вызывает containerd внутри Docker.
Тем не менее, некоторое влияние все же будет. Если K8s напрямую использует containerd для работы с контейнерами, то это рабочая среда, независимая от Docker, и ни один из них не может получить доступ к контейнерам и образам, которыми управляет другой. Другими словами, использование команды docker ps не увидит контейнеры, работающие в K8s.
Некоторым может потребоваться некоторое время, чтобы привыкнуть к новому инструменту crictl и использовать его, но подкоманды для просмотра контейнеров и изображений остались прежними, например, ps, images и т. д., и их нетрудно адаптировать (если вы использовал kubectl Manage K8s, это не имеет никакого эффекта).
Первоначально K8s планировал завершить работу по «прекращению поддержки докеров» за год, но действительно недооценил основу Docker. В версии 1.23 так и не удалось убрать докершим, поэтому его пришлось отложить на пол года. Наконец, версия 1.24 убрала докерский код из kubelet.
С тех пор пути Kubernetes и Docker полностью «разошлись».
Заключение: будущее Docker
Итак, что ждет Docker в будущем? Неужели для него нет места в эпоху облачных вычислений? Ответ на этот вопрос, очевидно, нет.
Как основатель технологии контейнеров, никто не может сомневаться в историческом статусе Docker. Хотя K8s больше не привязан к Docker по умолчанию, Docker по-прежнему может сосуществовать с другими формами K8s.
Прежде всего, поскольку формат образа контейнера был стандартизирован (спецификация OCI, Open Container Initiative), образ Docker по-прежнему можно нормально использовать в K8s, и нет необходимости изменять исходный тест разработки и процесс CI/CD. Мы все еще можем получить Docker Hub или написать Dockerfile для упаковки приложения.
Во-вторых, Docker — это полная линейка программных продуктов, а не только containerd, она также включает в себя множество сервисов, таких как сборка образов, распространение, тестирование, и даже K8s встроен в Docker Desktop.
С точки зрения удобства разработки контейнеров, Docker пока сложно заменить. Большинство облачных разработчиков могут продолжать работать в этой знакомой среде, используя Docker для разработки приложений, работающих в K8s.
Кроме того, хотя K8s больше не включает в себя dockershi, Docker взял на себя эту часть кода и построил проект под названием cri-dockerd, который также работает, адаптировав Docker Engine к интерфейсу CRI, чтобы kubelet мог снова передать его. если этого никогда не было.
В целом, хотя Docker потерпел поражение в войне за оркестровку контейнеров и был загнан в угол K8s, он по-прежнему обладает сильной жизненной силой. Множество лояльных пользователей и большое количество образов приложений, накопленных за годы, являются его самым большим капиталом и опорой. Достаточно, чтобы поддержать его на другом пути, который не идет лицом к лицу с K8s.
Для начинающих Docker прост в использовании, имеет полную цепочку инструментов и дружественный интерфейс.На рынке трудно найти сопоставимое программное обеспечение. Следует сказать, что это «лучший выбор» для контейнерных технологий обучения начального уровня и облачных технологий.
ссылка
[Почему K8s отказывается от Docker? 】https://mp.weixin.qq.com/s/qEKyEseD370xWI-2yIyUzg
【Обида между Docker и k8s】https://www.cnblogs.com/powertoolsteam/p/14980851.html
【Почему k8s отказывается от Docker】 https://boilingfrog.github.io/2023/01/07/почему k8s отказывается от докера/
Это конец сегодняшнего обмена
