Рожденный в недрах Google проект Kubernetes для управления контейнерным окружением, код которого был открыт разработчиками в середине 2014 г., сломал тщательно продуманные планы VMware, Microsoft, Oracle и других претендентов на доминирование на рынке архитектур для ЦОДов. 

Что из себя представляет Kubernetes?

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

Становление

Часть инфраструктуры ЦОДов направлена на обеспечение бесшовной работы рабочих нагрузок, а не серверов, ряд которых может выйти из строя под влиянием некорректной работы физических процессоров или виртуальных машин (ВМ). Очевидно, что сбой может привести к приостановке работы критически важных рабочих нагрузок, что попросту недопустимо, и его влияние должно быть минимальным. С момента открытия кода Kubernetes сообщество Open Source разработало несколько методологий для организации рабочих нагрузок, в том числе в ситуациях, когда возникают внештатные ситуации.

Технологии потребовалось всего несколько лет, чтобы завоевать доверие предприятий, сделавших ставку на Open Source. Основной плюс Kubernetes как платформы, то есть по-настоящему универсальной системы для развертывания приложений, состоит в том, что она физически позволяет размещать их где и как угодно: на голом железе, в публичных или частных облаках вне зависимости от их разработчиков и специфичных API.

Понимая значение этой технологии, в 2015 г. Google предприняла важный шаг, повлиявший на дальнейшую эволюцию Kubernetes. Компания провела переговоры с Linux Foundation, по итогам которых было решено учредить Cloud Native Computing Foundation (CNCF, является аффилированной структурой Linux Foundation). На нее возлагаются задачи по работе с сообществом разработчиков Kubernetes, но помимо этого она курирует такие проекты, как Prometheus, containerd, Helm, gRPC и др.

Своевременность такого шага дала достаточно времени на то, чтобы вокруг Kubernetes сплотился пул заинтересованных участников. Одновременно с этим начала вырисовываться бизнес-модель технологии — техническая поддержка. Она привлекла предприятия, которые хотели обезопасить себя от рисков lock-in (моновендорной привязки) и получить свободу действий при выборе поставщика, который мог бы оказать им помощь. В итоге вокруг CNCF сформировалась группа поставщиков, которые действовали хоть и не всегда согласованно, но подстегивали разработчиков как можно скорее довести до ума Kubernetes, чтобы вытеснить с рынка монопольные платформы.

Схема работы

Несмотря на то, что Google воспринимается как фактический лидер сообщества разработчиков Kubernetes, поскольку оно берет свое начало с проекта под названием Borg, фактически технология не принадлежит ни одной компании. Увидев ее ценность, Microsoft полностью переосмыслила систему разработки серверных систем на базе Kubernetes и наняла нескольких ее ключевых разработчиков. Примечательно, что изначально Borg обслуживал внутреннюю инфраструктуру Google, которая является лидирующей поисковой системой и именно ее можно привести в качестве примера того, как работает Kubernetes.

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

Контейнеры Docker

Распределенные компоненты, которые циркулируют в сети, пакуются в контейнеры, однако следует понимать, что это не унифицированная технология — контейнеры обладают разными форматами, к примеру, есть контейнеры Docker, Tupperware и др. Примером контейнеризации является zip-файл, где для объединения нескольких файлов в один применяется математическое сжатие. Более того, контейнеры используют ту же технологию сжатия, что и формат zip. Сжатые файлы состоят только из исполняемых элементов и данных, которые потребуются контейнеру для запуска, без необходимости искать дополнительные элементы в сети. Одним из таких файлов может быть небольшая ОС — как правило, это миниатюрная версия Linux или версия Microsoft Nano Server.

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

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

Оркестровка рабочих нагрузок

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

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

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

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

Привлекательность распределенных систем

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

• Непрерывность. Когда приложение состоит из отдельных компонентов, его намного легче дорабатывать, обновляя и улучшая компоненты по отдельности. Оркестратор может внести соответствующие корректировки, чтобы индивидуальные изменения не повлияли на рабочую нагрузку в целом. Отпала необходимость наращивания функциональных возможностей, которые реализуются в ходе капитального обновления приложений, что часто отрицательно влияет на удобство их использования. В основе контейнерной платформы лежит концепция автоматизации непрерывной интеграции (continuous integration, CI ) и непрерывной доставки (continuous delivery, CD, где «D» часто обозначает deployment, развертывание) путем ее разделения на ряд небольших и более управляемых этапов.
• Отказоустойчивость. Kubernetes поддерживает активную репликацию групп контейнеров (набор реплик) с целью поддержания работоспособности и быстродействия в случае сбоя одного или группировки контейнеров (в терминологии Kubernetes их принято называть pods, подами). По сути это означает, что ЦОДу не нужно дублировать приложение целиком и запускать балансировщик нагрузки для переключения на вторичное приложение в случае сбоя основного. Фактически, подмножество подов в наборе реплик работает одновременно, и задача оркестратора состоит в том, чтобы поддерживать их работоспособность в течение всего срока службы приложения.
• Масштабируемость. Большим преимуществом для организаций, которые управляют распределенными рабочими нагрузками с использованием Kubernetes, является встроенная возможность для их масштабирования по мере необходимости (увеличивать или уменьшать нагрузки в соответствии с заранее установленной политикой). Чтобы минимизировать риски хаотического скопления контейнеров, Kubernetes группирует связанные контейнеры в виде подов. За автоматическую репликацию подов на разные узлы отвечает служба интеллектуального горизонтального автомасштабирования autoscaler, созданная для автоматического изменения размера кластера Kubernetes (когда есть поды, которые не запускаются из-за недостатка ресурсов, или некоторые узлы долгое время используются недостаточно интенсивно).

