Автор | Премия Лю

задний план

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

Говоря о контейнерных технологиях, нельзя обойти стороной облачные решения, а разговоры о облачных технологиях не могут обойти вниманием контейнерные технологии. Контейнерная технология и облачная технология представляют собой пару двойной спирали.Контейнерная технология породила облачную мысль, а облачная экология способствовала развитию контейнерной технологии.. От рождения технологии докеров (контейнеров) в 2013 году до создания в 2015 году CNCF, тяжеловесного альянса в сфере облачных технологий, это не историческое совпадение, а историческая необходимость. Как одна из ключевых облачных технологий, контейнеры были в центре внимания отрасли с момента их появления в 2013 году. Используйте расширенную диаграмму технологии облачных контейнеров, широко цитируемую в отрасли, чтобы понять историческую подоплеку рождения технологии контейнеров и облачных технологий.

Давайте сначала взглянем на историческую хронологию развития контейнерных технологий, давайте интуитивно почувствуем эту горячую землю в самом разгаре!

В 1979 году системы Unix v7 поддерживали chroot, создавая независимое представление виртуальной файловой системы для приложений. В 1999 году FreeBSD 4.0 поддерживала тюрьмы, первую коммерчески доступную технологию виртуализации ОС. В 2004 году Solaris 10 поддерживал Solaris Zone, вторую коммерчески доступную технологию виртуализации ОС. В 2005 году был выпущен OpenVZ, очень важный пионер технологии виртуализации ОС Linux. С 2004 по 2007 год Google широко использовал технологии виртуализации ОС, такие как Cgroups. В 2006 году Google открыл исходный код технологии контейнера процессов, используемой внутри компании, и впоследствии изменил свое название на cgroup. В 2008 году Cgroups вошли в основную ветку ядра Linux. В 2008 году в проекте LXC (Linux Container) был прототип контейнеров Linux. В 2011 году CloudFoundry разработала систему Warden, прототип полной системы управления контейнерами. В 2013 году Google открыл исходный код своей внутренней контейнерной системы через Let Me Contain That For You (LMCTFY). В 2013 году был официально выпущен проект Docker, и контейнерная технология Linux постепенно захлестнула мир. В 2014 году был официально выпущен проект Kubernetes, и технология контейнеров стала идти рука об руку с системой оркестровки. В 2015 году Google, Redhat, Microsoft и некоторые крупные поставщики облачных услуг основали CNCF, и была запущена облачная волна. С 2016 по 2017 год экология контейнеров стала модульной и стандартизированной. CNCF принимает проекты Containerd, rkt, OCI версии 1.0, широко поддерживается CRI/CNI. 2017 - 2018, коммерциализация контейнерных услуг. AWS ECS, Google EKS, Alibaba ACK/ASK/ECI, Huawei CCI, Oracle Container Engine для Kubernetes, VMware, Redhat и Rancher начали предоставлять коммерческие сервисные продукты на основе Kubernetes. С 2017 по 2019 год технология контейнерных двигателей быстро развивалась, и появлялись новые технологии. Сообщество Kata Containers было создано в конце 2017 года, код gVisor с открытым исходным кодом Google — в мае 2018 года, фейерверк с открытым исходным кодом AWS — в ноябре 2018 года, а Alibaba Cloud выпустила Security Sandbox 1.0. С 2020 по 202x технология контейнерного движка будет модернизирована, Kata Containers запустит архитектуру 2.0, а Alibaba Cloud выпустит контейнер-песочницу 2.0....

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

технологическое детство

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

Изоляция среды выполнения контейнеров направлена на создание недифференцированной среды выполнения для контейнеров, позволяющей запускать образы контейнеров в любое время и в любом месте. Из-за проповеди докера все привыкли думать, что изоляция среды выполнения контейнера — это виртуализация ОС, или что контейнер равен namespace + cgroup + механизм защиты безопасности. Я не согласен с этим мнением, это просто исторический период, технология реализации среды выполнения контейнеров, и есть много других возможных технических решений для реализации среды выполнения контейнеров. Итак, вернемся к происхождению требования:Для контейнеров требуется технология изоляции во время выполнения, чтобы убедиться, что рабочая среда контейнера соответствует ожиданиям.. Традиционно люди называют этот компонент, реализующий технологию изоляции контейнеров, средой выполнения контейнера.

