[Перевод] Google признала сложность Kubernetes, поэтому разработала режим «Автопилот»
Новый режим GKE более дорогой и менее гибкий, но зато проще и безопаснее
Автопилот в GKE управляет подами за вас
О кластерах Kubernetes хорошо известны две вещи. Первое, что это абсолютно лучший инструмент для критически важной задачи — оркестровки контейнеров. И второе: его сложность является барьером для внедрения и общей причиной ошибок. Это признаёт даже Google, изобретатель и главный промоутер Kubernetes.
Чтобы упростить развёртывание и управление кластерами, компания представила всем клиентам GKE доступ к сервису Автопилот, который Google уже давно использует в собственных кластерах Borg. Это автоматическая конфигурация ресурсов на основе машинного обучения.
«Несмотря на 6 лет прогресса, Kubernetes по-прежнему невероятно сложен, — сказал Дрю Брэдсток (Drew Bradstock), руководитель продукта Google Kubernetes Engine (GKE), в интервью The Register. — В последние годы мы видели, что многие компании принимают Kubernetes, но затем сталкиваются с трудностями».
GKE — это платформа Kubernetes, которая работает в основном на Google Cloud Platform (GCP). Она также доступна и на других облаках или локально как часть Anthos.
Автопилот — новый режим работы GKE, он более автоматизирован и предварительно настроен для сокращения операционных затрат на управление кластерами, оптимизации кластеров для продакшна и высокой доступности.
Использование Автопилота в собственной инфраструктуре Google, источник
В Kubernetes есть понятия кластеров (набор физических или виртуальных серверов), узлов (отдельные серверы), подов (блок управления, представляющий один или несколько контейнеров на узле) и самих контейнеров. GKE полностью управляется на уровне кластера. Автопилот распространяет это на узлы и поды.
Проще всего понять особенности и ограничения Автопилота из описания системы. Обратите внимание на «предварительно настроенные» параметры (pre-configured), которые нельзя изменить.
По сути, это ещё один способ резервирования и управления ресурсами GKE, который жертвует гибкостью ради удобства. Поскольку Google управляет большей частью конфигурации, то для подов Автопилота с распределением по многим зонам она гарантирует более высокий аптайм 99,9% (см. SLA).
В облаке Google регионы состоят из трёх или более зон. Размещение всех ресурсов в одной зоне менее надёжно, чем по нескольким зонам, а максимальную отказоустойчивость даёт расширение на несколько регионов. Кластеры на Автопилоте всегда распределены по регионам, а не зонам: это надёжнее, но дороже.
Другое ограничение Автопилота — предустановленная операционная система Linux с Containerd, «оптимизированная для контейнеров». Нет возможности использовать Linux с Docker или Windows Server. Максимальное количество подов на узел 32, а не 110, как на стандартном GKE.
SSH-доступ к узлам отсутствует, узлы Автопилота заблокированы. Поддержка GPU и TPU (Tensor Processing Unit) недоступна, хотя и запланирована на будущее. «Отказ от SSH был сложным решением», — говорит Брэдсток. Конечно, это ограничивает возможности управления. Но Брэдсток сказал, что такое решение было принято по результатам исследований, показавших большой уровень критических ошибок в конфигурировании кластеров.
Модель ценообразования здесь тоже отличается. Плату берут не за вычислительные инстансы (виртуальные машины), а за реальное использование CPU, памяти и хранилища всеми подами. Плюс $0,10 в час за каждый кластер на Автопилоте, как в стандартном GKE.
Очевидный вопрос: что будет дороже, стандартный кластер или Автопилот. Ответить непросто. Поскольку это в каком-то смысле премиальный сервис, Автопилот обойдётся дороже, чем тщательно оптимизированное стандартное развертывание GKE. «Существует премия по сравнению с обычным GKE, — сказал Брэдсток, — потому что мы обеспечиваем не только функциональность, но полную поддержку SRE (Site Reliability Engineering) и гарантии SLA».
Тем не менее, Автопилот может обойтись дешевле, чем некорректно сконфигурированный деплой GKE, который не полностью загружен, потому что трудно оценить правильную спецификацию для вычислительных инстансов.
Интегральная функция распределения (CDF) неиспользуемой памяти и занятых машин для 5000 задач после включения Автопилота в собственной инфраструктуре Google, источник
Снижение ошибок памяти (OOM) и доли неиспользуемой памяти для 500 задач после включения Автопилота в инфраструктуре Google, источник
Почему просто не использовать Cloud Run, который запускает рабочие нагрузки контейнеров без какой-либо конфигурации кластеров, узлов и подов, даже на GKE? «Cloud Run — отличная среда для разработчиков, одно приложение может раскрутиться с нуля до 1000 инстансов и обратно опуститься до нуля, для того и созданы облака, — объясняет Брэдсток. — Автопилот облегчает жизнь людям, которые хотят использовать именно Kubernetes, хотят всё видеть и держать под контролем, хотят использовать сторонние скрипты, хотят построить свою собственную платформу».
Определённой проблемой является совместимость с существующими надстройками сторонними инструментами для Kubernetes. Некоторые из них пока не совместимы с Автопилотом, но другие уже работают, такие как мониторинг Datadog. Также поддерживается DaemonSets — эту функцию для запуска демонов на всех узлах используют многие инструменты.
Конфигурация хранилища, вычислений и сети вынудила отказаться от некоторого уровня гибкости и некоторых интеграций: «Но мы определённо хотим, чтобы на нём [Автопилоте] работала сторонняя экосистема», — говорит Брэдсток.
С запуском Автопилота расширяется диапазон вариантов, как запускать Kubernetes в облаке Google. Компромисс не только в более высокой стоимости и меньшей гибкости, но и в потенциальной дезориентации девопсов на предприятиях. Однако главная логика в том, что предприятиям лучше сосредоточиться на своём основном бизнесе, а не на услугах, которые выполняются подрядчиком.
У инженерной службы Google репутация гораздо лучше, чем службы поддержки клиентов. Разработчик Кевин Лин (Kevin Lin) недавно описал, как выглядит схема зачисления бонусов для стартапов в AWS и Google.
Google проявила себя как медленная и неэффективная организация, которая в итоге отправила клиента к стороннему партнёру. «Первый разговор был целиком посвящён тому, сколько денег я планирую потратить в Google (в отличие от звонка Amazon, где сотрудники хотели помочь мне запустить сервис). У Google Cloud действительно хорошая эргономика и инженеры мирового класса, но ужасная репутация службы поддержки клиентов», — сказал он.
Это ещё одно доказательство, что хорошие инженеры — не единственный важный фактор при выборе облака.
