Мало найдется сегодня несогласных с тем, что Docker в конце концов стал "мейнстримом". Ну, точнее, контейнеры Docker стали. Правда есть фронт, где война еще не окончена, хотя для многих победитель уже очевиден, и победитель этот — Kubernetes, который по статистике использования сильно опережает основных конкурентов: Docker Swarm и Mesos + Mesosphere. Я знаю людей и компании, которые не согласны с выводом большинства о том, что k8s это будущее оркестрации контейнеров. Но по некоторым причинам и аналогичные инструменты от других производителей их также часто не устраивают. Крупные компании в таком случае выбирают путь разработки своего собственного инструмента для оркестрации контейнеров. Другие останавливаются на Mesos или даже на Nomad. Но я пока не знаю никого, кто использовал бы Docker Swarm (mode). Кстати, число "8" в слове k8s означает точно "8 букв", то есть: k8s = k[8_других_букв]s = kubernetes. Мода на такие сокращения появилась в бородатых 80-х прошлого века, и лично я не приветствую такие сокращения, поэтому далее буду называть инструменты их полным именем. Ситуация с хайпом вокруг Kubernetes (а это именно хайп по моему мнению) заставляет вендоров озаботиться его поддержкой. Дошло до того, что даже Docker объявил о добавлении официальной поддержки Kubernetes в следующей версии Docker EE (Enterprise Edition), а также dev-версиях Docker CE (Community Edition) для Windows/macOS (да, о Linux версии речь не идет, пока). Поддержка Kubernetes внутри Docker не ведет к автоматическому прекращению развития Swarm, напротив, Docker продолжит активно инвестировать в Swarm, получая при этом дополнительные преимущества от поддержки двух систем сразу — так прокомментировал новость David Messina, глава отдела маркетинга в Docker. Как бы дела не обстояли на самом деле, но слова David Messina похожи на правду — архитектура Docker устроена так, что слой оркестрации находится ниже верхнего слоя абстракции. Это позволяет в теории легко менять логику оркестратора и даже заменять его полностью на другой компонент. На практике для взаимозаменяемости оркестраторов (Swarm и Kubernetes, в частности) они должны иметь схожий интерфейс, чего Docker активно добивался, начиная с версии Docker 1.12 (2016 год), когда впервые появились сервисы, а позднее, в версии 1.13, был представлен Docker Compose 3.0, формат которого во многом похож на формат описания конфигурации ресурсов Kubernetes. В итоге, мы приходим к тому, что при использовании сервисов Docker у нас будет выбор как минимум из двух оркестраторов: Swarm или Kubernetes. И да, это пока только в Docker EE. Но с другой стороны, вы действительно хотите обслуживать Kubernetes своими силами? Для сравнения, вот что мы видим на нодах Docker в режиме Swarm: Инкапсуляция во всей своей красе! Прибавив к этому абсолютно тривиальнейший способ установки и запуска Docker, мы получаем настолько удобный и простой в использовании инструмент для оркестрации контейнеров, что я в совершенном недоумении, почему им до сих пор почти никто не пользуется (ведь PHP когда-то много людей начали использовать именно по причине простоты и всеобщей доступности). Может в комментариях кто поведает о причинах этого заговора странного факта. В любом случае, с релизом поддержки Kubernetes в Docker даже у тех, кто не ищет легких путей, появится возможность поэкспериментировать с оркестрацией от Kubernetes сразу после установки Docker на свой новенький Mac/Windows. А пока, томясь в ожидании неизбежного, предлагаю сторонникам Kubernetes/Swarm/Nomad/Mesos поделиться соображениями о том, что могло склонить их на темную сторону выбрать именно этот инструмент. Python программист