С другого ракурса,Технология изоляции контейнеров решает проблему ресурсообеспечения. Почему технология изоляции контейнеров необходима для решения проблемы снабжения ресурсами? Победа или поражение не имеет значения! Закон Мура настолько силен, что дает нам возможность использовать все больше и больше вычислительных ресурсов. Когда 10 лет назад был создан миникомпьютер, типичной спецификацией миникомпьютера был 32-процессорный 8-ядерный ЦП, а теперь 4-процессорный ПК-сервер обладает большей вычислительной мощностью, чем сервер миникомпьютера 10 лет назад. Типичное использование миникомпьютера состоит в том, чтобы разделить всю машину на несколько разделов. Наблюдая за текущей тенденцией развития аппаратного обеспечения облачных сервисов, становится все более и более очевидным, что мы трансформируем технологию, связанную с миникомпьютерами, из военной в гражданскую. Теперь один из наших ПК-серверов имеет очень мощную вычислительную мощность, сравнимую с мощностью мини-компьютеров десятилетней давности.Так совпало, что типичное использование современных ПК-серверов аналогично использованию мини-компьютеров десять лет назад, которое урезано до 1-8vCPU. Использование виртуальной машины/контейнера.

Почему люди всегда привыкли делить большой серверный ресурс на маленькие разделы вместо того, чтобы разрабатывать программное обеспечение, способное полностью использовать вычислительную мощность большого сервера? Я лично думаю, что за этим стоят два ограничения:

Присущий параллелизм решаемой задачи ограничен. С ростом популярности многоядерных и многопроцессорных систем ИТ-индустрия с 2004 года переходит от последовательного программирования к параллельному. Вначале эффект параллелизации преобразования для конкретных отраслевых приложений был очень очевиден, но позже было обнаружено, что с ростом параллелизма стоимость преобразования становилась выше, а прибыль становилась все меньше и меньше. Ограниченная законом Амдала выгода будет постепенно уменьшаться после того, как параллелизм решения конкретной задачи превысит некоторую критическую точку. Так что слепое улучшение параллелизма системы не является экономичным подходом.
Человеческий разум ограничен. Ограниченный человеческим интеллектом, чем сложнее система и чем выше степень параллелизма, тем легче программное обеспечение выходит из строя, а стоимость обслуживания программного обеспечения увеличивается в геометрической прогрессии. Поэтому, с точки зрения разработки программного обеспечения, все также стремятся к интерфейсу, модульной и унифицированной архитектуре программного обеспечения, пытаются контролировать сложность программного обеспечения и снижают затраты на разработку.

Из опыта следует, что параллелизм от 1 до 8 ЦП является комфортной зоной разработки программного обеспечения, что также является одним из движущих факторов таких технологий, как контейнеризация и микросервисы.

Немного не по теме. . . В заключение, предложение ресурсов, основанное на изоляции, не является псевдоспросом. Требования к изоляции для программной операционной среды существовали с момента появления операционной системы. Многозадачная операционная система с разделением времени и виртуальный адрес процесса предназначены для решения проблемы совместного использования ресурсов между несколькими задачами, работающими на одном хосте, так что каждый процесс думает, что у него есть эксклюзивный хост. Конечно, одной изоляции процессов недостаточно. Глядя на современные технологии изоляции ресурсов, мы можем условно разделить технологии изоляции ресурсов на пять категорий:

Изоляция процесса. ОС использует процесс как абстракцию процесса выполнения задачи.Процесс имеет независимое адресное пространство и контекст выполнения.По сути, ОС виртуализирует ЦП и память процесса. Однако различные ресурсы, такие как файловая система, стек сетевых протоколов и коммуникационное пространство IPC, также совместно используются процессами, и взаимодействие между процессами из-за конкуренции за ресурсы очень серьезно. Этот уровень изоляции подходит для запуска разных программ одного пользователя на разных хостах, и пользователь может обеспечить распределение ресурсов и защиту безопасности с помощью средств управления системой.
виртуализация ОС. Изоляция ОС, также известная как виртуализация ОС, представляет собой сублимированную версию изоляции процессов. Изоляция процессов реализует отдельное адресное пространство и контекст ЦП для каждого процесса, в то время как изоляция ОС использует аватары операционной системы для создания независимой среды ОС для каждой группы экземпляров процесса для дальнейшей виртуализации файловой системы и стека сетевых протоколов. ID, ID пользователя и другие ресурсы ОС. Изоляция ОС должна решать три основные проблемы: независимые представления, контроль доступа и безопасность. Механизмы пространства имен Chroot и Linux реализуют независимые представления для групп процессов, cgroups контролируют доступ к группам процессов, а такие механизмы, как Capabilities, Apparmor и seccomp, реализуют защиту безопасности. Конечно, ОС — это очень сложная и динамично изменяющаяся система.Хотя метод клонирования ОС заставляет группу процессов чувствовать, что у нее есть независимая ОС, реальная реализация по-прежнему является экземпляром ОС, поэтому общая способность защиты все еще вызывает беспокойство.
аппаратная виртуализация. Виртуализация ОС — это реализация аватара ядра ОС, а аппаратная виртуализация — это реализация аватара аппаратного устройства. Появление технологии аппаратной виртуализации позволяет нескольким операционным системам работать на одном и том же физическом сервере одновременно, и каждая операционная система считает, что управляет целым сервером. Различные операционные системы строго изолированы, а доступ гостевой операционной системы к оборудованию строго регулируется VMM или ЦП. Аппаратная виртуализация обладает хорошей безопасностью и изоляцией, но недостатком является то, что введенный уровень аппаратной виртуализации приводит к дополнительным потерям производительности.
аппаратный раздел. Это технология разделения ресурсов, используемая в традиционной мини-компьютерной системе, которая предназначена для полного разделения большого сервера на несколько аппаратных блоков от аппаратного или микропрограммного уровня, чтобы получить самый высокий уровень безопасности и изоляции. Тем не менее, миникомпьютер как технология, которая постепенно сокращается, имеет очевидные недостатки: негибкая степень детализации разделения ресурсов, высокая стоимость системы и ограниченная масштабируемость системы.
Изоляция среды выполнения языка. Для управляемых языков, таких как Java и nodejs, которым требуется среда выполнения языка, у нас также есть возможность реализовать изоляцию в среде выполнения языка. Для облачных сервисов, таких как функциональные вычисления, теоретически оптимально реализовать механизм изоляции во время выполнения языка. Тем не менее, в реализации этого маршрута все еще есть много практических ограничений, поэтому большая часть текущих вычислений функций по-прежнему использует технологию контейнеров/VM для достижения изоляции.

На техническом пути виртуализации ОС наибольший технический вклад вносит Google.

С 2003 по 2006 год Google последовательно выпускала «тройку», которая закладывала основу для вычислений больших данных, а затем дополнительно создавала концепцию «облака». Также с этого периода технология изоляции процессов вышла на более продвинутую стадию. В рамках облачных вычислений, предложенной Google, изолированный процесс — это не только тюрьма, которая изолирована от внешнего мира, но стоит на месте, но и должна быть похожа на легкий контейнер, который контролируется и развертывается для достижения кросс-платформенной, высокой доступность и масштабируемость в сценариях распределенных приложений.

В 2006 году Google представил контейнеры процессов для ограничения, учета и изоляции ресурсов (ЦП, памяти, дискового ввода-вывода, сети и т. д.) для набора процессов. Из-за более зрелой технологии Process Container вошел в ствол ядра Linux на второй год после его официального запуска в 2006 году и был официально переименован в Cgroups, что положило начало пересмотру концепции «контейнера» в лагере Linux. и реализовано.

В 2008 году, объединив возможности управления ресурсами Cgroups и возможности изоляции представлений пространства имен Linux (namespace), в ядре Linux появилась полноценная контейнерная технология LXC (Linux Container), которая сейчас широко используется. .

В общем, до изобретения докера в 2013 году операционная система Linux в основном решала технологию изоляции операционной среды, одну из основных технологий контейнеров, или технология виртуализации ОС Linux в основном оформилась.. Хотя технология изоляции операционной среды контейнеров в основном используется, нам все еще нужно дождаться другой ключевой технологии, которая откроет момент взлета технологии контейнеров.

Технологический взрыв

