Гибридное облако на Kubernetes: «за» и «против»
Все существующие сейчас платформы гибридного облака можно отнести к одной из двух широких категорий — основанные на Kubernetes и остальные. Соответственно, использовать Kubernetes в качестве основы или нет — вот один из главных вопросов, которые сегодня приходится решать, приступая к интеграции внутренней (или размещенной в центре колокации) инфраструктуры с сервисами общедоступного облака.
Kubernetes и гибридное облако
Сам по себе оркестратор контейнеров с открытым кодом Kubernetes — это нечто гораздо большее, чем платформа для гибридного облака. Он позволяет развертывать приложения, работающие в контейнерах (и не только), на любой инфраструктуре — локальной, в общедоступном облаке или комбинированной.
При этом, отмечает аналитик Fixate.IO Кристофер Тоцци (Christopher Tozzi), Kubernetes позволяет единым образом, независимо от инфраструктуры, на которой выполняются приложения, развертывать их и управлять ими. Это достигается благодаря абстрагированию самой инфраструктуры от среды выполнения. Если вы развертываете приложение на Kubernetes, эта процедура практически одинакова в общедоступном облаке, в центре колокации и даже на ноутбуке, которым разработчик пользуется для тестирования.
А поскольку Kubernetes позволяет управлять средами приложений, охватывающими одновременно инфраструктуру нескольких видов, оркестратор обеспечит единство развертывания и управления даже когда часть ваших серверов и приложений работают в общедоступном облаке, а остальные — внутри вашей собственной компании или в центре колокации.
Учитывая эту возможность, часть поставщиков, предлагающих решения для построения гибридного облака, в последние годы выбрали Kubernetes в качестве основы таких решений. Возможно, наиболее яркий пример, — система Google Anthos, в которой оркестратор Google Kubernetes Engine может управлять кластерами, размещенными в любом общедоступном облаке и в частном центре обработки данных. Еще один такой пример — решение Tanzu компании VMware, которое она предлагает в облаках Azure и AWS.
Сервис EKS Anywhere от самой AWS, который может управлять кластерами в локальной среде и собственном облаке компании с помощью оркестратора Amazon Elastic Kubernetes, тоже в принципе относится к платформам гибридного облака. Однако это не главное гибридное решение Amazon. Основным является AWS Outposts, которое предоставляет более широкий набор соответствующих сервисов, но не базируется на Kubernetes. Однако учитывая, что EKS Anywhere поддерживает развертывание контейнерных приложений, работающих в разных средах, его в принципе можно отнести к платформам гибридного облака.
Этим перечень крупных гибридных платформ на базе Kubernetes по большей части исчерпывается. Другие решения такого рода, в том числе AWS Outposts, Azure Stack и Azure Arc, для управления гибридным облаком пользуются иными технологиями. Все эти решения поддерживают возможность развертывания Kubernetes в рамках гибридной архитектуры, но не применяют сам оркестратор в качестве слоя управления гибридным развертыванием.
Kubernetes или нет?
Какой подход к построению гибридного облака лучше? Ответ зависит от ряда факторов. Главный из них, считает Кристофер Тоцци, — предпочтительный для вас принцип управления рабочими нагрузками: с помощью Kubernetes или посредством стандартных инструментов публичного облака. На платформах Anthos и Tanzu, например, оркестратор с открытым кодом используется для координации всех процессов, тогда как в решениях вроде Outposts и Azure Stack для развертывания приложений и управления ими используются собственные облачные инструменты оператора (CloudWatch, CloudTrail, CloudFormation и т.д.). Если вы предпочитаете средства развертывания приложений и управления ими, которые предлагает сам оркестратор Kubernetes, возможно, стоит сделать выбор в пользу платформы, где есть эта возможность.
Второй фактор, который стоит учесть при выборе, — масштабы контейнеризации ваших приложений. Kubernetes позволяет управлять не только контейнерами, но и виртуальными машинами, и в частности, в Tanzu и Anthos оркестрация виртуальных машин — одна из основных функций. И все же, применять Kubernetes для управления виртуальными машинами кажется не вполне уместным, учитывая, что система в первую очередь предназначена для контейнеров. Виртуальным машинам обычно нужно больше времени на запуск и остановку, чем контейнерам, и чаще всего ВМ запускают в меньшем количестве экземпляров, чем контейнеров. Если ваши рабочие нагрузки преимущественно состоят из виртуальных машин, вероятно, в этом случае больше подойдет гибридное облако, основой которого является какое-то другое решение
Неплохо также учесть долгосрочные перспективы самого Kubernetes. Сегодня он пользуется бешеной популярностью, в связи с чем платформу, собственно, и взяли на вооружение Google, VMware и другие компании, однако она появилась всего семь лет тому назад. Вполне возможно, что со временем Kubernetes уйдет в прошлое, как временное увлечение, а не станет одним из столпов мира ИТ.
Можно напомнить, что еще пять-шесть лет тому назад, когда о Kubernetes еще мало кто слышал, казалось, что технологическим миром будет править система контейнеризации Docker и что надо внедрять решения на ее основе. Но вышло по-другому: создатели Docker из одноименного стартапа раскрыли формат контейнеров, а Google передала сообществу Open Source свою разработку Kubernetes. В результате Docker стал лишь катализатором развития экосистемы Kubernetes. Альтернативой решению с открытым кодом мог бы стать оркестровщик контейнеров Mesosphere и другие, но поскольку Kubernetes взяли на вооружение тяжеловесы во главе с Microsoft, этого не произошло. Если история повторится, внедрять сейчас гибридную платформу на базе Kubernetes, — это все равно что несколько лет тому назад полностью перейти на Mesosphere. Все будет работать, пока будет сохраняться «хайп», но когда мода пройдет, возможно, понадобится полная перестройка.
И, напоследок, в процессе выбора стоит учесть еще один фактор. В целом гибридные облака на Kubernetes обеспечивают больше гибкости, чем среды, зависимые от собственных инструментов облачного оператора. Например, если вы пользуетесь Azure Stack, то в случае необходимости будет трудно перейти на AWS Outposts, ведь по сути это потребует полноценной миграции из Azure в AWS. А вот переход с Anthos на Tanzu пройдет проще (хотя тоже не идеально легко), поскольку обе платформы базируются на Kubernetes.
В любом случае, на сегодня есть немало причин остановить свой выбор на Kubernetes в качестве платформы гибридного облака. Вместе с тем, могут быть и вполне разумные основания выбрать платформу, которая не имеет инструментов Kubernetes, и поддерживает больше видов рабочих нагрузок, чем решение с открытым кодом.