Kubernetes — платформа?

В кругах экспертов существует некоторая неопределенность в отношении того, можно ли назвать Kubernetes такой же платформой, как Microsoft Windows или VMware vSphere, которые предлагают весь спектр служб и ресурсов, необходимых для эффективного запуска размещаемого ПО. Kubernetes определенно является «двигателем» — основным элементом, обеспечивающим подпитку распределенной программной системы, однако по аналогии с ОС MS-DOS, предшественницей Windows, поставка которой на включала дополнительные программы типа встроенного оптимизатора жесткого диска или процедуры резервного копирования, контейнерная технология предлагает только базовые элементы.

Но, как утверждают многие пользователи, выступая в качестве эффективного движка, Kubernetes является центром, вокруг которого можно выстроить костяк из любого количества сервисов, способных работать в тандеме. За поддержку и развитие последних отвечает CNCF — под эгидой фонда развивается множество независимых проектов с открытым кодом, например, системы мониторинга (такие как Prometheus), менеджеры данных журналов (такие, как Fluentd), доверенные аутентификаторы контента (Notary), которые можно без особых трудностей скомпоновать в платформу. CNCF сертифицировал 59 дистрибутивов, многие из которых являются коммерческими, и поставляются с оркестратором и другими инструментами CNCF, или собственными инструментами поставщиков дистрибутивов.

«В поставку Kubernetes дополнительный софт не входит. Это та область, где действуют разные Open Source-поставщики и проекты, предоставляя рынку множество вариантов на выбор, чтобы испробовать и подключиться к ним. Богатство выбора дает компаниям возможность построить платформу, которая оптимально подходит для решения их задач. Основной задачей сообщества является обеспечение совместимости и поддержка модулей», — считает Грэйсли. Как показывает его комментарий, Kubernetes — это однозначно «платформа-координатор», которая собирает коллекцию вспомогательных сервисов и координирует их работу. OpenShift, а также Rancher 2.0 — яркие примеры таких платформ.

Воспринимается ли Kubernetes руководителями ЦОДов и ИТ-директорами как платформа или как механизм? Это отнюдь не тривиальный вопрос. Если оркестратор продолжит развиваться, привлекая предприятия, его более не имеет смысла рассматривать как лабораторный эксперимент, к которому должен прилагаться «новый стек» ПО, поскольку у предприятий может сложиться впечатление о его незавершенности. Они рассчитывают, что Kubernetes должен обеспечить развертывание любых типов приложений, а не только новомодных микросервисов. Именно по этой причине CNCF представляет Kubernetes в качестве платформы, способной размещать как старые, так и новые приложения посредством контейнеризации, даже когда преимущества переноса старых приложений из ВМ в контейнеры не совсем очевидны.

Одной из определяющих характеристик приложений «доконтейнерной» эпохи является их неспособность к распределению или масштабированию. Современные разработчики называют такие приложения монолитными. Во время недавнего Open Source Summit исполнительный директор CNCF Дэн Кон рассказал о достоинствах модели перевода монолитных приложений в контейнеры, обозначив ее как «подъем и сдвиг». «Эта концепция подразумевает, что вы можете взять любое когда-либо написанное приложение и поместить его в контейнер. Нас приучили думать, что контейнеры обладают минимально необходимым количеством библиотек и ПО, необходимого для запуска, однако уже сейчас в контейнер можно обернуть Java-приложение объемом 8 Гб. Радует сам факт того, что оно работает в контейнере, даже если оно не переместилось в облако», — сказал он.

Контейнеризация на старте

Сторонники Kubernetes считают, что основанная на Kubernetes или интегрированная с ним платформа поможет предприятиям поддерживать по крайней мере уже существующие приложения и вместе с тем они получат опыт, необходимый для овладения контейнерной архитектурой. В качестве основы для бизнес-модели рынок предлагает для размещения контейнерных приложений ряд публичных облачных платформ: Google Kubernetes Engine (ранее Google Container Engine), Azure Kubernetes Service (ранее Azure Container Service), IBM Cloud Kubernetes Service (ранее IBM Bluemix Container Service), Amazon Elastic Container Service для Kubernetes, Pivotal Container Service, VMware Kubernetes Engine.

Даже по названиям сервисов видно, что вендоры начали заменять слово «контейнер» на «Kubernetes». Эта тенденция говорит о взрослении технологии, а также о ее становлении в качестве концепции контейнеров как услуги (containers-as-a-service, CaaS), являющейся естественной формой развития PaaS. Нужно также упомянуть о первопроходце Red Hat и ее сервисе OpenShift Online, в котором концепция CaaS с Kubernetes была применена впервые.

Для создания контейнера и его помещения на кластеры Kubernetes можно применять Docker и вышеперечисленные платформы CaaS. Преимущество CaaS состоит в том, что замена ВМ на контейнер для запуска приложения избавляет от необходимости установки облачной виртуальной инфраструктуры на стороне клиента. Это подводит почву для революционных изменений на облачном рынке. На данный момент существует крупный рынок доставки облачных ресурсов только для хостинга приложений, тогда как виртуализированные ОС, на которых они устанавливаются, отсутствуют как класс. Количество новых, немонолитных приложений в публичном облаке растет с каждым днем (об этом свидетельствует хотя бы то, в какой спешке VMware выпустила свой Kubernetes Engine), но настоящим признаком зрелости CaaS-рынка станет то, что предприятия перестанут бояться осуществить «подъем и сдвиг» навстречу контейнерной технологии.