Почему экземпляры облачных вычислений запускают виртуальные машины, а не контейнеры?
Например, в AWS, когда я запускаю новый экземпляр EC2, он загружает новую виртуальную машину, а затем заполняет ее контейнером. образ. Это причина того, почему запуск новых инстансов EC2 занимает 60-90 секунд.
Из любопытства, каковы недостатки того, что AWS запускает хост-машину как есть, и когда пользователь хочет «раскрутить» Экземпляр EC2 », AWS просто запускает контейнер с ограниченными разрешениями и разрешает пользователю доступ только к этому контейнеру?
Положительным моментом будет то, что вычислительный экземпляр будет раскручиваться очень быстро. Я все еще изучаю облачные технологии, поэтому мне просто интересно, каковы их недостатки.
Возможно, сложнее выделить ресурсы ЦП без использования виртуальных машин? И в результате пользователи будут драться друг с другом за доступный процессор? Или, может быть, есть какие-то проблемы с безопасностью? Хотел бы узнать об этом.
Ваш вопрос в некоторой степени заключается в том, чтобы взглянуть назад: EC2 - это не универсальное хостинговое решение, в котором используются виртуальные машины ; это сервис для размещения виртуальных машин. Таким образом, есть несколько способов интерпретировать ваш вопрос.
Почему EC2 не был разработан для использования контейнеров?
Ответ на этот вопрос можно вывести из графика: бета-версия EC2 была запущена в 2006 году, а полная версия в 2008; Docker не был публично выпущен до 2013 года, а Kubernetes был выпущен в 2015 году.
Контейнерная технология разрабатывалась на момент запуска EC2 - в BSD уже были «тюрьмы», а в Linux были некоторые формы изоляции пространства имен - но это была не та зрелая экосистема, с которой мы знакомы сегодня. Виртуальные частные серверы, с другой стороны, были хорошо зарекомендовавшей себя концепцией - VMWare явно продавала ESX для услуг хостинга в 2002 году , гипервизор Xen последовал в 2003 году и Linode был запущен в том же году. Нововведением EC2 была система для запуска виртуальных серверов по запросу с использованием этой установленной технологии.
Почему EC2 не перешел с виртуальных машин на контейнеры?
Хотя контейнеры в некотором смысле можно рассматривать как « облегченная виртуальная машина ", это не полное описание, и они не взаимозаменяемы. Виртуальная машина создана для того, чтобы дать пользователю иллюзию, что он обращается к физическому серверу, с полным контролем над всей системой; ресурсы, такие как сеть, представлены как виртуальное оборудование, с которым пользователь может напрямую взаимодействовать, если пожелает. Контейнеры представляют собой более ограниченную абстракцию, и приложение, как правило, гораздо более тесно связано с конфигурацией самого контейнера, например, перенаправляет только определенные сетевые порты.
Amazon добавила много сервисов за эти годы, но очень консервативно относится к прекращению использования старые, на которые полагаются клиенты. Таким образом, они предлагают множество сервисов, основанных на контейнерах, а не на виртуальных машинах, таких как ECS (Elastic Container Service, запущен в 2014 г.), Fargate (запущен в 2017 г.) и EKS (Elastic Kubernetes Service, запущен в 2018 г.); но они вряд ли откажутся от EC2, если пользователи все еще его используют.
Почему пользователи не перешли на контейнерные службы?
Учитывая, что облачный хостинг на основе контейнеров доступен, почему люди все еще предпочитают использовать виртуальные машины такие сервисы, как EC2?
Думаю, есть несколько причин; несколько, которые приходят на ум:
- Знакомство: люди понимают, как настроить виртуальную машину,и может относительно быстро изучить различия между локальной виртуальной машиной и экземпляром EC2. Понимание технологии контейнеров требует дополнительного обучения.
- Стоимость миграции: существующие системы часто можно запускать без изменений на экземпляре EC2, включая целые операционные системы и графические интерфейсы. Создание контейнеров для приложений, как правило, более сложно.
- Безопасность: чем меньше используется совместно используемая система, тем ниже риск утечки данных другим клиентам. Службы размещения контейнеров часто пытаются смягчить это, организуя отдельные виртуальные машины для каждого клиента, но это имеет очевидную стоимость для некоторых показателей, которые вы упоминаете, например, скорости запуска.
Таким образом, хотя контейнеры продолжают расти в популярности, они этого не сделали. пока что полностью заменил виртуальные серверы и, вероятно, никогда не будет. Таким образом, EC2 и аналогичные услуги облачного хостинга на базе виртуальных машин никуда не денутся.
Edukiontziek normalean aplikazio bakarra exekutatzen dute eta aldaezinak dira, hau da, eta aldaketak ez dira berrabiarazten bitartean gordetzen. Edukiontziek ere ez dute beren nukleoa.
VMek, bestalde, sistema eragile osoa exekutatzen dute, nukleoa, init script-ak, sistemako demonioak, etab. Biltegiratzea normalean berrabiarazten den bitartean mantentzen da.
VMak eta Edukiontziek helburu ezberdina dute - google "VMs vs Containers" bezalako zerbait, Interneten ugari dago.
Edukiontzia AWS zerbitzu gisa exekutatu nahi baduzu, azpimarragarriak diren VMak begiratu beharrik gabe AWS Fargate - zuk nahi duzuna egiten du.
Itxaropenak lagunduko duela:)
Segurtasuna arrazoia da, zalantzarik gabe. Edukiontziek kernel bera partekatzen dute beraien eta ostalariaren artean. Beraz, ez dira% 100 isolatutzat jotzen.
Hala ere, hodei hornitzaileek edukiontziak ere ematen dituzte. AWS-k ere egiten du. Edukiontziak VMak baino merkeagoak direla suposatzen dut, baina ez dut egiaztatu.
Funtsean eskatzen duzuna gai orokorragoa da, VMs vs. containers; Plataforma edozein dela ere, alde onak eta txarrak berdinak dira.
Существует несколько различных подходов к контейнерам, и текущий принятый ответ, кажется, учитывает только контейнеры в стиле OCI (похожие на докеры). Есть много других типов контейнеров, таких как тюрьмы LXC и BSD, которые имеют разные подходы.
LXC, например, может легко содержать несколько приложений и является изменяемым по умолчанию. В нем также есть сценарии инициализации и системные демоны (systemd и т. Д.).
Возможно, труднее выделить ресурсы ЦП без использования виртуальных машин? И в результате пользователи будут сражаться друг за друга, чтобы занять доступный ЦП?
Выделение ресурсов ЦП, ОЗУ и дискового пространства можно также легко выполнить с помощью контейнеров.
Положительным моментом будет то, что вычислительный экземпляр будет
Подготовка контейнеров не является мгновенной задачей (но может быть быстрее, чем «60-90 секунд»), поскольку вам все равно нужно получить изображение, извлечь его и запустить.
Или, возможно, есть некоторые проблемы с безопасностью?
Безопасность является основным источником беспокойства для всех контейнерных решений, о которых я упоминал, поскольку все они используют одно ядро. Хотя существует множество мер безопасности, время от времени все же обнаруживаются уязвимости. Если бы у вас был общий сервер с вашими друзьями, и у вас у всех были контейнеры в них, вы, вероятно, были бы в основном в безопасности, но в масштабе крупных провайдеров, таких как Amazon (где множество компаний используют их услуги), это может быть значительным проблема безопасности.
Если вы, например, посетите веб-сайт AWS Fargate , там будет указано, что многие ресурсы для их контейнеров не используются совместно, и с этой точки зрения он намного ближе к виртуальной машине, чем к традиционному собственному -hosted container:
Отдельные задачи ECS или модули EKS выполняются в своей собственной выделенной среде выполнения ядра и не разделяют ЦП, память, хранилище или сетевые ресурсы с другими задачами и модулями. Это обеспечивает изоляцию рабочей нагрузки и повышенную безопасность для каждой задачи или модуля.
Еще одна проблема, которую я хотел бы отметить, - это совместимость. Поскольку ваш доступ к ядру (а также, возможно, ваши системные вызовы) ограничен, вы не можете выполнять определенные задачи, такие как загрузка модулей dkms или выполнение конфигураций sysctl. Не все приложения будут работать в этом режиме, но это скорее исключение, чем норма.
Существует множество допустимых вариантов использования контейнеров (как OCI-подобных, так и LXC-подобных), и это определенно не «одно решение». все. Отсутствие необходимости запускать все ядро и выполнять другие типы виртуализации (графика,аудио, сеть и т. д.) приводит к гораздо меньшим накладным расходам, но также необходимо учитывать недостатки использования контейнеров, некоторые из которых я упомянул в своем ответе.