Готовые кластеры Kubernetes или самостоятельное развертывание? Что выбрать

Многие провайдеры предлагают услугу Managed Kubernetes — это готовые кластеры Kubernetes на базе облачной инфраструктуры. Обычно провайдеры объясняют ценность подобных PaaS-сервисов так: мы сами заботимся об отказоустойчивости кластеров, control plane и избавляем администраторов от рутинных задач.

Альтернатива managed-решению — это кластеры, которые собственноручно поднимают и настраивают сисадмины конкретной компании (self-hosted). Это можно сделать как на виртуальных машинах, так и в bare metal-инсталляциях на выделенных серверах. Второе встречается чаще, поскольку развертывать кластеры на выделенных серверах, как правило, дешевле, чем в облаке.

Под катом рассказываем, чем отличается Managed Kubernetes от самостоятельного развертывания инфраструктуры, и рассуждаем, кому подойдет готовое решение. Если у вас есть опыт подобного выбора, делитесь в комментариях!

Сравним готовые кластеры и self-hosted-решение

Чтобы лучше понять разницу между подходами, вспомните, как арендовали квартиру на Airbnb.

В арендованной квартире у вас уже все есть: холодильник, кухня, стиральная машина и даже кофеварка. Сломался душ — хозяин быстро вызовет сантехника. Если развалится стул на кухне, его заменят. Вы живете как обычно, разбрасывая носки в спальне. Только платите вы больше, чем за собственную квартиру, а еще не можете перекрасить стены под цвет настроения и переставить мебель.

Аренда квартиры на Airbnb — это готовые кластеры Kubernetes. Провайдер предоставляет все необходимые ресурсы — мощности облачных серверов, диски, обеспечивает отказоустойчивость решения, добавляет необходимую автоматизацию. Но доступ к control plane и мастер-нодам клиенту ограничен — забота о них находится в юрисдикции провайдера.

Решение self-hosted — это квартира, в которой вы сделали ремонт, а теперь живете. На старте пришлось потратить много времени и сил, особенно если вы справлялись без помощи мастеров на аутсорсе. Это было непросто, но зато в квартире все подобрано под ваш вкус, вы можете менять мебель и вешать постеры в туалете, а платите привычную сумму за КУ. Какие минусы? Вы полгода не могли въехать в квартиру, пока не закончили ремонт, а еще все поломки в квартире — исключительно ваша проблема.

Есть вещи, от которых вас не застрахует ни заботливый хозяин, ни владение квартирой. Например, вы можете забыть выключить утюг (→ пожар), оставить наполняться ванну и заснуть (→ потоп), не закрыть дверь (→ кража)… Есть вещи, за которые ответственны исключительно вы. В кластерах Kubernetes, как готовых, так и собственноручно поднятых, это ответственность за работу приложения внутри контейнера.

Итак, базовый принцип понятен. Теперь рассмотрим конкретные пункты, где конкурируют самостоятельное развертывание и managed-решение.

Скорость развертывания

Managed-решение. Провайдеры предлагают быстрый старт работы с кластерами Kubernetes для людей с разным уровнем подготовки. Менее опытных порадует работа через интерфейс, где нужно выбрать сет-ап кластера, отметить несколько чекбоксов, подождать несколько минут и загрузить в воркер-ноды необходимые приложения. Более опытные пользователи быстро создадут кластеры описанной конфигурации через Terraform-провайдера. Все работы можно завершить в течение дня.

Самостоятельное развертывание. Здесь придется сделать шаг назад и начать с выбора инфраструктуры — облачных или выделенных серверов. Только после этого можно заняться непосредственно Kubernetes: создать кластеры, задать им необходимые настройки, подумать об автоматизации. Все это займет больше времени в зависимости от опыта и компетенций сисадмина.

Требования к навыкам сисадминов

