Ответ 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.