Кластеры в гибридных средах — это иллюзия?
Для сценариев Kubernetes многих организаций желательна гибридная облачная архитектура: это сочетание общедоступного облака и необлачной инфраструктуры в едином кластере на несколько сред. Вместо отдельных кластеров имеется единая плоскость управления. В одной среде она запускается, в других ею управляются узлы.
Какие в связи с этим открываются возможности?
Оптимальное использование специализированных локальных ресурсов
Приложения, которым нужна обработка с низкой задержкой вблизи источников данных или требуются специальные аппаратные конфигурации, доступные только локально (например, ИИ/машинное обучение), теперь легко координируются в одной плоскости управления, которой контролируются облачные рабочие нагрузки.
Зачем выделять ценное локальное оборудование для управления кластерами и связующего ПО? Перенесите эту работу в облако и выделите все ресурсы своих дата-центров на рабочие нагрузки приложений.
Выход в облако при пиковых рабочих нагрузках
Гибридные архитектуры — эффективный путь выхода в облако, где для обуздания пиков локальные приложения временно масштабируются. Приложения, которые сталкиваются с колебаниями рабочих нагрузок или пиковым трафиком в конкретное время, благодаря выходу в облако динамически масштабируются гибридными кластерами без выделения дополнительных локальных ресурсов.
С такой эластичностью организациям становится экономичнее и гибче управлять востребованными рабочими нагрузками, обеспечивая доступность ресурсов по мере необходимости и избавляясь от избыточного их выделения в локальной среде.
Межсайтовое аварийное восстановление
При гибридной архитектуре все периферийные площадки регистрируются в одной плоскости управления. Если одна из площадок «падает», рабочие нагрузки легко переносятся планировщиком Kubernetes на другую, так предоставляется возможность аварийного восстановления.
Гибридным характером кластера вкупе с единой плоскостью управления обеспечивается повышенная мобильность рабочих нагрузок, недоступная в стандартных кластерах Kubernetes, все узлы которых расположены на одной физической площадке.
Снижение накладных расходов и сложности
При управлении Kubernetes в различных средах традиционно требуются отдельные кластеры и инструментарии для локальных, периферийных и облачных развертываний. Такая фрагментация чревата разрозненностью инфраструктуры, несогласованностью политик, увеличением накладных расходов.
С гибридной, связной архитектурой больше не требуется для каждой периферийной площадки держать плоскость управления: локальные узлы управляются теми же инструментами и процессами, что и облачные ресурсы.
Согласованная безопасность и наблюдаемость
Гибридными архитектурами в локальных и облачных средах обеспечивается согласованная модель безопасности с пониженным риском возникновения слабых мест — особенно в регулируемых сферах, где требуется строгий контроль доступа и соблюдение требований по хранению данных. Благодаря интегрированной наблюдаемости упрощаются мониторинг и логирование в гибридных средах, так что команды отслеживают производительность приложений и выявляют проблемы в локальных и облачных развертываниях согласованно. А с централизованным мониторингом в организациях получают полное представление о гибридных кластерах, быстрее устраняют неполадки, сокращают простои.
Почему же не все это делают?
Гибридные модели развертывания особенно ценятся в периферийных вычислениях и телекоммуникациях (здесь важна локальная обработка, но необходимость централизованного управления и масштабируемости диктуются масштабом), а еще в финансовых услугах, машинном обучении и потоковых мультимедиа. Рабочим нагрузкам, чувствительным к задержкам, требуется специальное оборудование или рабочие нагрузки связаны строгими правилами управления данными — и те, и другие находятся с облачными приложениями под одним рабочим зонтом безопасности и инструментария и подключены к ним.
Имеется лишь один недостаток. Растягивание кластеров Kubernetes между общедоступным облаком и частными сетями, включая дата-центры и периферийные площадки, до сих пор было невероятно сложной задачей.
С гибридными узлами EKS мечта становится реальностью
Благодаря новинке AWS — гибридным узлам EKS — клиенты используют локальную и периферийную инфраструктуры как рабочие узлы в кластерах EKS. Гибридные узлы — это «пустые» и/или виртуализированные хост-машины, выполняемые вне AWS и регистрируемые в централизованной плоскости управления EKS как рабочие узлы, в результате чего получается единый кластер EKS, который простирается на облако Amazon и минимум одну частную площадку.
Гибридные узлы разделяются многочисленными площадками, каждой из которых используется отдельная частная сеть. Узлы одной гибридной площадки называются единым пулом гибридных узлов.
Плоскость управления Kubernetes размещается и управляется на AWS, благодаря чему минимизируются практические действия, необходимые для запуска гибридных приложений Kubernetes, и для рабочих нагрузок приложений резервируется ценное локальное оборудование.
Ингредиенты для первого гибридного кластера
Для полного понимания гибридных кластеров, их конфигурации и возможностей разберем концепции, немного отличные от тех, что имеются в традиционном кластере EKS, особенно это касается сетевых требований.
Настройка кластера EKS
Пользователи создают кластеры с поддержкой гибридных узлов, используя интерфейс командной строки AWS, шаблоны CloudFormation или eksctl.
При развертывании гибридного кластера EKS требуется два дополнительных компонента метаданных — сети удаленных узлов и сети удаленных подов. Оба они определены как списки бесклассовой междоменной маршрутизации CIDR с разделением запятыми для гибридных узлов и их подов соответственно. Поэтому перед развертыванием необходимо ознакомиться с сетевой топологией каждой гибридной площадки.
Аутентификация
Для безопасной аутентификации с плоскостью управления EKS гибридными узлами используются AWS IAM Roles Anywhere либо AWS Systems Manager.
Запускаемым на гибридном узле kubelet в обоих случаях присваивается и используется роль IAM, предварительно регистрируемая с кластером EKS. Роль IAM регистрируется, как обычно с EKS: редактированием aws-auth ConfigMap.
Сети и подключение
Наибольшая сложность гибридных узлов заключается в сетях.
Между локальной инфраструктурой и виртуальным частным облаком VPC AWS кластера EKS требуется подключение L3. Оно осуществляется такими решениями, как межсайтовая VPN в AWS и AWS Direct Connect.
Плагин CNI виртуального частного облака кластера EKS гибридными узлами не поддерживается, но используется в работе с сетью для облачных рабочих узлов. Для гибридных узлов рекомендуются альтернативные плагины CNI вроде Calico или Cilium, которыми обеспечиваются управление IP-адресами и дополнительная конфигурация BGP для узлов за пределами AWS.
Какой бы ни был выбран плагин CNI, его DaemonSet обязательно обновляется правилами совместного существования, предназначенными только для гибридных узлов. С этой целью к каждому гибридному узлу автоматически применяется метка eks.amazonaws.com/compute-type: hybrid.
Гибридными узлами используется IPv4-адресация, им требуются маршруты между VPC кластера EKS и локальными сетями. Для решений с архитектурой VPN на каждый пул гибридных узлов рекомендуется иметь выделенный VPN-сервер.
Задача пользователя — обеспечить наличие маршрута в таблице маршрутов VPC кластера EKS, в которой предназначенный для каждого пула гибридных узлов и CIDR пода трафик сопоставляется с VPN-сервером этого пула или, если используется Direct Connect, с корректной CIDR частной подсети.
Каждое VPN-соединение в AWS должно иметь два статических маршрута, связанных с его пулом гибридных узлов:
- узловая CIDR гибридных узлов в пуле;
- подовая CIDR подов, запускаемых на гибридных узлах.
Если для виртуального частного шлюза и/или транспортного шлюза включено распространение маршрутов, эти маршруты добавятся в таблицу маршрутов VPC согласно этим способам создания маршрутов.
Конфигурация локального VPN-сервера
В идеале у каждого пула гибридных узлов должен быть выделенный VPN-сервер. Этими серверами завершается локальная часть межсайтового VPN-туннеля между облаком AWS и частной сетью, которой оперируют на каждой гибридной площадке. У каждого VPN-сервера два туннеля ipsec P1, в каждом из которых сконфигурировано два P2:
- Подсеть гибридного узла → EKS VPC CIDR.
- CIDR пода гибридного узла → EKS VPC CIDR.
API-сервер EKS должен напрямую подключаться к любому IP-адресу в CIDR удаленных подов, указанному во время установки. Вот два конкретных примера использования этого сетевого пути: 1) запросы логов пода, инициируемые через kubectl, и 2) вебхуки, запускаемые в гибридных узлах.
По маршрутам, указанным в таблице маршрутов VPC в EKS, трафик отправится в частную сеть через VPN-туннель соответствующего пула гибридных узлов. Поэтому любые локальные VPN-серверы конфигурируются на отправку запросов в конкретные узлы в зависимости от того, к какому фрагменту общей CIDR относится IP-адрес назначения пакета. Это автоматизируется, если сконфигурировать Cilium на работу в режиме BGP и создать BGPPeeringPolicy. Или же статические маршруты для CIDR конкретного пода каждого узла настраиваются на VPN-сервере вручную.
Если VPN-сервер не является основным маршрутизатором сети, его конфигурируют на широковещательные маршруты через BGP в остальную сеть либо статические маршруты основного маршрутизатора конфигурируют на перенаправление трафика с EKS VPC CIDR на VPN-сервер. Статические маршруты для CIDR пода гибридных узлов тоже конфигурируют на основном маршрутизаторе, если BGP не сконфигурирован на VPN-сервере.
Настройка гибридного узла и присоединение его к кластеру EKS
В AWS операции жизненного цикла гибридных узлов: установки, конфигурирования, регистрация, обновления — выполняются инструментом CLI nodeadm.
Поддерживаемые версии Kubernetes: с 1.26 по 1.30, а операционные системы узлов: Amazon Linux 2023, Ubuntu 20.04, 22.04 и 24.04, а также RHEL 8 и 9.
Вот примерный процесс подготовки:
После инициализации nodeadm в кластере EKS появляется новый рабочий узел, который подготовится, как только в нем окажется агент CNI.
Решающий момент
Итак, мы настроили гибридный кластер, ознакомились с сетевыми требованиями и подключили к нему первый гибридный узел.
Прежде чем переводить это на продакшен, нужно подумать о:
- Инфраструктуре начальной загрузки для регистрации. Гибридными узлами EKS используется подход создания собственной инфраструктуры, при котором подготавливаются и управляются серверы без программного обеспечения внутри или виртуальные машины, предназначенные для использования в качестве гибридных узлов. Нужно включить nodeadm в образы операционной системы и, как-то раздобыв конфигурационные файлы узлов, автоматизировать его выполнение. Как согласованно и безопасно повторять процесс регистрации?
- Организации комплексного управления жизненным циклом гибридных узлов. С первого дня все остается на вас. Как организовывать выкатывания, постоянные обновления для гибридных узлов или управлять ротацией ресурсов PKI, используемых в IAM Roles Anywhere?
Ответами на эти вопросы занимаются партнеры по инфраструктуре, такие как Spectro Cloud. Мы воспользовались приглашением поучаствовать в бета-программе EKS Hybrid Nodes, дополнив и расширив основной функционал гибридных узлов нашим Palette.
Многократной автоматизацией жизненного цикла инфраструктуры упрощается процесс начальной загрузки гибридных узлов и управления гибридными кластерами EKS в условиях масштабирования, благодаря чему организациями быстро реализуются преимущества гибридных архитектур.
Palette и EKS Hybrid: шаг за шагом
Чтобы с легкостью управлять комплексным жизненным циклом пулов гибридных узлов, поэтапно импортируем гибридный кластер EKS в Palette и воспользуемся периферийными возможностями Kubernetes:
- Импортируем гибридный кластер EKS в Palette.
- Активируем гибридный режим и предоставляем в гибридные узлы кластера данные аутентификации.
- Подготавливаем один или несколько периферийных хостов.
- Определяем профиль кластера гибридных узлов.
- Используя периферийные хосты, создаем пул гибридных узлов для кластера EKS.
Этап 1. Импортирование гибридного кластера EKS в Palette
Для импорта гибридного кластера EKS в Palette применяется единый манифест, получаемый через API или пользовательский интерфейс Palette. Кластеры тоже автоматически импортируются интерфейсом командной строки Palette:
Этап 2. Активация гибридного режима кластера
После импорта переходим к гибридной конфигурации в настройках кластера, где активируем гибридный режим и указываем учетные данные для выбранной службы аутентификации:
Этап 3. Подготовка локальных хостов
Теперь, используя локальную инфраструктуру, подготовим периферийные хосты. Это машины с созданным при помощи рабочего процесса EdgeForge ISO-установщиком. В него включено все — от мощных серверов для дата-центров до компактных периферийных устройств. ISO-установщик настраивается под различные, специфичные для площадок сетевые и аппаратные конфигурации и переиспользуется для каждого гибридного узла этой площадки.
Как только машины из ISO-установщика загружены, установка завершается и они выключаются. После этого установочный носитель извлекается, выполняется перезагрузка. В этот момент устройство с Palette регистрируется периферийным агентом Spectro Cloud и готово добавиться в пул гибридных узлов:
Этап 4. Определение профиля кластера для гибридных узлов
Мы создадим пул гибридных узлов, но сначала для кодирования желаемого состояния гибридного узла определим профиль кластера. В противоположность ручной настройке одного за другим каждого узла, профили кластера Palette — это многоразовые макеты для декларативного конфигурирования кластера Kubernetes: от операционной системы узлов до дистрибутива Kubernetes и расширений.
В профиле гибридного кластера выделяется три уровня: операционная система, Kubernetes, сеть:
- В уровень ОС включается ссылка на собранный по ходу рабочего процесса EdgeForge образ от поставщика, а также любые дополнительные настройки, указываемые синтаксисом cloud-init.
- На уровне Kubernetes выбирается версия EKS-D kubelet, которая будет подготовлена в узле при помощи nodeadm.
- В случае гибридных узлов уровень сети — это всего лишь заполнитель, поскольку сетевыми операциями каждого гибридного узла занимается сам CNI, развернутый в кластере EKS.
Этап 5. Создание пула узлов
Теперь добавим в кластер EKS новый пул гибридных узлов: выбираем название, профиль кластера, а также один или несколько периферийных хостов, каждому из которых дополнительно присваивается пользовательский IP-адрес VPN-сервера.
По умолчанию предполагается, что сеть «поймет», как через VPN-сервер направлять предназначенные для VPC CIDR кластера EKS запросы. В противном случае IP-адрес VPN-сервера для каждого хоста указывается вручную, так что статический маршрут сконфигурируется на хосте периферийным агентом Spectro Cloud при создании кластера:
Окно для операций над гибридными узлами
Создав один или несколько пулов гибридных узлов, получаем встроенную поддержку операций: добавления и удаления узлов, обновлений версий и даже расширенной конфигурации на уровне ОС при помощи настроек уровня ОС в профиле кластера пула узлов.
Работоспособность, статус каждого пула гибридных узлов и доступность обновлений отображаются в едином окне, в целях мониторинга и отладки для каждого пула также предусмотрен специальный поток событий:
Гибридными узлами, собранными в пул, конфигурация которого связана с конкретной площадкой, легко управлять в условиях масштабирования.
Если профиль кластера, используемый пулом гибридных узлов, обновлен, например из-за повышения версии Kubernetes, пул узлов немедленно становится доступным для rolling repave, т. е. распространенной в Kubernetes практики, применяемой для развертывания узлов с последней версией ОС и Kubernetes. Как только запускается этот repave, каждым узлом в кластере загружается образ от поставщика, где содержатся последние обновления, и осуществляется контролируемая перезагрузка, в ходе которой применяются любые настройки на уровне ОС.
Что, если у вас несколько гибридных кластеров EKS, другие кластеры EKS или кластеры в других облаках, в локальных и периферийных средах? Palette — место для управления всеми ими в условиях масштабирования.
Заключительные слова и дальнейшие шаги
В Spectro ценят ваш выбор. Где бы ни использовались кластеры и какая бы архитектура ни была оптимальной для ваших задач, мы все это поддерживаем. Запуском гибридных узлов EKS в AWS открывается настоящее гибридное облако, расширенная кластерная модель для Kubernetes — совершенно новый инструмент в вашем арсенале как команды облачной платформы.
Мы рассказали, как оптимальнее сочетать гибридные узлы EKS и Palette, упрощая процесс начальной загрузки локальных устройств и управляя жизненным циклом узлов на уровне организаций.
Что дальше? Узнать о запуске гибридных узлов на re:Invent и ознакомиться с рекомендациями по EKS, зайти на страницу решений AWS, заказать демоверсию и поэкспериментировать с сервисом EKS Quickstart.
Читайте также:
- Руководство по Docker. Часть 3: Amazon Web Services, Travis CI и Elastic Beanstalk
- Как запустить и использовать файловые системы с помощью Amazon FSx
- OutSystems: взаимодействие в реальном времени
Читайте нас в Telegram, VK и Дзен
Перевод статьи Tyler: Bringing Amazon EKS Hybrid Nodes to life with Palette
