Что такое Кубернетес? Все, что нужно знать вашему бизнесу

Что такое Кубернетес?

Определение Kubernetes постоянно меняется, потому что по мере своего роста Kubernetes меняет мир вокруг себя. Вот и осеннее издание 2019 года: Kubernetes — это механизм распределения и оркестровки рабочей нагрузки для кластерных серверов в центре обработки данных, обеспечивая доступность ресурсов, доступность и сбалансированное выполнение нескольких сервисов одновременно.

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

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

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

Бизнес-кейс для Kubernetes

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

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

• Облако основано на виртуализации первого поколения., который устарел и, возможно, со временем станет неактуальным. Образ программного обеспечения, которое обычно устанавливается на главный жесткий диск сервера, визуализируется в памяти и хранилище удаленного сервера, чтобы программное обеспечение могло работать там, как всегда до. Теперь нет необходимости в том, чтобы программное обеспечение работало так, как оно всегда работало раньше. Экономическое обоснование продолжения производства монолитных приложений испарилось, даже в случае массовая многопользовательская онлайн-игракомпании, чьи базовые проприетарные платформы являются исключительной собственностью их производителей.
• Интернет отображается с использованием доменной системы. который сопоставляет адреса их зарегистрированным владельцам, а не используемым функциям и услугам. Сервисные сетки накладывают на эти карты более актуальные карты, позволяя распределенным приложениям находить друг друга в сильно рассредоточенных сетях. И эти сервисные сетки тесно связаны с Kubernetes, обеспечивая второй по значимости сервис системы после оркестрации рабочей нагрузки.
• Мобильные устройства зависят от мобильных приложений которые распределяют «умные» функции на стороне клиента, главным образом для минимизации обмена информацией между клиентами и серверами. Поскольку пропускная способность беспроводной сети больше не является товаром премиум-класса, может оказаться более практичным и экономически эффективным перенести эту функциональность обратно на серверную сторону, что позволит создать новый класс устройств, которые значительно «тупее», чем их предшественники, хотя и с действительно отличными камерами, но выполняют те же задачи с гораздо большей производительностью. скорости.
• Центры обработки данных общедоступного облака массивные, «гипермасштабные» объекты которые обслуживают десятки тысяч арендаторов одновременно, зачастую на расстоянии нескольких сотен миль. Благодаря более высокой степени распределенности вычислений может стать более практичным и желательным иметь большее количество гораздо меньших центров обработки данных, разбросанных поближе к своим пользователям.
• Искусственный интеллект представляет собой высший класс программного обеспечения., главным образом из-за его относительно высокая стоимость памяти, хранилища и других ресурсов. Используя модели распределенных сервисов, включающие множество контейнеров, каждый из которых занимает гораздо меньше места, ИИ может стать гораздо более распространенным явлением, поскольку программное обеспечение, которое делает более точные выводы (например, «Ищите это дерево в 30 ярдах от меня!»), не будет называться «умным», как его называют «стандартным операционным». оборудование."
• Контейнеризация упрощает управление бизнес-программным обеспечением. В контексте серверных вычислений контейнер — это пакет, который позволяет виртуализировать рабочие нагрузки. (переносимый, автономный, работающий изолированно), но при этом размещается на операционной системе (в отличие от гипервизор). Современные приложения становятся переносимыми между серверами за счет их контейнеризации, а это не просто упаковка и развертывание. В контейнерной среде код программного обеспечения извлекается или «извлекается» из репозиториев (некоторые из них общедоступные, другие — частные), а затем немедленно развертывается и запускается в производственной среде. Этот метод автоматического развертывания позволяет совершенствовать программное обеспечение не только каждые восемнадцать месяцев или около того, но потенциально каждый день, причем не только его создателями, но и его пользователями. В свою очередь, это значительно повышает целостность и безопасность системы центра обработки данных.

Что означает «оркестровка»

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

Как дирижер оркестра?

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

Отличие оркестратора от операционной системы

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

