По данным совместного исследования TAdviser и разработчиков платформы «Штурвал», 60% крупных российских компаний уже используют Kubernetes, ещё 15% опрошенных планируют его внедрять. Технология, которая ещё недавно была инструментом крупных банков и маркетплейсов, уже становится стандартом для больших предприятий из других отраслей и среднего бизнеса. Перед многими ИТ-руководителями встает вопрос: нужен ли компании Kubernetes или пока достаточно Docker? А если Kubernetes всё-таки необходим, то как его использовать — вместо Docker или вместе с ним?
Владимир Утратенко, BDM платформы «Штурвал», расскажет, в чём разница между Docker и Kubernetes и как понять, какой инструмент подходит вашей компании.
Владимир Утратенко, BDM платформы «Штурвал», расскажет, в чём разница между Docker и Kubernetes и как понять, какой инструмент подходит вашей компании.
Docker и Kubernetes: что это такое и зачем нужны
Главное, что стоит понимать: Docker и Kubernetes не конкурируют между собой. Это инструменты разного уровня, предназначенные для разных задач.
- Docker отвечает за упаковку и запуск приложения в стандартизованном виде.
- Kubernetes следит, чтобы сотни таких приложений работали на десятках серверов и не падали, автоматически масштабировались и переживали сбои.
Что такое Docker простыми словами
Docker — это платформа для работы с контейнерами. Контейнер представляет собой приложение, упакованное со всем своим окружением: библиотеками, настройками, зависимостями. Такая «коробка» одинаково запускается на ноутбуке разработчика, тестовом сервере и в продакшене. Docker представляет собой не один инструмент, а целую экосистему, в которую входят несколько ключевых компонентов:
Контейнеры создаются из образов — шаблонов, которые хранятся в реестрах, например, в Docker Hub. По сути, это «магазин приложений» для контейнеров с готовыми образами для тысяч программ и сервисов.
- Docker Engine — движок, который запускает контейнеры;
- Docker CLI — команды для работы из терминала;
- Docker Compose — утилита для запуска нескольких контейнеров одной командой по YAML-файлу;
- Docker Desktop — графическое приложение для ПК, в котором можно запустить локальный Kubernetes (docker desktop kubernetes);
- Docker Swarm — встроенный оркестратор контейнеров.
Контейнеры создаются из образов — шаблонов, которые хранятся в реестрах, например, в Docker Hub. По сути, это «магазин приложений» для контейнеров с готовыми образами для тысяч программ и сервисов.
Что такое Kubernetes (K8s) простыми словами
Kubernetes (K8s) — это платформа с открытым исходным кодом для оркестрации контейнеров. В 2014 году его создала компания Google, и с тех пор он успел пройти путь от инструмента для гиков до стандарта индустрии.
Если Docker отвечает за запуск контейнера на одном сервере, то Kubernetes управляет контейнерами, которые работают на десятках серверов одновременно. Он объединяет группу серверов в кластер и берёт на себя всю рутину:
Именно в автоматизации и заключается ценность Kubernetes. Docker подходит для одиночных приложений. Внедрение Kubernetes необходимо, когда появляется потребность в масштабировании, балансировке нагрузки, обеспечении отказоустойчивости.
Если Docker отвечает за запуск контейнера на одном сервере, то Kubernetes управляет контейнерами, которые работают на десятках серверов одновременно. Он объединяет группу серверов в кластер и берёт на себя всю рутину:
- решает, на какой машине запустить контейнер;
- следит за тем, чтобы они не падали;
- автоматически создаёт новые копии при росте нагрузки;
- распределяет работу между серверами.
Именно в автоматизации и заключается ценность Kubernetes. Docker подходит для одиночных приложений. Внедрение Kubernetes необходимо, когда появляется потребность в масштабировании, балансировке нагрузки, обеспечении отказоустойчивости.
Отличия Docker и Kubernetes
Обычно эти инструменты работают в связке в крупных проектах. Docker упаковывает и запускает контейнеры, а Kubernetes ими управляет. В этом и заключается их разница на уровне задач.
Чем Kubernetes отличается от Docker с точки зрения роли в проекте? Предлагаем провести аналогию. Один корабельный контейнер можно увезти на одной фуре, а вот три контейнера уже потребуют трех фур. Но когда контейнеров становится пять десятков, удобнее нанять контейнеровоз. С нашими инструментами всё устроено похожим образом. Docker работает как «фура», которая прекрасно справляется с небольшим количеством контейнеров. А Kubernetes выступает в роли «логистического центра», управляющего парком контейнеровозов, когда грузов становится действительно много.
Чем Kubernetes отличается от Docker с точки зрения роли в проекте? Предлагаем провести аналогию. Один корабельный контейнер можно увезти на одной фуре, а вот три контейнера уже потребуют трех фур. Но когда контейнеров становится пять десятков, удобнее нанять контейнеровоз. С нашими инструментами всё устроено похожим образом. Docker работает как «фура», которая прекрасно справляется с небольшим количеством контейнеров. А Kubernetes выступает в роли «логистического центра», управляющего парком контейнеровозов, когда грузов становится действительно много.
Пока у вас один-два сервиса, логично использовать Docker и обходиться без оркестратора. Когда же сервисов становится много и они требуют масштабирования и высокой доступности, без Kubernetes уже не обойтись. При этом Docker никуда не исчезает: он по-прежнему отвечает за работу с контейнерами, а Kubernetes надстраивается сверху как управляющий слой.
А если нагляднее
Чтобы отличия Docker и Kubernetes было проще удержать в голове, мы собрали ключевые параметры в таблицу.
Docker Compose и Kubernetes: в чём разница
Этот вопрос звучит часто, потому что оба инструмента умеют запускать несколько контейнеров. Docker Compose — это утилита внутри экосистемы Docker, которая позволяет описать несколько контейнеров в одном YAML-файле и запустить их одной командой. Это удобно для локальной разработки: можно поднять бэкенд, базу данных, кэш и фронтенд командой docker compose up, и всё начинает работать.
Kubernetes решает похожую задачу, но на принципиально другом уровне. Compose работает на одном сервере и не занимается масштабированием, балансировкой нагрузки и самовосстановлением. Kubernetes же работает на кластере серверов и делает всё это автоматически.
Когда сравнивают docker vs kubernetes, чаще всего имеют в виду именно пару Compose и Kubernetes, потому что голый Docker без Compose в продакшене почти никто не использует. Выбор kubernetes vs docker compose — это, по сути, выбор между инструментом для разработки и небольших установок и промышленной платформой оркестрации. Отсюда и популярный вопрос «docker compose или kubernetes», ответ на который зависит от масштаба проекта.
По словам Владимира Утратенко, Compose остаётся осознанным выбором, если нужно запустить три-четыре сервиса, на которые приходится нагрузка раз в месяц. Для стартапа, где систем мало и их надо развивать по функциональности и стабильности, проще использовать Docker.
Compose также остается стандартом для локальной разработки даже в крупных компаниях. Разработчик поднимает у себя окружение в Compose, а в продакшене оно работает уже в Kubernetes с нужной конфигурацией.
Kubernetes решает похожую задачу, но на принципиально другом уровне. Compose работает на одном сервере и не занимается масштабированием, балансировкой нагрузки и самовосстановлением. Kubernetes же работает на кластере серверов и делает всё это автоматически.
Когда сравнивают docker vs kubernetes, чаще всего имеют в виду именно пару Compose и Kubernetes, потому что голый Docker без Compose в продакшене почти никто не использует. Выбор kubernetes vs docker compose — это, по сути, выбор между инструментом для разработки и небольших установок и промышленной платформой оркестрации. Отсюда и популярный вопрос «docker compose или kubernetes», ответ на который зависит от масштаба проекта.
По словам Владимира Утратенко, Compose остаётся осознанным выбором, если нужно запустить три-четыре сервиса, на которые приходится нагрузка раз в месяц. Для стартапа, где систем мало и их надо развивать по функциональности и стабильности, проще использовать Docker.
Compose также остается стандартом для локальной разработки даже в крупных компаниях. Разработчик поднимает у себя окружение в Compose, а в продакшене оно работает уже в Kubernetes с нужной конфигурацией.
Docker Swarm или Kubernetes: что выбрать для оркестрации
Docker Swarm — это встроенный в Docker оркестратор контейнеров. Он появился раньше Kubernetes и долгое время рассматривался как более простая альтернатива. Сегодня выбор docker swarm или kubernetes для нового проекта выглядит уже не так однозначно.
Если вы уже живете на Swarm и у вас всё стабильно работает, нет срочной причины переезжать. Если же вы выбираете оркестратор для нового проекта, разумнее брать Kubernetes: под него больше специалистов, есть различные инструменты, документация, интеграции с облаками и вендорскими платформами.
Если вы уже живете на Swarm и у вас всё стабильно работает, нет срочной причины переезжать. Если же вы выбираете оркестратор для нового проекта, разумнее брать Kubernetes: под него больше специалистов, есть различные инструменты, документация, интеграции с облаками и вендорскими платформами.
Совместимы ли Docker и Kubernetes
Образы, собранные через Docker, прекрасно запускаются в Kubernetes. На практике разработчики продолжают пользоваться Docker и Docker Compose локально, а в продакшене те же самые образы разворачиваются уже в Kubernetes.
При этом в 2020 году Kubernetes объявил о постепенном отказе от Docker Engine как среды выполнения контейнеров внутри кластера, а в 2022-м поддержку окончательно удалили. На смену пришел containerd — низкоуровневая среда, которая, кстати, и раньше использовалась внутри самого Docker. В сообществе это иногда подают как «Kubernetes развелся с Docker», но на практике почти ничего не меняется. Образы, собранные через Docker, продолжают работать в Kubernetes так же, как и раньше, потому что они соответствуют единому стандарту OCI. Для разработчиков и ИТ-руководителей этот переход вообще не заметен.
При этом в 2020 году Kubernetes объявил о постепенном отказе от Docker Engine как среды выполнения контейнеров внутри кластера, а в 2022-м поддержку окончательно удалили. На смену пришел containerd — низкоуровневая среда, которая, кстати, и раньше использовалась внутри самого Docker. В сообществе это иногда подают как «Kubernetes развелся с Docker», но на практике почти ничего не меняется. Образы, собранные через Docker, продолжают работать в Kubernetes так же, как и раньше, потому что они соответствуют единому стандарту OCI. Для разработчиков и ИТ-руководителей этот переход вообще не заметен.
Что выбрать: Docker или Kubernetes
Выбор между Docker и Kubernetes определяется масштабом проекта, а не отраслью, и возросшей потребностью в управлении подобной инфраструктурой.
Когда достаточно Docker и Docker Compose
Есть несколько типовых сценариев, в которых Kubernetes избыточен, а Docker и Docker Compose справляются с задачей лучше и дешевле.
Стартап на ранней стадии. Систем пока мало, и главная задача — развитие функциональности и стабилизация продукта, а не масштабирование нагрузки. Kubernetes потребует нескольких виртуальных машин и кратно увеличит затраты на эксплуатацию, на таком масштабе это бессмысленно.
Проект с небольшим количеством сервисов и нерегулярной нагрузкой. Три-четыре сервиса с эпизодической нагрузкой в оркестраторе не нуждаются.
Маркетплейс или веб-сервис на старте. Маркетплейс в самом зачатке почти наверняка живет на голом Docker и двух-трёх виртуальных машинах. Миграция в Kubernetes оправдана тогда, когда приходит реальное масштабирование.
Локальная разработка и тестовые окружения. Даже в компаниях, где в продуктиве развернут Kubernetes, разработчики локально поднимают сервисы через Docker Compose.
Когда достаточно Docker и Docker Compose
Есть несколько типовых сценариев, в которых Kubernetes избыточен, а Docker и Docker Compose справляются с задачей лучше и дешевле.
Стартап на ранней стадии. Систем пока мало, и главная задача — развитие функциональности и стабилизация продукта, а не масштабирование нагрузки. Kubernetes потребует нескольких виртуальных машин и кратно увеличит затраты на эксплуатацию, на таком масштабе это бессмысленно.
Проект с небольшим количеством сервисов и нерегулярной нагрузкой. Три-четыре сервиса с эпизодической нагрузкой в оркестраторе не нуждаются.
Маркетплейс или веб-сервис на старте. Маркетплейс в самом зачатке почти наверняка живет на голом Docker и двух-трёх виртуальных машинах. Миграция в Kubernetes оправдана тогда, когда приходит реальное масштабирование.
Локальная разработка и тестовые окружения. Даже в компаниях, где в продуктиве развернут Kubernetes, разработчики локально поднимают сервисы через Docker Compose.
Когда нужен Kubernetes
Есть три понятные причины, по которым компании переходят на Kubernetes.
Первая — требования поставщиков ПО. Современные корпоративные системы всё чаще поставляются в контейнерах под Kubernetes. Сначала потребность появляется под одну систему, потом под вторую, третью, и в какой-то момент кластер становится необходимостью. Для ИТ-руководителя это означает следующее: даже если команде сейчас Kubernetes не нужен, он может потребоваться из-за выбора вендорского решения.
Вторая — реальное масштабирование. Это и есть главный драйвер перехода. Когда сервис активно растёт, постоянно разворачивать новые виртуальные машины ради выкатки нового софта становится неудобно. Появляется потребность в многочисленных копиях сервисов, автоматическом управлении нагрузкой и самовосстановлении при сбоях. В этот момент приходит осознание, что нужен оркестратор, и появляется Kubernetes.
Третья — критическая масса контейнерных систем. Когда в компании накапливается много самописных и внедренных систем в контейнерах, архитекторы принимают решение оркестрировать их все вместе, чтобы не было зоопарка, а всё лежало в одной «корзинке» по своим местам.
Важный нюанс касается того, чего стоит ожидать от Kubernetes. Согласно исследованию TAdviser и команды разработчиков платформы «Штурвал», среди главных эффектов внедрения Kubernetes в крупных компаниях лидируют ускорение Time-to-Market (47% респондентов отметили это как главный эффект), снижение затрат на человеческие ресурсы за счёт автоматизации (34%), улучшение метрик отказов и восстановления (28%) и рост продуктовых показателей (26%). Сокращение TCO как основной эффект отмечают только 24% компаний. Иными словами, если рассматривать Kubernetes как способ напрямую снизить расходы, скорее всего, вас ждёт разочарование. Если же воспринимать его как инструмент ускорения разработки, разгрузки команды, повышения надёжности и производительности продуктовых сервисов, ожидания вполне оправдаются.
Первая — требования поставщиков ПО. Современные корпоративные системы всё чаще поставляются в контейнерах под Kubernetes. Сначала потребность появляется под одну систему, потом под вторую, третью, и в какой-то момент кластер становится необходимостью. Для ИТ-руководителя это означает следующее: даже если команде сейчас Kubernetes не нужен, он может потребоваться из-за выбора вендорского решения.
Вторая — реальное масштабирование. Это и есть главный драйвер перехода. Когда сервис активно растёт, постоянно разворачивать новые виртуальные машины ради выкатки нового софта становится неудобно. Появляется потребность в многочисленных копиях сервисов, автоматическом управлении нагрузкой и самовосстановлении при сбоях. В этот момент приходит осознание, что нужен оркестратор, и появляется Kubernetes.
Третья — критическая масса контейнерных систем. Когда в компании накапливается много самописных и внедренных систем в контейнерах, архитекторы принимают решение оркестрировать их все вместе, чтобы не было зоопарка, а всё лежало в одной «корзинке» по своим местам.
Важный нюанс касается того, чего стоит ожидать от Kubernetes. Согласно исследованию TAdviser и команды разработчиков платформы «Штурвал», среди главных эффектов внедрения Kubernetes в крупных компаниях лидируют ускорение Time-to-Market (47% респондентов отметили это как главный эффект), снижение затрат на человеческие ресурсы за счёт автоматизации (34%), улучшение метрик отказов и восстановления (28%) и рост продуктовых показателей (26%). Сокращение TCO как основной эффект отмечают только 24% компаний. Иными словами, если рассматривать Kubernetes как способ напрямую снизить расходы, скорее всего, вас ждёт разочарование. Если же воспринимать его как инструмент ускорения разработки, разгрузки команды, повышения надёжности и производительности продуктовых сервисов, ожидания вполне оправдаются.
Сколько стоит Kubernetes: затраты, о которых забывают
На итоговую сумму влияет всё: количество систем, сложность конфигурации, число окружений, размер команды эксплуатации, использование вендорского или open-source-решения.
Но есть статья расходов, которую ИТ-руководители часто недооценивают. Многие думают, что open-source Kubernetes является бесплатным. Однако он предполагает настройку всей необходимой обвязки и следующие за этим управление, обновление, интеграцию с системами и доработку под необходимые сценарии. Обычно дополнительно подключаются системы мониторинга, логирования, резервного копирования, CI/CD, настраиваются политики безопасности и средства безопасности, чтобы кластер был пригоден для продакшена.
В вендорском решении обычно все сервисы доступны «из коробки», именно за это заказчики и платят. В открытом фреймворке всё это придётся делать самостоятельно, и это превращается в отдельную большую статью затрат в TCO.
Данные исследования эту картину дополняют. При выборе платформы 67% руководителей ставят на первое место стоимость, 61% — затраты на обслуживание. А главным барьером внедрения остаётся не технологическая незрелость решений, а острый дефицит компетенций, поэтому 49% компаний планируют инвестировать в обучение команд.
Но есть статья расходов, которую ИТ-руководители часто недооценивают. Многие думают, что open-source Kubernetes является бесплатным. Однако он предполагает настройку всей необходимой обвязки и следующие за этим управление, обновление, интеграцию с системами и доработку под необходимые сценарии. Обычно дополнительно подключаются системы мониторинга, логирования, резервного копирования, CI/CD, настраиваются политики безопасности и средства безопасности, чтобы кластер был пригоден для продакшена.
В вендорском решении обычно все сервисы доступны «из коробки», именно за это заказчики и платят. В открытом фреймворке всё это придётся делать самостоятельно, и это превращается в отдельную большую статью затрат в TCO.
Данные исследования эту картину дополняют. При выборе платформы 67% руководителей ставят на первое место стоимость, 61% — затраты на обслуживание. А главным барьером внедрения остаётся не технологическая незрелость решений, а острый дефицит компетенций, поэтому 49% компаний планируют инвестировать в обучение команд.
Где сейчас российский рынок
Владимир Утратенко предлагает такую хронологию внедрения Kubernetes в России:
- 2014 год — создание Kubernetes как технологии.
- 2016 год — первые внедрения в продуктиве у инноваторов.
- 2017−2018 годы — появление ранних последователей.
- Сейчас — этап «раннего большинства»: крупные банки (Сбер, Т-Банк, ВТБ), маркетплейсы, ритейл, телеком. Этот эшелон либо уже прошёл путь внедрения, либо находится на завершающем этапе.
- Следующий эшелон — компании с меньшим масштабом ИТ-систем. За ранним большинством, по словам эксперта, «неизбежно тянется весь остальной рынок», потому что современное корпоративное ПО всё чаще разрабатывается с расчётом именно на Kubernetes.
Цифры отчёта TAdviser и команды «Штурвала» подтверждают эту картину. Среди крупных российских компаний с выручкой от 10 миллиардов рублей 60% уже используют Kubernetes в продуктиве, ещё 15% планируют внедрение. 73% запускают контейнерную платформу поверх существующей виртуализации, чаще всего поверх VMware (62%), но активно используются и open-source-системы виртуализации (28%), что говорит о том, что импортозамещение идёт и здесь. В сегменте операционных систем почти поровну представлены Ubuntu (36%) и Astra Linux (35%). Российские контейнерные платформы по распространению почти догоняют open-source: 33% против 54%, а зарубежные продукты используют всего 10% респондентов.
Российский рынок постепенно переходит в фазу зрелости, и на нём чётко обозначились лидеры: «Штурвал» и Deckhouse Kubernetes Platform. Выручка лидеров сегмента в 2024 году выросла почти на 300%. Кроме того, 51% компаний, уже внедривших Kubernetes, планируют расширять его использование в ближайшие два-три года, масштабируя на новые подразделения и увеличивая число контейнеризованных сервисов.
Для ИТ-руководителя среднего бизнеса это означает, что в ближайшие два года вопрос «переходить ли на Kubernetes» с большой вероятностью перейдёт из плоскости «если» в плоскость «когда и как».
Российский рынок постепенно переходит в фазу зрелости, и на нём чётко обозначились лидеры: «Штурвал» и Deckhouse Kubernetes Platform. Выручка лидеров сегмента в 2024 году выросла почти на 300%. Кроме того, 51% компаний, уже внедривших Kubernetes, планируют расширять его использование в ближайшие два-три года, масштабируя на новые подразделения и увеличивая число контейнеризованных сервисов.
Для ИТ-руководителя среднего бизнеса это означает, что в ближайшие два года вопрос «переходить ли на Kubernetes» с большой вероятностью перейдёт из плоскости «если» в плоскость «когда и как».
Российская специфика: Docker Hub и безопасность
Работать с Docker и Kubernetes в России после 2022 года значит учитывать два важных фактора.
Доступность Docker Hub. Сам реестр по-прежнему доступен из России и пользоваться им можно. Однако за последние годы случилось несколько инцидентов недоступности — по регуляторным причинам со стороны самого сервиса, а не со стороны российских ограничений. Самый заметный из них пришелся на конец мая 2024 года, когда доступ для российских IP был временно полностью закрыт, и сервис восстановился лишь через несколько дней. Российское сообщество отреагировало развертыванием зеркал Docker Hub, а многие компании, активно работающие с готовыми образами, начали заводить собственные внутренние зеркала, чтобы не зависеть от внешнего ресурса в критичный момент.
Безопасность вышла на первый план. По словам Владимира Утратенко: «До 2022 года вопрос безопасности публичных образов не стоял остро. Возможность того, что в Docker Hub окажется вредоносный код, признавали, но всерьёз эту угрозу не рассматривали. Сейчас могут быть намеренные атаки и на цепочки поставок, и на сами базовые образы контейнеров в Docker Hub, и на библиотеки внутри этих образов. Мы начинаем внимательнее относиться к тому, что получаем из публичных источников, переходим больше на сборку собственных образов внутри компании. Кто-то вообще подписывает свои образы контейнеров, чтобы точно ничего левого не попало в продуктивный контур».
Практический вывод здесь такой: если ваша инфраструктура использует образы из публичных источников, этому нужно уделять внимание как отдельной задаче — с политиками проверки, сканированием уязвимостей и, возможно, собственным внутренним реестром.
Доступность Docker Hub. Сам реестр по-прежнему доступен из России и пользоваться им можно. Однако за последние годы случилось несколько инцидентов недоступности — по регуляторным причинам со стороны самого сервиса, а не со стороны российских ограничений. Самый заметный из них пришелся на конец мая 2024 года, когда доступ для российских IP был временно полностью закрыт, и сервис восстановился лишь через несколько дней. Российское сообщество отреагировало развертыванием зеркал Docker Hub, а многие компании, активно работающие с готовыми образами, начали заводить собственные внутренние зеркала, чтобы не зависеть от внешнего ресурса в критичный момент.
Безопасность вышла на первый план. По словам Владимира Утратенко: «До 2022 года вопрос безопасности публичных образов не стоял остро. Возможность того, что в Docker Hub окажется вредоносный код, признавали, но всерьёз эту угрозу не рассматривали. Сейчас могут быть намеренные атаки и на цепочки поставок, и на сами базовые образы контейнеров в Docker Hub, и на библиотеки внутри этих образов. Мы начинаем внимательнее относиться к тому, что получаем из публичных источников, переходим больше на сборку собственных образов внутри компании. Кто-то вообще подписывает свои образы контейнеров, чтобы точно ничего левого не попало в продуктивный контур».
Практический вывод здесь такой: если ваша инфраструктура использует образы из публичных источников, этому нужно уделять внимание как отдельной задаче — с политиками проверки, сканированием уязвимостей и, возможно, собственным внутренним реестром.
Итоги
- Docker и Kubernetes не конкуренты. Docker упаковывает и запускает контейнеры, а Kubernetes управляет ими на масштабе. В крупных проектах эти инструменты работают вместе.
- Главный критерий выбора — масштаб проекта, а не отрасль.
- Docker и Docker Compose достаточны для стартапов, локальной разработки, небольших продакшенов с тремя-четырьмя сервисами. Это не «бедный родственник», а вполне осознанный выбор под определенный масштаб.
- Docker Swarm жив, но для новых проектов рациональнее выбирать Kubernetes ради экосистемы, специалистов и базы знаний.
- Kubernetes нужен по трём причинам: вендорское ПО строится на его основе, проект реально масштабируется или в компании накопилась критическая масса контейнерных систем.
- Главный эффект Kubernetes для бизнеса — ускорение Time-to-Market и автоматизация работы команды, а не экономия на инфраструктуре.
- Главные скрытые затраты — развитие open-source Kubernetes и обвязка вокруг него: мониторинг, безопасность, CI/CD, обновления.
- Российский рынок: крупный бизнес уже в Kubernetes или завершает переход. Средний бизнес — следующий эшелон.
Docker и Kubernetes не относятся к разряду модных технологий, которые берут, чтобы быть современным. Это два инструмента разного уровня, и выбор между ними всегда сводится к вопросу о конкретных задачах проекта.
