Я пытаюсь получить хорошее представление о контейнерных технологиях, но несколько запутался. Похоже, что определенные технологии перекрывают разные части стека, и разные части разных технологий могут использоваться так, как команда DevOps считает нужным (например, можно использовать контейнеры Docker, но не обязательно использовать движок Docker, вместо этого можно использовать движок от облачного провайдера). Мое замешательство заключается в понимании того, что предоставляет каждый уровень «Стека контейнеров» и кто является ключевыми поставщиками каждого решения.

Вот понимание моего непрофессионала; был бы признателен за любые исправления и отзывы о пробелах в моем понимании

1. Контейнеры: автономный пакет, включающий приложение, среду выполнения, системные библиотеки и т.д.; как мини-ОС с приложением
   • Похоже, что Docker является стандартом де-факто. Есть ли другие, которые заметны и широко используются?
2. Кластеры контейнеров: группы контейнеров, совместно использующих ресурсы
3. Механизм создания контейнеров: группирует контейнеры в кластеры, управляет ресурсами
4. Оркестратор: это чем-то отличается от контейнерного движка? Как?
   • Где движок Docker, rkt, Kubernetes, Google Container Engine, AWS Container Service и т.д. Находятся между # s 2-4?

Это может быть немного длинновато и представлять собой некоторое упрощение, но должно быть достаточным, чтобы донести идею до всех.

Физические машины

Некоторое время назад лучшим способом развертывания простых приложений было просто купить новый веб-сервер, установить на него свою любимую операционную систему и запускать там свои приложения.

Минусами этой модели являются:

• Процессы могут мешать друг другу (поскольку они совместно используют ресурсы процессора и файловой системы), и один из них может повлиять на производительность другого.

• Масштабирование этой системы вверх / вниз также затруднено, поскольку на настройку новой физической машины уходит много усилий и времени.

• Могут существовать различия в технических характеристиках оборудования, версиях ОС / ядра и программных пакетов физических машин, что затрудняет управление этими экземплярами приложений независимо от аппаратного обеспечения.

Приложения, на которые напрямую влияют спецификации физической машины, могут нуждаться в специальной настройке, перекомпиляции и т.д., Что означает, что администратору кластера необходимо рассматривать их как экземпляры на уровне отдельной машины. Следовательно, этот подход не масштабируется. Эти свойства делают его нежелательным для развертывания современных производственных приложений.

Виртуальные машины

Виртуальные машины решают некоторые из проблем, описанных выше:

• Они обеспечивают изоляцию даже при запуске на одном компьютере.
• Они обеспечивают стандартную среду выполнения (гостевую ОС) независимо от базового оборудования.
• Они могут быть запущены на другой машине (реплицированы) довольно быстро при масштабировании (порядка минут).
• Приложения обычно не нуждаются в переархивировании для перехода с физического оборудования на виртуальные машины.

Но они создают некоторые собственные проблемы:

• Они потребляют большое количество ресурсов при запуске целого экземпляра операционной системы.
• Они могут запускаться / отключаться не так быстро, как мы хотим (порядка секунд).

• Даже при аппаратной виртуализации экземпляры приложений могут значительно снизить производительность по сравнению с приложением, запущенным непосредственно на хосте. (Это может быть проблемой только для определенных типов приложений)

• Упаковка и распространение образов виртуальных машин не так просты, как могло бы быть. (Это не столько недостаток подхода, сколько недостаток существующего инструментария для виртуализации.)

Контейнеры

Затем, где-то по ходу дела, в ядро Linux были добавлены группы управления. Эта функция позволяет нам изолировать процессы в группах, решать, какие другие процессы и файловую систему они могут видеть, и выполнять учет ресурсов на уровне группы.

Появились различные среды выполнения контейнеров и движки, которые делают процесс создания «контейнера», среды внутри ОС, например пространства имен, С ограниченной видимостью, ресурсами и т.д., Очень простым. Распространенными примерами таких технологий являются docker, rkt, runC, LXC и т.д.

Docker, например, включает демон, который обеспечивает взаимодействие, такое как создание «образа», объекта многократного использования, который может быть мгновенно запущен в контейнер. Это также позволяет интуитивно управлять отдельными контейнерами.

Преимущества контейнеров:

• Они легкие и выполняются с очень небольшими накладными расходами, поскольку у них нет собственного экземпляра ядра / ОС и они выполняются поверх одной хост-ОС.
• Они предлагают некоторую степень изоляции между различными контейнерами и возможность налагать ограничения на различные ресурсы, потребляемые ими (с использованием механизма cgroup).
• Инструментарий вокруг них быстро развивался, позволяя легко создавать повторно используемые модули (образы), репозитории для хранения версий образов (реестры контейнеров) и так далее, Во многом благодаря docker.
• Рекомендуется, чтобы один контейнер запускал единый процесс приложения, чтобы поддерживать и распространять его независимо. Легкий характер контейнера делает это предпочтительным и приводит к более быстрой разработке за счет разделения.