Это не значит, что Kubernetes — это масштабируемая операционная система. ОС по-прежнему играет роль организатора выполнения каждой программы. А в контейнерной среде (по крайней мере, в ее родной среде в том виде, в котором она была изначально спроектирована) хостом каждого контейнера является не гипервизор, как в случае с vSphere или KVM, а скорее операционная система.

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

Куда уходит все программное обеспечение?

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

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

Почему контейнеризация так важна, если у нее такое паршивое имя?

Контейнеризация — это тенденция, официально начатая Docker Inc., затем доведенная до невероятной скорости Google, а теперь к ней присоединились большинство остальных участников платформы, включая Microsoft и VMware. Четыре года назад нам сказали, что это эзотерический аспект управления центром обработки данных, который останется незамеченным обычным пользователем. Тем не менее, каждый зритель Netflix и Amazon Prime, а также каждый пользователь Alexa и Siri ощутили это влияние на собственном опыте, даже если она не была способна определить его источник. Смещение фокуса управления центром обработки данных с машин на рабочие нагрузки произвело революцию в способах предоставления приложений и услуг.

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

Что это за «рабочая нагрузка»?

Программа, работающая на компьютере, по-прежнему остается «программным обеспечением», используя термин, который инженеры НАСА первоначально придумали в эпоху Аполлона в качестве каламбура. А приложение по-прежнему остается программой, предназначенной для работы несколькими пользователями и называемой по имени.

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

Разработчики программного обеспечения обычно не садятся за стол и не составляют рабочие нагрузки. Они до сих пор пишут программы. Но в процессе развертывания контейнеров, собранных вокруг этих программ, инструкции, данные оркестратору, такому как Kubernetes, в конечном итоге объявляют рабочие параметры активной рабочей нагрузки. Таким образом, в процессе развертывания программное обеспечение становится рабочей нагрузкой. Его влияние на потребление ресурсов центра обработки данных можно измерить и смягчить, как и влияние рабочей нагрузки на повседневную жизнь людей и вещей можно измерить и смягчить сотрудники.

Хорошо, тогда что такое «услуга»?

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

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

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

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

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

Компоненты Кубернетеса

Возможно, вы заметили, что в первых десяти абзацах этой статьи не упоминается ни слово «контейнер», ни, тем более, слово «контейнер». самоочевидное слово «контейнеризация». Отделение Kubernetes от контейнеров — одно из самых неожиданных изменений за последние месяцы в области применения. Кубернетеса. Через несколько минут вы поймете, почему.

Одна из ключевых задач оркестрации — сделать вещи доступными в сети. До сих пор мы в основном называли эти вещи «контейнерами», хотя и отмечали, что с тех пор В начале своего существования Kubernetes называл сущности, которые он координирует и эффективно организует, как стручки. В этом контексте термин «модуль» определяется просто как «группа контейнеров».

Поды и ресурсы на плоскости управления

Каждый сервер (физический или виртуальный) в кластере Kubernetes называется узлом. Если он содержит какой-то аспект Kubernetes и доступен через сеть, поддерживаемую оркестратором, это узел. Существует главный узел и любое количество рабочих узлов (иногда называемых миньонами). Сеть компонентов, отвечающих за управление системой, отделена от всех других сетей и образует плоскость управления. В этом эксклюзивном самолете вы найдете три компонента:

• API-сервер(кубе-апайзервер), который проверяет все входящие запросы, в том числе к службам, работающим внутри модулей.
• Менеджер контроллера(кубе-контроллер-менеджер). Отдельные компоненты Kubernetes, несущие прямую ответственность за управление некоторыми ресурсами внутри системы, называются контроллерами. Например, подготовка задания для службы на основе модулей — это задача для контроллера заданий. Вот тут-то все становится интереснее: Kubernetes можно расширить за счет добавления дополнительных контроллеров, что делает его оркестратором не только контейнеров.
• Планировщик (kube-scheduler), что касается не столько времени, сколько делегирования рабочих нагрузок подам. Когда модуль подготовлен, планировщик делегирует его рабочему узлу, который лучше всего подходит для его обработки, учитывая его текущее состояние доступности.

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