Managed-решение. Готовые кластеры Kubernetes требуют базовых знаний оркестратора — хотя бы понимания его основных абстракций. В остальном вся техническая «жесть» — конфигурирование control plane в составе kube-scheduler, etcd, kube-apiserver и других компонентов — находится в зоне ответственности облачного провайдера.

Самостоятельное развертывание. Здесь потребуются более серьезные компетенции системного администратора, если речь не идет о каком-нибудь minikube. Ему настраивать работу control plane, следить за ее работоспособностью и отказоустойчивостью. Нужно будет самостоятельно настраивать мониторинг мастер-нод и подумать, что делать в случае отказа одной из них. Существует ряд инструментов для облегчения работы — например, rancher (open source-платформа для управления контейнерами), но не для всех это панацея.

Managed Kubernetes — готовый инструмент: «потыкал» кнопки и кластер можно использовать по назначению. Развернуть его на «голом» железе сложнее. Половина контейнеров у нас в Managed Kubernetes, другую половину развернули самостоятельно. Для этого пришлось оплатить два месяца работы стороннего разработчика — запуск и отладку, потому что в компании не все умели работать с k8s.

Алексей, сисадмин в компании, которая занимается системой мониторинга грузового транспорта

Автоматизация

Managed-решение. Автоматизации «из коробки» — киллер-фича готовых кластеров Kubernetes. Настроить их и поддерживать работу самостоятельно довольно сложно. Провайдеры же предлагают возможности по автохилингу — развертыванию новой воркер-ноды, если старая перестала отвечать, автомасштабированию, когда число нод повышается при росте нагрузки или снижается при ее падении, и автообновлению версий Kubernetes.

Самостоятельное развертывание. Здесь возвращаемся к вопросу о компетентности администраторов. Для самостоятельной настройки автоматизации нужно владеть такими инструментами, как Puppet, Ansible, Chef, Saltstack или другими, а также потратить в разы больше времени.

Сначала у нас был монолит на bare metal, но в период первой волны коронавируса мы поняли, что не можем быстро масштабироваться под увеличивающейся нагрузкой. Вынесли из монолита фронтенд и часть сервисов в Kubernetes. Ценность для нас представляла именно легкость масштабирования, а Managed Kubernetes был самым быстрым вариантом решить проблему с резко нарастающей нагрузкой из-за пандемии.

Алексей, CTO сервиса доставки продуктов на дом

Отказоустойчивость

Managed-решение. Здесь провайдер может предложить кластер, в котором 3 мастер-ноды создаются в нескольких зонах доступности одного региона. При этом группы нод можно создать в разных регионах, тем самым повысив отказоустойчивость. Кроме того, провайдер несет ответственность за доступность кластера. Так, в Selectel бесперебойная работа control plane закрепляется SLA.

Самостоятельное развертывание. Реализовать отказоустойчивость системы self-hosted можно, но, опять же, это потребует большего времени администратора и компетенций, а также повысит чек за инфраструктуру. Нужно будет добавить резервные площадки — дополнительные виртуальные машины под ноды — или брать более мощный сервер под bare metal.

Кастомизация

Managed-решение. В случае готового продукта чаще всего бывают ограничения по доступности к ряду элементов и возможности менять системы под себя.

→ Так, в Managed Kubernetes от Selectel отсутствует доступ к мастер-нодам, поскольку за доступность кластера полностью отвечает провайдер. Клиент может свободно управлять кластерами в облаке со своего ноутбука через kubectl, скачав kubeconfig. Но, вызвав информацию о кластере, в списке нод админ увидит только воркер-ноды, без мастеров.

→ Особенности может налагать платформа, выбранная для реализации сервиса. Провайдер связывает Kubernetes с выбранным облаком, и те ограничения, что были в облаке, передаются «по наследству» системе оркестрации. Например, OpenStack, на котором работает Managed Kubernetes, накладывает некоторые ограничения на использование сетевых дисков, переписывание сетевых маршрутов на нодах кластеров, работу с сетевыми абстрациями вроде балансировщиков нагрузки.

