Новый режим GKE более дорогой и менее гибкий, но зато проще и безопаснее
![](https://habrastorage.org/webt/l9/ob/sp/l9obspg93oxyldyszv15favvdn4.png)
Автопилот в 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, он более автоматизирован и предварительно настроен для сокращения операционных затрат на управление кластерами, оптимизации кластеров для продакшна и высокой доступности.
![](https://habrastorage.org/webt/n-/sl/lt/n-slltzd1scd4pamemw9csuoto8.png)
Использование Автопилота в собственной инфраструктуре Google, источник
В Kubernetes есть понятия кластеров (набор физических или виртуальных серверов), узлов (отдельные серверы), подов (блок управления, представляющий один или несколько контейнеров на узле) и самих контейнеров. GKE полностью управляется на уровне кластера. Автопилот распространяет это на узлы и поды.
Проще всего понять особенности и ограничения Автопилота из описания системы. Обратите внимание на «предварительно настроенные» параметры (pre-configured), которые нельзя изменить.
Сравнение режимов Autopilot и Standard
![](https://habrastorage.org/webt/d1/0t/0v/d10t0vapobpnx-xrc6aheyxvcd0.png)
По сути, это ещё один способ резервирования и управления ресурсами 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, который не полностью загружен, потому что трудно оценить правильную спецификацию для вычислительных инстансов.
![](https://habrastorage.org/webt/8q/gy/fy/8qgyfyyhz0zlxbwucahm9aerhtw.png)
Интегральная функция распределения (CDF) неиспользуемой памяти и занятых машин для 5000 задач после включения Автопилота в собственной инфраструктуре Google, источник
![](https://habrastorage.org/webt/6j/m3/g0/6jm3g0wrlzq2typ4t5zglfwhwpe.png)
Снижение ошибок памяти (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 действительно хорошая эргономика и инженеры мирового класса, но ужасная репутация службы поддержки клиентов», — сказал он.
Это ещё одно доказательство, что хорошие инженеры — не единственный важный фактор при выборе облака.