Пользовательские ресурсы

Именно расширяемость этой схемы контроллера может, в конечном итоге, стать мастерским ходом, который укрепит позиции Kubernetes в центрах обработки данных. В результате архитектурного дополнения, называемого пользовательскими определениями ресурсов (CRD), Kubernetes может управлять не только этими контейнерами, но и другими вещами.. Другими словами, если вы можете создать контроллер, который эффективно научит Kubernetes распознавать что-то еще как оркестрованный ресурс, он так и сделает. О чем мы здесь говорим? Что может быть «чем-то еще»?

• Виртуальные машины (ВМ) -- Классические объекты, управляемые гипервизором, которые поддерживают большинство корпоративных рабочих нагрузок в мире. VMware, чья платформа vSphere является доминирующим коммерческим лидером в области управления виртуальными машинами, уже начал проект, чтобы сделать Kubernetes основным оркестратором виртуальных машин..
• Массивные базы данных чьи механизмы и функции управления в последние годы были перенесены в специализированные системы, такие как Hadoop и Apache Spark, и которые, предположительно, могли бы отойдите от этих платформ, если разработчики снова смогут писать рабочие нагрузки, используя языки, отличные от избранных, таких как Java, Scala и Р.
• Рабочие нагрузки высокопроизводительных вычислений (HPC) для суперкомпьютеров, которые исторически управлялись специальные планировщики, такие как Slurm и, совсем недавно, Апачи Месос. Их преимущества в центрах обработки данных как агентов планирования, ориентированных на время, теперь подвергаются сомнению, поскольку Kubernetes приближается к почти повсеместному распространению.
• Модели машинного обучения, которые требуют больших объемов данных с параллельным доступом, а также детерминированного планирования. Вы можете подумать, что сами по себе эти факторы дисквалифицируют Kubernetes как оркестратора или посредника инфраструктуры, но существуют такие проекты, как Кубефлоу где поставщики баз данных и планировщики, которые предоставляют эти функции, сами предоставляются Kubernetes.

Объекты на плоскости данных

Все эти классы объектов, несущих рабочую нагрузку, которые собираются в модули, а также все остальное, что Kubernetes может организовать в будущем, становятся предметы, за неимением лучшего слова.

Что объясняет оркестратору один из этих объектов, так это файл, который служит его идентификационными документами, называемый манифестом. Это элемент кода, написанный с использованием языка YAML, который объявляет ресурсы, которые объект планирует использовать. Здесь контроллер может предварительно просмотреть, сколько топлива, если хотите, будет потреблять объект — сколько места для хранения данных, какие классы баз данных, какие порты в сети. Контроллер делает все возможное, чтобы удовлетворить эти требования, зная, что, если кластер уже перегружен, ему, возможно, придется сделать все возможное, используя то, что у него есть.

Внутри каждого модуля находится удаленный агент под названием кубелет, который получает запросы от оператора и управляет компонентами модуля. В обычной контейнерной системе это кубелет который порождает процессы для механизма контейнера. Именно здесь у Docker раньше было зарезервированное место за столом Kubernetes — раньше он был де-факто эксклюзивным поставщиком контейнерных движков. Он даже создал универсальную среду выполнения под названием запуститьC (произносится как «беги · смотри») и выпустил его для сообщества разработчиков программного обеспечения с открытым исходным кодом. Теперь проект Kubernetes породил собственную альтернативу под названием ЦНИИ-О («крик · О», хотя иногда произносится как «креольский»), который является предпочтительным контейнерным движком Платформы на базе Kubernetes, такие как Red Hat OpenShift..

Побежденные конкуренты Kubernetes

Прежде чем большая часть технической прессы пришла к коллективному осознанию того, что пространство оркестрации серверных кластеров является самым горячим полем битвы в современном центре обработки данных, битва уже закончилась. Товарные рынки редко терпят конкурирующие стандарты в течение длительного времени. Вот почему существует один HTML, один Facebook и один Kubernetes.

Докер Рой

