На конференции Container World один из последних докладов, «Контейнеры и оркестраторы: как обойти блокировки и получить максимальную отдачу от решений, базирующихся на программах с открытым исходным кодом», сделал Крейг МакЛаки, один из основателей и главный управляющий Heptio, начинающей компании, которая специализируется на разработке платформы оркестровки Kubernetes.
Что такое Kubernetes, Маклаки знает не понаслышке. Некогда он вместе с Джо Беда, вторым сооснователем Heptio, а также с Бренданом Бернсом, ныне занимающим важную инженерную должность в Microsoft, работали в компании Google. И вот лет пять назад они совместными усилиями разработали Kubernetes и выпустили его как продукт с открытым исходным кодом. До этого Маклаки вместе с Беда разработал Google Compute Engine, поставляемый корпорацией Google продукт категории Infrastructure-as-a-Service. Кроме того. Маклаки инициировал создание фондом Linux Foundation организации Cloud Native Computing Foundation, которая сегодня считается колыбелью платформы оркестровки Kubernetes. Недавно редакции ITPro Today представилась возможность встретиться с Маклаки, и мы расспросили его о тех днях, когда он работал в Google, а платформа Kubernetes делала только первые шаги.
Представители Google впервые упомянули о Kubernetes в 2014 году, но вы, Джо Беда и Брендан Бернс в то время уже работали над проектом. Могли бы вы подробнее рассказать о том, как все начиналось?
Ну что ж, отмотаем ленту немного назад. Джо и я работали в корпорации Google. Мы создали продукт, который назывался Google Compute Engine, и это был интересный проект. В сущности, мы переносили мир унаследованных ИТ-решений в центры обработки данных Google. То, что мы создавали, казалось представителям внешнего мира весьма традиционным вариантом выполнения приложений на инфраструктуре Google. Когда этот проект, что называется, сдвинулся с мертвой точки, мы с Джо стали подумывать о том, а что же делать дальше, и рассматривать проблему с других сторон.
У нас был продукт Compute Engine, который мы построили, а также Арр Engine, современное изделие категории Platform-as-a-Service (PaaS), включающее парадигмы Twelve-Factor Арр. Но между ними явно существовал разрыв, и мы занялись поисками некоего объединяющего компонента, который имел бы достаточно высокий уровень для того, чтобы устранить неопределенность инфраструктуры, но достаточно низкий для того, чтобы потребители могли выполнять на нем практически любые программы.
Мы заметили, что организации сталкиваются со множеством проблем, поскольку каждая из них целиком располагается либо в мире PaaS, либо в мире IaaS. А обитатели мира PaaS столкнулись с тем, что всякий раз, когда им попадается программный продукт, который они хотели бы запустить, но не имеют возможности, им неизбежно приходится откатываться вереду инфраструктуры как службы. Понятно, что при этом они, если говорить об инфраструктуре, теряют значительную часть выгоды, и мы пытались найти выход из положения.
Надо сказать, что Джо к тому времени был, что называется, заточен на решение подобных задач — ну прямо ясновидящий в вопросах, касающихся тенденций в развитии технологий. Он обратил внимание на технологию Docker еще до того, как ее разработчики по-настоящему взялись за популяризацию своего продукта. И мы стали прикидывать, как можно реализовать те или иные идеи. Потом к нам присоединился Брендан, а он всегда был весьма творческой личностью.
Помимо прочего, нас попросили подготовить демонстрационные материалы для этакого массового интерактивного собрания в Интернете, где мы могли бы рассказать о том, что происходит сейчас в отрасли, и поделиться с аудиторией некоторыми идеями. Брендан менее чем за день соорудил необходимый дсмоматсриал с использованием технологии Docker для выполнения рабочих нагрузок в коллекции инфраструктурных виртуальных машин Google. Я посмотрел его и сразу понял: это именно то, что нам нужно. Получился такой персональный миникластер из виртуальных машин, и в нем подкупало то, что он не обязательно следовал за определенными технологиями, как, скажем, Mesos. Это решение давало пользователям возможность найти свой вариант более прогрессивного подхода к медленному выполнению рабочих нагрузок, я бы сказал, по чайной ложке, сшивая ряд виртуальных машин так, чтобы в итоге получалась почти идеальная компьютерная ткань.
Вот здесь-то и зародилась исходная идея Kubcrnctcs. Когда Джо, Брендан и я рассуждали об этом, рассматривали подходы, главная мысль заключалась в том, что мы не будем использовать гигантские горизонтальные пристройки, подобные тем, что применяются в Mesos. Мы пойдем другим путем, основываясь на прецедентах, которые используют традиционные средства управления программной средой, такие как Puppet, Chef и Ansible. И на этих прецедентах будем строить систему. Здесь мы взяли паузу: нужно было убедиться, что все расчеты правильны.
А трудно было заручиться поддержкой руководства Google?
Скажем так — непросто. Надо сказать, что мы хотели реализовать этот проект не совсем так, как все прочие проекты. Естественно, подход компании Google был такой: давайте создадим нечто, напоминающее Borg, и предъявим свой продукт миру. В нашей компании, где работали специалисты вроде Брайана Гранта, Тима Хокинса и другие эксперты инженерного дела, создавшие два поколения программ на базе технологии управления контейнерами, была наработана масса потрясающей ДНК. А что хотели сделать мы? Не помню, кто первым высказал это предложение, но идея состояла в том, чтобы выпустить продукт как технологию с открытым исходным кодом. Начать с технологии открытого исходного кода, и это позволило бы нам подпитываться из такого мошною источника, как мир открытого исходного кода. Мы видели, как Docker получил в сообществе несоразмерный объем внимания и поддержки, и все потому, что его исходный код был общедоступным. Мы хотели повторить этот ход, но уже на следующем уровне стека, где было недостаточно просто расставить контейнеры. По-настоящему интересно было то, как вы управляете ими, как развертываете их, как обновляете приложения, где они выполняются. Наша цель состояла в том, чтобы с самого начала реализовать принцип «открытый код прежде всего». Разумеется, в руководстве Google это не всем пришлось по душе. Мы приложили немало усилий в беседах с Урсом Холзли, старшим вице-президентом Google, прежде чем он дал нам добро. Это, собственно, сделал другой человек, довольно известный, — Эрик Брюер, и в беседах с ним мы тоже провели немало времени. Так вот, он воспринял наши идеи и помог нам создать внутри компании модель проекта с целью подтверждения его обоснованности, а также оснастить нашу идею технологией открытого кода.
Продолжение в следующей статье.
Внедрение и поддержка различного ПО для оркестровки, обращайтесь [email protected]