До 2013 года индустрия облачных вычислений беспокоилась о правильном открытии облачных технологий. Платформа как услуга (PaaS) выглядит перспективным направлением. Сервис Zimi, выпущенный Fotango в 2006 году, можно назвать основоположником индустрии PaaS с типичными облачными функциями, такими как оплата по мере использования, бессерверная конфигурация и услуги на основе API; Google запустил GAE в 2008 году; Pivotal запущен в 2011 г. Выпуск Cloud Foundry. Эти ранние платформы PaaS проводили очень полезные исследования и способствовали здоровому развитию экосистемы облачных вычислений, но эти ранние технологии исследования не сформировали основную отраслевую тенденцию, а были ограничены некоторыми конкретными областями. Только после того, как Docker был открыт, все проснулись, как сон.Оказалось, что это не было в неправильном направлении, но средства распространения и доставки приложений были плохими.

Настоящая ключевая инновация Docker — это образ Docker, новый механизм упаковки, распространения и запуска приложений. Образ контейнера будет примененРабочая среда, включая код, зависимые библиотеки, инструменты, файлы ресурсов и метаинформацию и т. д., упакованные вдистрибутив ОСнесвязанныйне может быть измененупаковка.

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

Девиз Docker: «Создавайте, отправляйте и запускайте любое приложение в любом месте». Мы уже поняли, как докер решает задачу «Запустить где угодно» через образ контейнера, так как же реализовано «Запуск любого приложения»? На самом деле это также зависит от образа контейнера.Пользователи могут упаковать среду, от которой зависит любой процесс контейнера, не изменяя приложение для адаптации к рабочей среде, определенной PaaS. На самом деле «Запуск любого приложения» одним махом разрешил дилемму, с которой столкнулась индустрия PaaS, создал безграничные возможности и активно способствовал развитию облачных технологий. Давайте вместе воздадим должное этой прекрасной идее!

На данный момент система контейнерных технологий решила две основные проблемы:Как распространять программное обеспечениеа такжеКак запустить программу, время взлета приближается. До 2014 года бывший босс компании сказал мне: «Хватит работать над ядром Linux целыми днями, почему бы тебе не взглянуть на докер?» После непродолжительного расследования я дал бывшему боссу простой и ясный ответ: «Без него есть только инструмент для упаковки. !» Из-за этого ответа дверь, которую открыл для меня облачный родной, была тихо закрыта. Оглядываясь назад на историю, я иногда сожалею об этом, потому что я был слишком молод, чтобы увидеть мощь контейнерной технологии + системы оркестровки, и я не осознавал грядущую атмосферу облачных технологий!

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

Когда дело доходит до систем оркестрации контейнеров, нам нужно начать с Google. В 2008 году Google запустила первую платформу для размещения приложений GAE (Google App Engine) на основе LXC и впервые предоставила платформу для разработки как услугу.

GAE — служба распределенной платформы. Google предоставляет пользователям такие услуги, как среда разработки, серверная платформа и аппаратные ресурсы посредством технологии виртуализации. Пользователи могут настраивать и разрабатывать собственные приложения на основе платформы и распространять их через серверы Google и интернет-ресурсы. . . . Google использует инструмент, который организует и планирует LXC в GAE — Borg (предшественник Kubernetes). Borg — это крупномасштабная система управления кластером, используемая внутри Google, которая может выполнять сотни тысяч задач, тысячи различных приложений и одновременно управлять десятками тысяч машин. Borg обеспечивает высокую степень использования ресурсов за счет управления разрешениями, совместного использования ресурсов и изоляции производительности. Он может поддерживать приложения с высокой доступностью, снижать вероятность сбоев за счет стратегий планирования и предоставлять языки описания задач, средства мониторинга и анализа задач в реальном времени. Если изолированные контейнеры являются контейнерами, то можно сказать, что Borg является самой ранней системой портов, а LXC + Borg — самой ранней структурой оркестрации контейнеров.

После запуска докера в 2013 г. он быстро захватил мир.В 2014 г. Google создал проект с открытым исходным кодом Kubernetes (сокращенно K8s) на основе системы Borg, используемой внутри компании для решения задач развертывания контейнеров, эксплуатации и управления большими масштабные кластеры. Kubernetes добавляет новый уровень абстракции управления Pod на основе контейнеров, чтобы лучше использовать контейнеры для функциональной модульной сегментации приложений. Благодаря большому опыту Google в построении крупномасштабной кластерной инфраструктуры, K8s, рожденный от Borg, быстро стал стандартным приложением в отрасли и может рассматриваться как важный инструмент для оркестрации контейнеров.