Docker Inc., компания, чьи инженеры ответственны за запуск контейнерной революции, основала бизнес философия, основанная на коммерциализации крупномасштабного развертывания, безопасности и поддержки бесплатного ПО с открытым исходным кодом. основной. Доход будет поступать от дополнений и усилений ядра Docker, которые имели торговую марку Docker, но для которых были широко доступны заменители, для бизнес-модели, которую оно называло «Батареи». Включены, но заменяемы». Если контейнеры станут повсеместными, утверждали лидеры Docker, у них не должно быть никаких претензий, интеллектуальных или иных, на то, что делает контейнеры товар. Компания считала, что более широкий рынок приведет к увеличению числа желающих клиентов.

С этой целью в 2015 году Docker поддержал создание Инициативы открытых контейнеров (OCI, первоначально либо Open Container Project, либо Open Container Foundation, хотя по множеству причин вскоре потребовалось изменение названия) под эгидой Linux Foundation. Делая это заявление во время конференции компании, тогдашний технический директор Соломон Хайкс рассказал своей аудитории ему не нравились войны стандартов, которые он описывал как споры из-за «таких деталей, как размер и форма коробки». По этой причине среди другие, Хайкс объявил о замене компонента среды выполнения контейнеров Docker — той части, которая обеспечивает их работу по сети — с запуститьC.

На той же неделе многие из тех же членов-основателей ОКИ объявили о создание Фонда облачных вычислений, еще один проект Linux Foundation. Якобы мандат CNCF будет заключаться в продвижении и продвижении использования технологий развертывания приложений с открытым исходным кодом. CNCF будет руководить первым проектом, начиная с марта следующего года. будет Кубернетес, проект, зародившийся в Google.

Между тем, после нескольких экспериментов с менее универсальными и порой неуклюжие попытки развертывания платформSwarm стал оркестратором Docker. По мнению большинства, Swarm был достойным соперником. Администраторы сказали, что кривая обучения гораздо менее сложна. Его модель наложенной сети, которая разделяла трафик между контейнерами и трафик хоста, каждый в своей плоскости с мост между ними считался умным, особенно по сравнению с моделью плоского наложения сети Kubernetes. В модели развертывания нескольких облаков кластер контейнеров Swarm можно делегировать более медленному общедоступному облаку, а трафик на плоскости управления можно более тщательно ограничить в кластере с меньшей задержкой. В плане производительности и управляемости эксперты не спешили с выбором фаворитов.

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

CNCF поставила перед собой задачу продвигать и способствовать широкому развертыванию всей экосистемы с открытым исходным кодом, включая мониторинг производительности, обнаружение сервисов, управление объемами данных и безопасность — все сосредоточено вокруг одного развертывания рабочей нагрузки. двигатель. Docker уже начал запускать свою модель расширяемости, но сразу запутался в эзотерической, философской трясине вопрос о том, нарушает ли расширяемая архитектура определенную догму проектирования приложений, называемую «безгражданством».

В то же время, хотя Kubernetes представлялся полностью независимой от поставщика платформой, в те первые дни Google приложил весь свой вес и мускулы, лежащие в основе его маркетинга, адаптируя тему и последовательную презентацию как для потребителей, так и для журналистов, одновременно вплетая имя Kubernetes в свою брендинг. На протяжении 2017 года предприятия, оценивающие Kubernetes, воспринимали его как продукт Google. Когда им объяснили законность и формальности, многие отмахнулись от них, заявив, что все это не имеет значения, пока конечный результат будет чем-то, называемым Движок Google Кубернетес. Во время многих бесед, в которых я участвовал, ИТ-администраторы и другие опытные специалисты-практики рассказывали мне, если вопрос сводится к Google или Google. Докер, что такое Сэм Хилл Докер?

