Ответ 1

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

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

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

Минусы этой модели:

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

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

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

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

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

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

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

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

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

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

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

Контейнеры

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

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

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

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

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

Есть и минусы:

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

Контейнерная оркестровка

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

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

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

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

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

Ответ 2

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

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

• rkt: Аналогично движку докеров, но другая реализация

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

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

• ECS: аналогично GKE (4), но без Кубернетов.

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

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

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