Docker kubernetes что это
Прошлое, настоящее и будущее Docker и других исполняемых сред контейнеров в Kubernetes
Прим. перев.: Мы написали уже не одну публикацию (см. ссылки в конце статьи) об исполняемых средах контейнеров (container runtimes) — речь в них, как правило, идёт в контексте Kubernetes. Однако зачастую эти материалы вызывали у читателей вопросы, свидетельствующие о недостаточном понимании, откуда взялся очередной проект, как он связан с другими и что вообще происходит во всём этом контейнерном «зоопарке».
Основные выводы
Однако, даже несмотря на попытки LXC спрятать сложность объединения различных технологических «внутренностей» того, что мы сегодня обычно называем контейнером, контейнеры оставались некой магией и укрепились лишь в мире особо сведущих, так и не получив широкого распространения в массах.
Всё изменилось в 2014 году с Docker, когда появилась новая, дружелюбная к разработчикам, обёртка той же самой технологии ядра Linux, что была на вооружении у LXC — ведь на самом деле ранние версии Docker «за кулисами» использовали LXC, — и контейнеры стали по-настоящему массовым явлением, поскольку разработчики прониклись простотой и возможностями повторного использования образов Docker-контейнеров и простыми командами для работы с ними.
Конечно, Docker не был единственным, кто хотел заполучить долю на рынке контейнеров, когда сопровождающая их шумиха и не думала затихать после первого взрывного интереса в 2014 году. За прошедшие годы появились разнообразные альтернативные идеи для исполняемых сред контейнеров от CoreOS (rkt), Intel Clear Containers, hyper.sh (легковесная виртуализация на базе контейнеров), а также Singularity и shifter в мире научных исследований в области высокопроизводительных вычислений (HPC).
Рынок продолжал расти и взрослеть, и с Open Container Initiative (OCI) пришли попытки стандартизации изначальных идей, продвигаемых Docker. На сегодняшний день многие исполняемые среды контейнеров или уже совместимы с OCI, или на пути к этому, предлагая производителям равные условия по продвижению их фич и возможностей, ориентированных на особое применение.
Популярность Kubernetes
Следующим этапом эволюции контейнеров было объединение с контейнерами распределённых вычислений а-ля микросервисы — и всё это в новом мире быстрой разработки и итераций деплоя (можем сказать, что DevOps), который активно набирал обороты вместе с популярностью Docker.
Хотя до получения Kubernetes’ом доминирующей позиции существовал и Apache Mesos, и другие платформы для оркестровки программного обеспечения, стремительный взлёт провёл K8s от небольшого Open Source-проекта из Google до главного проекта организации Cloud Native Computing Foundation (CNCF).
Прим. перев.: Знаете ли вы, что CNCF появилась в 2015 году по случаю релиза Kubernetes 1.0? В этот же момент проект был передан компанией Google в новую независимую организацию, ставшую частью The Linux Foundation.
Мероприятие по случаю выпуска K8s 1.0, которое, в числе прочих, спонсировали Mesosphere, CoreOS, Mirantis, OpenStack, Bitnami
Из новости про релиз Kubernetes 1.0 на ZDNet
Даже после того, как Docker выпустил конкурирующую платформу для оркестровки — Swarm, — встроенную в Docker и обладающую простотой в стиле Docker и фокусом на безопасной по умолчанию конфигурации кластера, этого уже не было достаточно для того, чтобы остановить растущий интерес к Kubernetes.
Однако многие заинтересованные стороны вне набравших быструю популярность облачных (cloud native) сообществ были сбиты с толку. Рядовой наблюдатель не мог разобраться, что же происходит: борьба Kubernetes с Docker или их сотрудничество? Поскольку Kubernetes был лишь платформой для оркестровки, требовалась исполняемая среда контейнеров, которая бы выполняла непосредственный запуск контейнеров, оркестрируемых в Kubernetes. С самого начала Kubernetes использовал движок Docker и, даже несмотря на конкурентную напряженность между Swarm и Kubernetes, Docker всё ещё оставался runtime’ом по умолчанию и требовался для функционирования кластера Kubernetes.
С небольшим числом исполняемых сред контейнеров, отличных от Docker, казалось ясным, что сопряжение runtime’а с Kubernetes потребует специально написанного интерфейса — shim — для каждой из исполняемых сред. Отсутствие понятного интерфейса для реализации исполняемых сред контейнеров очень усложняло добавление поддержки новых runtime’ов в Kubernetes.
Container Runtime Interface (CRI)
Чтобы решить проблему растущей сложности внедрения runtime’ов в Kubernetes, сообщество определило интерфейс — конкретные функции, которые исполняемая среда контейнеров должна реализовывать в рамках Kubernetes, — назвав его Container Runtime Interface (CRI) (он появился в Kubernetes 1.5 — прим. перев.). Это событие не только помогло проблеме разрастающегося числа фрагментов кодовой базы Kubernetes, затрагивающих применение исполняемых сред контейнеров, но и способствовало пониманию, какие именно функции должны поддерживаться потенциальными runtime’ами, если они хотят соответствовать CRI.
Как легко догадаться, CRI ожидает от исполняемой среды весьма простых вещей. Такая среда должна быть способна запускать и останавливать поды, обрабатывать все операции с контейнерами в контексте подов (запуск, остановка, пауза, kill, удаление), а также поддерживать управление образами контейнеров с помощью реестра. Предусмотрены также вспомогательные функции для сбора логов, метрик и т.п.
Когда новые фичи появляются в Kubernetes, если они зависят от прослойки исполняемой среды контейнеров, то такие изменения вносятся в версионный CRI API. Это в свою очередь создаёт новую функциональную зависимость от Kubernetes и требует выпуска очередных версий runtime’ов, поддерживающих новые возможности (один из недавних примеров — user namespaces).
Нынешний ландшафт CRI
По состоянию на 2018 год существует несколько опций для использования в качестве исполняемых сред контейнеров в Kubernetes. Как показано на иллюстрации ниже, одним из реальных вариантов по-прежнему остаётся Docker с его dockershim, реализующим CRI API. И на самом деле в большинстве сегодняшних инсталляций Kubernetes именно он, Docker, остаётся исполняемой средой по умолчанию.
Одним из интересных следствий напряжённости между стратегией Docker по оркестровке со Swarm и сообществом Kubernetes стал совместный проект, взявший из Docker основу runtime’а и собравший из неё новый, разрабатываемый совместно, Open Source-проект — containerd. Со временем containerd был передан в CNCF — ту же самую организацию, что управляет и владеет проектом Kubernetes. (Прим. перев.: Более подробно появление containerd мы описывали в отдельной статье.)
Из анонса containerd в блоге Docker
Containerd, будучи простой, базовой и независимой от взглядов конкретной компании (un-opinionated) реализацией runtime’а и для Docker, и для Kubernetes (через CRI), стал набирать популярность как потенциальная замена для Docker во множестве инсталляций Kubernetes. На сегодняшний день у IBM Cloud и Google Cloud кластеры на базе containerd находятся в раннем доступе/бета-режиме. В Microsoft Azure тоже пообещали перейти на containerd в будущем, а Amazon всё ещё рассматривает различные варианты runtime’ов для своих контейнерных решений (ECS и EKS), пока что продолжая использовать Docker.
Red Hat пришла в пространство исполняемых сред контейнеров, создав простую реализацию CRI, названную cri-o, на базе эталонной реализации OCI — runc. Docker и containerd тоже основаны на runc, однако создатели cri-o утверждают, что их runtime’а «просто достаточно» для Kubernetes и большего не требуется — они лишь добавили самые необходимые для реализации Kubernetes CRI функции поверх базового бинарника runc. (Прим. перев.: Подробнее о проекте CRI-O мы писали в этой статье, а про его дальнейшее развитие в виде podman — здесь.)
Проекты легковесной виртуализации: Intel Clear Containers и hyper.sh — появились в дебрях OpenStack Foundation, контейнерах Kata, и предлагают своё видение виртуализированных контейнеров для дополнительной изоляции, используя реализацию CRI под названием frakti. И cri-o, и containerd тоже работают с контейнерами Kata, так что их совместимый с OCI runtime может быть выбран в качестве подключаемой опции.
Предсказывая будущее
Говорить, что знаешь будущее, обычно не очень-то и мудро, но мы можем хотя бы зафиксировать некоторые появляющиеся тренды по мере того, как экосистема контейнеров движется от повального восторга и хайпа к более зрелому этапу своего существования.
Были ранние опасения насчёт того, что экосистема контейнеров сформирует раздробленную среду, разные участники которой придут к отличающимся и несовместимым идеям о том, что же такое контейнер. Благодаря работе OCI и ответственным действиям главных вендоров и участников, мы увидели здоровую обстановку в индустрии среди предложений в области программного обеспечения, отдающих предпочтение совместимости с OCI.
Даже в более новых окружениях, где стандарт использования Docker встретил меньше сопротивления из-за существующих ограничений — например, в HPC, — все попытки создать исполняемые среды контейнеров не на базе Docker тоже обратили внимание на OCI. Ведутся дискуссии и о том, может ли OCI быть жизнеспособным решением для специфичных нужд сообществ учёных и исследователей.
Добавив к этому стандартизацию подключаемых исполняемых сред контейнеров в Kubernetes с помощью CRI, мы можем представить мир, в котором разработчики и администраторы могут выбирать подходящие для своих задач инструменты и стеки ПО, ожидая и наблюдая интероперабельность во всей экосистеме контейнеров.
Рассмотрим конкретный пример, чтобы лучше понять этот мир:
Эта возможная гибкость и право выбора делает экосистему контейнеров по-настоящему замечательной, а также является очень важным условием для зрелости индустрии, которая так стремительно выросла с 2014 года. На пороге 2019 года и следующих лет я вижу светлое будущее с продолжающимися инновациями и гибкостью для тех, кто использует и создаёт платформы на базе контейнеров.
Дополнительную информацию по этой теме можно найти в недавнем выступлении Phil Estes на QCon NY: «CRI Runtimes Deep Dive: Who’s Running My Kubernetes Pod!?»
Основы Kubernetes
В этой публикации я хотел рассказать об интересной, но незаслуженно мало описанной на Хабре, системе управления контейнерами Kubernetes.
Что такое Kubernetes?
Kubernetes является проектом с открытым исходным кодом, предназначенным для управления кластером контейнеров Linux как единой системой. Kubernetes управляет и запускает контейнеры Docker на большом количестве хостов, а так же обеспечивает совместное размещение и репликацию большого количества контейнеров. Проект был начат Google и теперь поддерживается многими компаниями, среди которых Microsoft, RedHat, IBM и Docker.
Компания Google пользуется контейнерной технологией уже более десяти лет. Она начинала с запуска более 2 млрд контейнеров в течение одной недели. С помощью проекта Kubernetes компания делится своим опытом создания открытой платформы, предназначенной для масштабируемого запуска контейнеров.
Проект преследует две цели. Если вы пользуетесь контейнерами Docker, возникает следующий вопрос о том, как масштабировать и запускать контейнеры сразу на большом количестве хостов Docker, а также как выполнять их балансировку. В проекте предлагается высокоуровневый API, определяющее логическое группирование контейнеров, позволяющее определять пулы контейнеров, балансировать нагрузку, а также задавать их размещение.
Концепции Kubernetes
Nodes (node.md): Нода это машина в кластере Kubernetes.
Pods (pods.md): Pod это группа контейнеров с общими разделами, запускаемых как единое целое.
Replication Controllers (replication-controller.md): replication controller гарантирует, что определенное количество «реплик» pod’ы будут запущены в любой момент времени.
Services (services.md): Сервис в Kubernetes это абстракция которая определяет логический объединённый набор pod и политику доступа к ним.
Volumes (volumes.md): Volume(раздел) это директория, возможно, с данными в ней, которая доступна в контейнере.
Labels (labels.md): Label’ы это пары ключ/значение которые прикрепляются к объектам, например pod’ам. Label’ы могут быть использованы для создания и выбора наборов объектов.
Kubectl Command Line Interface (kubectl.md): kubectl интерфейс командной строки для управления Kubernetes.
Архитектура Kubernetes
Работающий кластер Kubernetes включает в себя агента, запущенного на нодах (kubelet) и компоненты мастера (APIs, scheduler, etc), поверх решения с распределённым хранилищем. Приведённая схема показывает желаемое, в конечном итоге, состояние, хотя все ещё ведётся работа над некоторыми вещами, например: как сделать так, чтобы kubelet (все компоненты, на самом деле) самостоятельно запускался в контейнере, что сделает планировщик на 100% подключаемым.
Нода Kubernetes
При взгляде на архитектуру системы мы можем разбить его на сервисы, которые работают на каждой ноде и сервисы уровня управления кластера. На каждой ноде Kubernetes запускаются сервисы, необходимые для управления нодой со стороны мастера и для запуска приложений. Конечно, на каждой ноде запускается Docker. Docker обеспечивает загрузку образов и запуск контейнеров.
Kubelet
Kubelet управляет pod’ами их контейнерами, образами, разделами, etc.
Kube-Proxy
Также на каждой ноде запускается простой proxy-балансировщик. Этот сервис запускается на каждой ноде и настраивается в Kubernetes API. Kube-Proxy может выполнять простейшее перенаправление потоков TCP и UDP (round robin) между набором бэкендов.
Компоненты управления Kubernetes
Система управления Kubernetes разделена на несколько компонентов. В данный момент все они запускаются на мастер-ноде, но в скором времени это будет изменено для возможности создания отказоустойчивого кластера. Эти компоненты работают вместе, чтобы обеспечить единое представление кластера.
Состояние мастера хранится в экземпляре etcd. Это обеспечивает надёжное хранение конфигурационных данных и своевременное оповещение прочих компонентов об изменении состояния.
Kubernetes API Server
Kubernetes API обеспечивает работу api-сервера. Он предназначен для того, чтобы быть CRUD сервером со встроенной бизнес-логикой, реализованной в отдельных компонентах или в плагинах. Он, в основном, обрабатывает REST операции, проверяя их и обновляя соответствующие объекты в etcd (и событийно в других хранилищах).
Scheduler
Scheduler привязывает незапущенные pod’ы к нодам через вызов /binding API. Scheduler подключаем; планируется поддержка множественных scheduler’ов и пользовательских scheduler’ов.
Kubernetes Controller Manager Server
Все остальные функции уровня кластера представлены в Controller Manager. Например, ноды обнаруживаются, управляются и контролируются средствами node controller. Эта сущность в итоге может быть разделена на отдельные компоненты, чтобы сделать их независимо подключаемыми.
ReplicationController — это механизм, основывающийся на pod API. В конечном счете планируется перевести её на общий механизм plug-in, когда он будет реализован.
Пример настройки кластера
В качестве платформы для примера настройки была выбрана Ubuntu-server 14.10 как наиболее простая для примера и, в то же время, позволяющая продемонстрировать основные параметры настройки кластера.
Для создания тестового кластера будут использованы три машины для создания нод и отдельная машина для проведения удалённой установки. Можно не выделять отдельную машину и производить установку с одной из нод.
Подготовка нод
Требования для запуска:
Установка ПО на ноды
Установку Docker можно произвести по статье в официальных источниках:
Дополнительная настройка Docker после установки не нужна, т.к. будет произведена скриптом установки Kubernetes.
Установка bridge-utils:
Добавление ssh-ключей
Выполняем на машине, с которой будет запущен скрипт установки.
Если ключи ещё не созданы, создаём их:
Копируем ключи на удалённые машины, предварительно убедившись в наличии на них необходимого пользователя, в нашем случае core.
Установка Kubernetes
Далее мы займёмся установкой непосредственно Kubernetes. Для этого в первую очередь скачаем и распакуем последний доступный релиз с GitHub:
Настройка
Для того, чтобы использовать последний, на момент написания статьи, релиз 0.17.0 необходимо заменить:
На этом настройка заканчивается и можно переходить к установке.
Установка
Первым делом необходимо сообщить системе про наш ssh-agent и используемый ssh-ключ для этого выполняем:
В процессе установки скрипт потребует пароль sudo для каждой ноды. По окончанию установки проверит состояние кластера и выведет список нод и адреса Kubernetes api.
Посмотрим, какие ноды и сервисы присутствуют в новом кластере:
Видим список из установленных нод в состоянии Ready и два предустановленных сервиса kubernetes и kubernetes-ro — это прокси для непосредственного доступа к Kubernetes API. Как и к любому сервису Kubernetes к kubernetes и kubernetes-ro можно обратиться непосредственно по IP адресу с любой из нод.
Запуск тестового сервиса
Для запуска сервиса необходимо подготовить docker контейнер, на основе которого будет создан сервис. Дабы не усложнять, в примере будет использован общедоступный контейнер nginx. Обязательными составляющими сервиса являются Replication Controller, обеспечивающий запущенность необходимого набора контейнеров (точнее pod) и service, который определяет, на каких IP адресе и портах будет слушать сервис и правила распределения запросов между pod’ами.
Любой сервис можно запустить 2-я способами: вручную и с помощью конфиг-файла. Рассмотрим оба.
Запуск сервиса вручную
Начнём с создания Replication Controller’а:
Далее создаём service который будет использовать наш Replication Controller как бекенд.
Для http:
Для проверки запущенности можно зайти на любую из нод и выполнить в консоли:
В выводе curl увидим стандартную приветственную страницу nginx. Готово, сервис запущен и доступен.
Запуск сервиса с помощью конфигов
Для этого способа запуска необходимо создать конфиги для Replication Controller’а и service’а. Kubernetes принимает конфиги в форматах yaml и json. Мне ближе yaml поэтому будем использовать его.
Предварительно очистим наш кластер от предыдущего эксперимента:
Был создан Replication Controller с именем nginx и количеством реплик равным 6. Реплики в произвольном порядке запущены на нодах, местоположения каждой pod’ы указано в столбце HOST.
Можно заметить, что при использовании конфига за одним сервисом могут быть закреплены несколько портов.
Применяем конфиг:
Для проверки запущенности можно зайти на любую из нод и выполнить в консоли:
В выводе curl увидим стандартную приветственную страницу nginx.
Заметки на полях
В качестве заключения хочу описать пару важных моментов, о которые уже пришлось запнуться при проектировании системы. Связаны они были с работой kube-proxy, того самого модуля, который позволяет превратить разрозненный набор элементов в сервис.
PORTAL_NET. Сущность сама по себе интересная, предлагаю ознакомиться с тем, как же это реализовано.
Недолгие раскопки привели меня к осознанию простой, но эффективной модели, заглянем в вывод iptables-save:
На этом всё, спасибо за внимание
К сожалению, всю информацию, которую хочется передать, не получается уместить в одну статью.
В чем разница между Docker и Kubernetes?
В этой статье мы сравним Docker и Kubernetes, чтобы увидеть, где эти две технологии противостоят друг другу.
Мы также поговорим о некоторых альтернативах инструментам оркестровки, кроме Kubernetes. Далее мы подробно рассмотрим сравнение Docker Swarm и Kubernetes.
Что такое Docker?
Это способ, который позволяет пользователям полностью управлять своим приложением во время разработки и во время запуска, а также смягчает проблемы, возникающие на этих этапах. Он также помогает получить точное представление о том, как приложение должно быть подключено к сети, управляет использованием хранилища и памяти, а также обрабатывает права доступа вне приложения.
Подводя итог, это способ обеспечить согласованную среду на любом OS-совместимом хосте (Linux или Windows).
Особенности Docker
Многие приложения работают на Docker.
Что такое Kubernetes (или K8s)?
Это портативная платформа с открытым исходным кодом, разработанная Google и управляемая облачным вычислительным фондом. Он помогает обновлять приложения более простым и быстрым способом без каких-либо простоев, а также управляет работой планирования контейнеров в кластере и рабочей нагрузкой.
Эта платформа оркестровки автоматизирует многие ручные процессы, такие как развертывание, управление и масштабирование приложений в контейнере.
Особенности Kubernetes
Docker VS Kubernetes
Давайте разберемся в этом подробно с изображением ниже.
Оно показывает, что Docker и Kubernetes идут рука об руку и работают параллельно.
Давайте рассмотрим некоторые сходства между Docker и Kubernetes.
Предпочтение Docker и Kubernetes
Если мы посмотрим на любое приложение с теоретической точки зрения, оно будет выглядеть гладким и без каких-либо проблем. Реальные проблемы можно увидеть только после практической реализации. Точки, которые необходимо учитывать для успешного результата любого приложения, являются:
Затем из Docker или Kubernetes мы должны выбрать один или другой в зависимости от варианта использования.
Когда выбрать Docker?
Когда выбрать Kubernetes?
Что такое Docker Swarm?
Это внутренний инструмент оркестровки контейнеров, разработанный Docker для взаимодействия с контейнерами, работающими в среде Docker. Он используется для кластеризации и планирования. Это позволяет управлять несколькими контейнерами, развернутыми на нескольких хостах. Он использует стандартный интерфейс Docker API и работу в сети, что позволяет легко перейти в любую среду Dcoker.
Заключение
Не паникуйте: Kubernetes и Docker
Прим. перев.: свежая публикация в блоге Kubernetes — оперативный ответ на ту шумиху, что поднялась вокруг грядущего релиза K8s, в котором поддержка Docker будет объявлена устаревшей. Представляем вашему вниманию её перевод.
Начиная с версии v1.20, Kubernetes отказывается от Docker как от исполняемой среды контейнеров.
Но не паникуйте. Не все так страшно, как представляется на первый взгляд.
TL;DR. Kubernetes отказывается от Docker в пользу сред выполнения на базе Container Runtime Interface (CRI), разработанного специально для Kubernetes. Образы для Docker продолжат работать во всех средах выполнения как обычно.
Если вы пользуетесь услугами 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%. Пожалуйста, задавайте любые вопросы, независимо от уровня опыта или сложности! Наша цель — максимально подготовить всех к предстоящим переменам.