Однако Google не смогла долго сохранять видимость единственного защитника веры в оркестровку. Еще в 2015 году Red Hat приняла важное решение заменить движок своей платформы развертывания контейнеров OpenShift на Kubernetes. К 2017 году это решение окупилось сторицей. Red Hat стала ведущим участником Kubernetes. На севере Microsoft, стремясь предотвратить возможность оказаться в стороне от новой волны изменений на предприятии, наняла двух наиболее заметных инженеров сообщества открытого исходного кода: Гейб Монрой, который был соучредителем и техническим директором Deis, ключевого фактора в экосистеме Kubernetes для создания и развертывания контейнерных приложений (оплот, который Docker надеялся защитить сам); и Брендан Бернс, один из инженеров Google, создавший Borg, прототип Kubernetes.PDF]. На этот раз Microsoft не стала прятать своих новых сотрудников в чулане какого-то побочного проекта исследовательского подразделения. Они взяли на себя инициативу по переработке значительной части Azure в образе Kubernetes.

Плотину прорвало, причем сразу в нескольких местах.

Апачи Месос

Признанным лидером в планировании рабочей нагрузки для распределенных кластеров серверов был Apache Mesos. Он стал пионером в архитектуре «главный/рабочий» (хотя Mesos использовал другое слово для обозначения «работник») и был одним из первых планировщиков, расширенных до частной платформы PaaS под названием Marathon. Первое крупное развертывание Mesos произошло в Twitter, где Бен Хиндман работал инженером. В 2013 году Хиндман ушел и основал ведущего коммерческого поставщика Mesos — компанию MesSphere. Сотрудничая с Microsoft, компания Mesphere создала одну из первых общедоступных облачных PaaS, обеспечивающих управляемое гибридное развертывание: ДК/ОС, который выглядел так, будто станет лучшей платформой для развертывания рабочих нагрузок в Azure. У Mesos был несколько лет опыта развертывания, так что это была платформа, которую не всем приходилось понимать с самого начала.

Но действующий президент Месос не смог избежать воздействия повстанческого соперника, набравшего полную силу. В августе 2017 года VMware задействовала ресурсы своей дочерней компании Pivotal для запуска облачная платформа Kubernetes под названием Pivotal Container Service, с механизмом автоматического развертывания под названием Kubo, пришедшим из Cloud Foundry. Вскоре этому примеру последовала Azure, фактически отложив на второй план свой проект DC/OS. Затем, в июне 2018 года, стойкий приверженец Amazon сдала оборонительную позицию, открыв свою платформу развертывания Kubernetes. И, наконец, мало кто верит в то, что Приобретение IBM компании Red Hat, завершившееся в июле прошлого года, речь шла о том, что IBM нуждается в лучшем дистрибутиве Linux. OpenShift уже проложила маршруты к распределенному центру обработки данных, которые, как обнаружила IBM, больше не нужно прокладывать снова.

Поражение было настолько полным, что Мезосфера больше не могла вести дела с этим именем. переименовал себя в D2IQ в августе прошлого годаи поклявшись создать собственную «Ксферу». И в начале октября, Докер предложил что его пользователи пытаются запускать Kubernetes и Swarm одновременно. «Новым пользователям гораздо легче понять Docker Swarm», — говорится в сообщении в блоге компании. «Однако Kubernetes эволюционировал и добавил много функциональности».

Куда пойдет Kubernetes дальше

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

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

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

Люди, создавшие Kubernetes, несколько лет назад сказали, что настанет время, когда их творение станет настолько неотъемлемая часть всех центров обработки данных, что они были бы скучными, и никто не стал бы читать статью о это. Судя по тому, что я наблюдаю, до этого дня еще как минимум несколько лет.

Узнайте больше — из интерактивной сети CBS.

• Следующим шагом Kubernetes может стать попытка организовать все остальное. Скотт М. Фултон, III, ЗДНет
• 5G зависит от Kubernetes в облаке Стивен Дж. Воган-Николс, ЗДНет Linux и открытый исходный код
• Почему Red Hat видит в Knative ответ на оркестровку Kubernetes Джеймс Сандерс, TechRepublic Cloud

В другом месте

• Определения пользовательских ресурсов Kubernetes: объяснение CRD от программного обеспечения BMC
• Архитектура Кубернетеса 101 от Aqua Container Security
• Понимание архитектуры Kubernetes от Эдурека