Впрочем, managed-решение не «связывает руки» и не исключает кастомизацию полностью. Необходимые настройки «под себя» можно добавлять через kubelet или API.

Самостоятельное развертывание. В данном случае есть большая свобода в конфигурировании кластеров и нижележащей инфраструктуры, в том числе сетевой. Поэтому self-hosted часто выбирают компании, которым нужен полный контроль инфраструктуры или нетривиальная кастомизация.

На данный момент (май 2023 года) Managed Kubernetes поддерживает самые актуальные версии оркестратора: 1.25.9, 1.24.13, 1.23.16.

Создать новый кластер в Managed Kubernetes можно тремя способами:

• через единую панель управления — нужные опции можно «накликать» в интерфейсе,
• через Terraform, если компания придерживается концепции Infrastructure-as-a-code, у Selectel есть собственный Terraform-провайдер (инструкция, как создать кластер с помощью него),
• через API Selectel — вариант для тех, кому не подходит панель управления.

Рассмотрим возможности Managed Kubernetes через интерфейс в панели управления.

Выбор региона и типа кластеров

Создать готовый кластер Kubernetes можно в облачных регионах в Москве, Санкт-Петербурге, Новосибирске и Ташкенте.

Клиент может выбрать региональный или зональный тип кластера. Региональный подразумевает наличие 3 мастер-нод, расположенных в разных зонах доступности. Если одна из матер-нод перестанет работать, control plane не развалится. Этот вариант подходит для боевого продакшена, где важна отказоустойчивость, и для высоконагруженных проектов, где одна мастер-нода просто не справится с количеством пользовательского трафика. В целях экономии для тестовых сред и менее требовательных к надежности систем можно выбрать зональный тип — с одной мастер-нодой.

Группы нод

В Managed Kubernetes можно создавать разные группы нод кастомной конфигурации. Это позволяет не ограничивать себя в выборе. Можно создать ноду с 2 CPU и 8 ГБ оперативной памяти или запустить ноды с 24 CPU для высоконагруженного приложения. В одном кластере из панели управления можно создать до 4 групп нод и 60 нод — больше ресурсов можно получить через API. Также группы можно создать в разных зонах доступности, что повысит отказоустойчивость инфраструктуры.

Здесь же можно «разметить» ноды, чтобы ограничить либо, наоборот, рекомендовать запуск приложений на них. Делается это с помощью меток и тейнтов.

Сети

Если у вас есть иная инфраструктура в облаке — виртуальные серверы, базы данных, объектном хранилище — можно разместить кластер в единой подсети, чтобы связать с ними Kubernetes. Новая же подсеть создается по умолчанию.

Автоматизация

Managed Kubernetes предлагает три актуальных автоматизации, две из которых легко настроить на старте:

• Автомасштабирование. Эта функция позволит без участия клиента увеличивать количество нод в кластере, если нагрузка на инфраструктуру повышается и, наоборот, исключать малозагруженные ноды. Главное — обозначить диапазон количества нод в группе в панели управления.
• Автохилинг, или автоматическое восстановление нод. Если рабочая нода не отвечает в течение 15 минут, она будет переустановлена автоматически.
• Автообновление версий. Опция позволит вовремя переходить на новые патч-версии Kubernetes (с исправлением багов и мелкими доработками), не тратя время на самостоятельный апгрейд. Автообновление доступно лишь для региональных кластеров и происходит в указанное клиентом окно обслуживания — обычно это время, когда нагрузка на инфраструктуру минимальна.

Важно: Опцию лучше отключить, если ваши сервисы чувствительны к версии Kubernetes. Возможно, в вашем случае предпочтительнее обновляться контролируемо, тем более что самостоятельное обновление делается в один клик.

Хранение данных