В ответ на это Docker также добавила систему управления контейнерным кластером Docker swarm в версию Docker 1.12, выпущенную в 2015 году, а также вспомогательные инструменты, такие как Docker machine и Docker Compose, чтобы создать полную систему оркестрации контейнеров и конкурировать на равных. -голова с Kubernetes. С тех пор контейнерные реки и озера разделились на два лагеря: фракция Google и фракция Docker, а система оркестрации контейнеров — Kubernetes, Docker Swarm и Apache Mesos. Конкуренция между основными фракциями обострилась, постепенно распространяясь на установление отраслевых стандартов. Вспомним вместе эту бурную историю рек и озер!

После того, как компания Docker запустила Docker в 2013 году, появилась CoreOS. CoreOS — это облегченная операционная система на базе ядра Linux, специально разработанная для построения инфраструктуры компьютерных кластеров в эпоху облачных вычислений. В то время у него был очень известный лейбл:Операционная система, разработанная для контейнеров. С помощью Docker CoreOS быстро стала популярной в сфере облачных вычислений, и на какое-то время Docker + CoreOS стала золотым партнером по развертыванию контейнеров в отрасли. В то же время CoreOS также внесла большой вклад в продвижение и создание сообщества Docker. Однако у растущего Докера, похоже, большие амбиции. Не желая быть только «простой базовой единицей», Docker самостоятельно разработал ряд связанных компонентов контейнера.В то же время он приобрел несколько компаний, занимающихся контейнеризацией, и начал создавать свою собственную контейнерную экологическую платформу. Очевидно, что это прямая конкуренция для CoreOS. В конце 2014 года CoreOS запустила собственный контейнерный движок Rocket (сокращенно rkt), пытаясь конкурировать с Docker. Подобно Docker, rkt может помочь разработчикам упаковывать приложения и зависимости в переносимые контейнеры, упрощая работу по развертыванию, например настройку среды. Разница между rkt и Docker заключается в том, что rkt не имеет «дружественных функций», которые Docker предоставляет корпоративным пользователям, таких как инструменты ускорения облачных сервисов, кластерные системы и т. д. И наоборот, то, что rkt хочет сделать, является более чистым отраслевым стандартом.

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

Результатом конкуренции между контейнерными движками (docker vs rock) и оркестровкой контейнеров (Docker swarm vs Kubernetes vs Apache Mesos) стало то, что люди садятся и обсуждают стандарты интерфейсов. В июне 2015 года Docker взял на себя инициативу по созданию OCI с целью «сформулировать и поддерживать формат образа контейнера и формальные спецификации времени выполнения контейнера (спецификации OCI)», а его основными результатами являются OCI Runtime Spec (спецификация времени выполнения контейнера), OCI Image Spec ( спецификация формата изображения), OCI Distribution Spec (спецификация распространения изображения). такОрганизация OCI решает проблему создания, распространения и запуска контейнеров..

Месяц спустя Google возглавил создание Фонда облачных вычислений (CNCF), целью которого является «создание облачных вычислений - широко используемой архитектуры, ориентированной на инфраструктуру». такОрганизация CNCF решает проблемы управления приложениями и оркестрации контейнеров.. Эти две основы вокруг контейнеров сыграли очень важную роль в развитии облачной экосистемы, они не конкурируют, а дополняют друг друга и совместно формулируют ряд отраслевых стандартов де-факто. Установление этих отраслевых стандартов де-факто вдохнуло бесконечную жизненную силу в различные отрасли, и появляются конкретные реализации стандартов на основе интерфейсов, демонстрирующие сцену цветения цветов.

Среди них наиболее важные спецификации, связанные с контейнерами, включают: CRI, CNI, CSI, спецификацию распространения OCI, спецификацию изображения OCI, спецификацию времени выполнения OCI и Shimv2. Спецификации CRI, OCI Image Spec, OCI Runtime и Shimv2 тесно связаны с контейнером-песочницей Alibaba Cloud.

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

Период коммерческой разведки

