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