Есть и некоторые недостатки:

• Обеспечиваемый уровень изоляции на порядок ниже, чем в случае виртуальных машин.
• Их проще всего использовать, когда заново создаются 12-факторные приложения без сохранения состояния, и возникают небольшие трудности при попытке развертывания устаревших приложений, кластеризованных распределенных баз данных и так далее.
• Для эффективного и масштабируемого использования им нужны оркестровка и примитивы более высокого уровня.

Оркестровка контейнеров

При запуске приложений в рабочей среде по мере роста сложности в них, как правило, много разных компонентов, некоторые из которых масштабируются по мере необходимости или могут нуждаться в масштабировании. Сами контейнеры не решают всех наших проблем. Нам нужна система, которая решает проблемы, связанные с реальными крупномасштабными приложениями, такими как:

• Создание сетей между контейнерами
• Балансировка нагрузки
• Управление хранилищем, подключенным к этим контейнерам
• Обновление контейнеров, их масштабирование, распределение по узлам в многоузловом кластере и так далее.

Когда мы хотим управлять кластером контейнеров, мы используем механизм оркестровки контейнеров. Примерами таких технологий являются Kubernetes, Mesos, Docker Swarm и т.д. Они предоставляют множество функциональных возможностей в дополнение к перечисленным выше, и цель состоит в том, чтобы сократить усилия, затрачиваемые на разработку.

GKE (Google Container Engine) размещен в Kubernetes на облачной платформе Google. Это позволяет пользователю просто указать, что ему нужен n-узловой кластер kubernetes, и предоставляет сам кластер в качестве управляемого экземпляра. Kubernetes имеет открытый исходный код, и при желании его можно также настроить на Google Compute Engine, другом облачном провайдере или на собственных компьютерах в собственном дата-центре.

ECS — это проприетарная система управления контейнерами и оркестровки, созданная и эксплуатируемая Amazon и доступная как часть пакета AWS suite.

Чтобы конкретно ответить на ваши вопросы:

1. Docker engine: инструмент для управления жизненным циклом контейнера docker и образов docker. Создавайте, перезапускайте, удаляйте контейнеры docker. Создавайте, переименовывайте, удаляйте образы docker.

2. rkt: аналогичен движку docker, но отличается реализацией

3. Kubernetes: набор инструментов для управления жизненным циклом распределенного приложения, использующего контейнеры. Содержит инструментарий для управления контейнерами, группами контейнеров, конфигурацией контейнеров, оркестровкой контейнеров, планированием их в реальных экземплярах, инструментарий, помогающий разработчикам писать и поддерживать другие сервисы / инструменты для работы с контейнерами.

4. Google Container Engine: вместо того, чтобы получать виртуальные машины, устанавливать на них «docker-engine», устанавливать на них kubernetes и заставлять все это работать с такими вещами, как правильные разрешения для вашей инфраструктуры и т.д. Представьте, если бы все это объединилось, чтобы вы могли выбирать типы машин и размер вашего кластера, на котором все это просто работает. Такие вещи, как извлечение изображений из репозитория docker для конкретного проекта (реестр контейнеров Google) или использование постоянных томов, или предоставление балансировщиков нагрузки, просто работают, не беспокоясь об учетных записях служб и разрешениях, а также о том, что нет.

5. ECS: Аналогичен GKE (4), но без Kubernetes.

Чтобы обсудить моменты в вашем понимании: вы отчасти правы во всем (я думаю, за исключением контейнерного движка). Важно понимать, что единственное, что важно понимать, это что такое контейнер. Остальное — просто маркетинг / названия продуктов. Также важно понимать, что сегодняшнее понимание контейнеров сильно искажено тем, что представляют собой контейнеры Docker, и множеством мнений, навязываемых Docker и инструментарием вокруг Docker. Контейнеры существуют уже давно.

Итак, как только вы поймете, что такое контейнер (docker), движок контейнеров — это просто инструмент для управления ими, контейнерный кластер — это просто группа контейнеров, orchestrator — это просто инструмент для управления запуском контейнеров на основе некоторых параметров. ИМХО, вам действительно не нужно слишком беспокоиться о том, что представляет собой остальной инструментарий, как только вы поймете и построите надежную ментальную модель вокруг контейнеров. Остальное просто поместится автоматически.

Лучший способ понять все это? Создайте и разверните достаточно сложное приложение с помощью Docker (сохраняйте данные / используйте базу данных в своем приложении), и все обретет смысл.