После пяти лет технологического развития контейнерная технология в основном стала зрелой, и облачная система также приобрела форму. С 2017 года крупные поставщики облачных услуг начали тестировать возможности контейнерных сервисов и прогрессивных облачных сервисов. Исходя из текущей бизнес-формы, общедоступные облачные сервисы, связанные с контейнерами, можно условно разделить на три формы:

Универсальная служба оркестрации контейнеров. До того, как стали известны результаты работы системы оркестровки контейнеров Three Kingdoms, сервисная система оркестрации контейнеров была построена на основе многосторонней стратегии ставок. AWS — это система оркестровки собственной разработки, Azure ACS одновременно поддерживает Docker Swarm, DC/OS и Kubernetes, а Alibaba Cloud ACS поддерживает Docker swarm и Kubernetes. Google и Huawei твердо поддерживают Kubernetes, не запуская сервисы контейнеров, поддерживающие другие системы оркестрации контейнеров. Поскольку Kubernetes унифицирует оркестровку контейнеров, контейнерная служба этого маршрута сокращается день ото дня, а Azure напрямую отключила службу ACS в начале этого года.
Служба оркестрации контейнеров Kubernetes. Само собой разумеется, что Google был первым крупным производителем, протестировавшим сервис оркестрации контейнеров Kubernetes для воды, а ранее он также запустил сервис оркестровки контейнеров K8s. Когда в 2017 году основные производители достигли процесса сертификации совместимости с Kubernetes за столом переговоров CNCF, на рынке услуг оркестрации Kubernetes произошел большой взрыв. К 2018 году сервисы оркестрации контейнеров K8s крупных производителей облачных сервисов будут полностью готовы.
Бессерверная служба экземпляра контейнера. С 2017 года отрасль начала тестировать сервис инстансов контейнеров без сервера для воды, освобождая пользователей от трудоемкой задачи обслуживания контейнерной инфраструктуры и сосредоточив внимание на самом бизнесе. Основной целью Google Cloud Run является поддержка Knative, поэтому на форму его использования накладывается множество ограничений.

Как видно из приведенного выше рисунка, общедоступные облачные контейнерные сервисы исследуются с 2014 года, особенно после двухлетнего преимущественного периода с 2017 по 2018 год, основная бизнес-форма контейнерных сервисов стала относительно ясной. Тенденцию развития можно охарактеризовать следующим образом:

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

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

Среди них типичная архитектура уровня узла оркестрации контейнеров и службы хостинга заключается в использовании системы IaaS для создания виртуальной машины, а затем развертывании компонентов службы контейнера, таких как kubelet, docker, containerd и runC, на виртуальной машине, то естьТехническая архитектура ВМ + контейнер. Виртуальная машина может содержать несколько экземпляров контейнеров/модулей одного и того же пользователя. Архитектура уровня узла службы экземпляра бессерверного контейнера более проста,Разверните только один экземпляр контейнера/пода на виртуальной машине, чтобы добиться бессерверности.. Такая короткая, плоская и быстрая игра быстро способствовала изучению коммерческих моделей и сыграла очень важную историческую роль, но ее исторические ограничения с точки зрения эластичности, плотности развертывания и стоимости ресурсов все еще очень велики.

Период коммерческого расширения

К 2019 году бизнес-форма и рыночная тенденция контейнерных услуг стали очевидными.Отрасль в целом вступила в стадию расширения бизнеса, с внешней рекламой для привлечения большего количества групп клиентов и внутренней напряженной работой по повышению технической конкурентоспособности продукции.Отрасль переживает технологическое обновление с «существующего» до «отличного».. Отрасль проходит этот исторический этап технологической модернизации, выводов пока нет, можно только вместе говорить о тенденциях и прогнозах. В центре внимания этой серии тем — технология изоляции контейнеров, поэтому давайте не будем говорить о расширении бизнеса и оркестровке контейнеров, а сосредоточимся на тенденции развития технологии движка контейнеров. На данный момент мы можем условно разделить технологию контейнерных двигателей на два поколения:

Container on VM. То есть, согласно идее многоуровневого проектирования, контейнерный сервис строится через архитектуру IaaS + PaaS, которая является типичной архитектурой на стадии коммерческой разведки. На основе зрелой инфраструктуры IaaS основных поставщиков облачных услуг создаются виртуальные машины, а компоненты службы контейнеров развертываются на виртуальных машинах. В этой архитектуре используется стратегия подъема и переноса, которая передает ответственность за эксплуатацию и обслуживание контейнерных служб от пользователей поставщикам облачных услуг. Использование тех же программных компонентов, что и пользователи, только передает ответственность за эксплуатацию и обслуживание, что способствует постепенному переходу клиентов в облако и принятию облачного мышления.Однако услуги, предоставляемые облачными поставщиками в этот период, представляют собой исключительно операционный и обслуживающий хостинг, и они не имеют очевидных технических преимуществ по сравнению с контейнерными сервисами, созданными пользователями. -встроенные контейнерные услуги..
Container with hardware virtualization. Если следовать многоуровневой архитектуре Container on VM, поставщикам облачных услуг будет сложно создать уникальные технические преимущества. Для бессерверных служб экземпляров контейнеров плоскость предоставления услуг была перенесена с аппаратного интерфейса IaaS на системный вызов ОС, поэтому не следуйте идее многоуровневого проектирования VM + контейнер. Нам нужно начать с источника спроса.Контейнерным службам нужен контейнерный движок с высокой производительностью, надежной изоляцией, достаточной безопасностью и низкой стоимостью. Одним из актуальных направлений отраслевых исследований и разработок является создание такого контейнерного движка. Пожалуйста, обратите внимание на последующие серии статей, посвященные конкретным техническим идеям.

резюме

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

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

слухи

После разговора об истории, давайте поговорим о докерной компании и технологии докеров!

13 ноября 2019 года Mirantis, компания, занимающаяся частной облачной инфраструктурой, объявила в своем официальном блоге, что приобрела корпоративный бизнес Docker, в том числе переняв более 700 клиентов, что означает полный провал коммерческого исследования Docker с 2013 года. Для тех, кто не знаком с историей развития контейнеров, этот результат трудно понять.Докер — пионер контейнерного бума, а контейнер — инициатор этого витка эволюции технологии облачных вычислений.Почему он явно стоит в воздух, но все еще не можешь летать?

На самом деле судьба Докера сегодня была решена 4 года назад.

После выпуска Kubernetes в 2014 году он быстро привлек группу тяжеловесов, включая Redhat, и через год быстро выпустил Kubernetes 1.0 для поддержки официального коммерческого использования. В ответ Докер возглавил создание OCI, целью которой является разработка открытого стандарта для форматов образов контейнеров и сред выполнения, чтобы продолжать занимать право голоса в экосистеме контейнеров. Однако после создания CNCF в июле 2015 года она быстро открыла новое поле битвы для обгона, сосредоточившись на оркестровке контейнеров и управлении приложениями. Затем, в 2016 году, сообщество Kubernetes сформулировало спецификацию интерфейса CRI для среды выполнения контейнера.Поскольку среда выполнения контейнера, реализующая эту спецификацию CRI, может быть подключена к экосистеме K8s, это вызвало волну исследований и разработок контейнерных движков. Продолжают появляться такие движки, как cri-containerd, cri-o и frakti.Наряду с оригинальным движком rkt, docker стал одним из движков контейнеров. Откуда он взялся, докер вернулся в исходное состояние, автономный инструмент для упаковки и запуска программного обеспечения, который в основном полностью пропустил облачную нативную волну.

Но еще долго будет существовать инструмент управления контейнерами (UI) клиента docker, в конце концов, где сильная группа пользователей. Однако в технологическом стеке производителей облачных сервисов статус докера будет становиться все слабее и слабее, и постепенно его заменит контейнерный движок, предназначенный для K8s. Хотя массовая база докеров еще сильна, искра зажглась, тренд появился, а остальное лишь вопрос времени!

использованная литература

《Ландшафт облачных и контейнерных технологий》
Краткая история контейнеров: с 1970-х до наших дней
«От виртуализации к облачным технологиям — история технологии контейнеров»
«Почему 2019 год относится к эпохе контейнерных технологий? 》
«Практика и исследования Alibaba в области безопасных контейнеров»
«Практика безопасных контейнеров в сценариях граничных вычислений»
«В ожидании 2020 года: традиционные контейнеры мертвы, а безопасные контейнеры станут облачным стандартом»

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