К кластеру можно подключить дополнительный диск (Persistent Volume). В Kubernetes персистентный диск используется в качестве хранилища. Он может понадобиться, если в кластерах поднимается база данных, stateful-приложение и подобные системы. Persistent Volume интегрирован с системой хранения OpenStack, поэтому в кластерах можно использовать все четыре типа диска из облачной платформы Selectel.

Локальный диск выбирают для максимальной производительности — передача данных осуществляется без сетевых задержек. Однако стоит учесть, что в случае проблем перенос данных на другой сервер будет сильно затруднен или невозможен.

Для большей отказоустойчивости можно выбрать из трех видов сетевых дисков — быстрый (SSD-диск, 25 000/15 000 IOPS), универсальный (SSD-диск, 7 000/4 000 IOPS) и базовый (SATA-диск, 320/120 IOPS). Выбор зависит от требования конкретных приложений, размещаемых в кластерах. Подробнее о персистентых дисках — в базе знаний Selectel.

Также к кластеру Kubernetes можно подключить файловое хранилище на быстрых (25000/1500 IOPS) и универсальных (7000/400 IOPS) сетевых дисках. Так вы получите постоянное хранилище для нескольких подов с режимом доступа ReadWriteMany.

Наконец, к подам кластера можно монтировать контейнеры объектного хранилища — существующие или свежесозданные. Сделать это можно через Container Storage Interface.

Сейчас c Managed Kubernetes можно использовать готовый реестр контейнеров. Пользователю не нужно арендовать хост или дополнительное место на диске, чтобы самостоятельно организовывать подобную систему хранения. Трафик между облачной инфраструктурой и Container Registry не тарифицируется, а образы будут развертываться быстрее.

Протестируйте продукт →

Выше мы рассмотрели основные возможности Managed Kubernetes, доступные из панели управления, — этого достаточно для работы с приложениями в контейнерах. Также услуга поддерживает более сложные кастомизации, такие как контроллеры доступа, Feature Gates, Ingress-контроллер (балансировщик нагрузки для куба). Инструкции по работе с ними есть в документации Selectel.

Для начала компания должна запускать приложения в контейнерах или развивать микросервисную архитектуру. Сфера бизнеса — не принципиальна. Контейнеры актуальны как для больших высоконагруженных проектов, так и для небольших стартапов, которые смотрят в будущее и сразу развиваются в логике микросервисов. Впрочем, Kubernetes не панацея: вы можете развивать контейнеризированный сервис, но если он небольшой и ненагруженный, возможно, лучше запустить контейнеры в Docker и не заниматься овермозгом.

Подробнее про микросервисную архитектуру и монолит →

Managed Kubernetes полезен, когда сотрудникам компании не хватает опыта администрирования кластеров Kubernetes и навыков для поддержания работоспособной control plane.

Также PaaS-сервис актуален для тех, у кого нет времени для самостоятельного развертывания кластеров и их автоматизации.

Наконец, подойдет Managed Kubernetes и тем, кто хорошо знает Kubernetes, но хочет избавить себя от рутинных задач, связанных с настройкой и поддержкой кластеров.

Не подойдет услуга тем, кому нужен полный контроль и доступ ко всем уровням кластера Kubernetes.

Также сложно советовать сервис тем, кто хочет высокую степень кастомизации. Реализовать сложные и уникальные надстройки и автоматизации кластеров в managed-решении будет затруднительно. Если специалисты компании обладают навыками для подобных операций, они смогут развернуть Kubernetes самостоятельно. Это будет дольше, зато кластеры будут полностью интегрированы в инфраструктуру в необходимых компании сценариях.

Возможно, эти тексты тоже вас заинтересуют:

→ Антология ARM: какие перспективы у процессоров в серверном сегменте
→ Как мы автоматизировали тестирование OpenStack с помощью Rally и Tempest
→ Как улучшать продукты, опираясь на мнение пользователей, или загадка плавающего IP-адреса