Привет, Хабр! Меня зовут Нурсултан Калниязов, в Yandex Cloud я занимаюсь развитием Yandex Managed Service for Kubernetes® и других сервисов.
Наши пользователи нередко строят гибридные облака — когда часть вычислительных ресурсов остаётся «на земле», а часть из них переезжает в облако. Предпосылки могут быть связаны с требованиями регуляторов или финансовой составляющей, например, если в собственную инфраструктуру уже вложены значительные инвестиции. Компании также могут рассматривают гибридные сценарии как этап эволюции своей инфраструктуры — для постепенной миграции рабочих нагрузок в облака.
Это, в свою очередь, порождает технические челленджи, так как облачная и собственная инфраструктуры имеют совершенно разные механизмы управления, и компаниям, помимо этого, необходимо озаботиться вопросом связанности обеих инфраструктур. Поэтому задачей нашей команды в последние месяцы было упростить этот процесс.
Сегодня покажу, как обновления облачных платформ помогают решить эту задачу и как это работает в конкретных сценариях.
Как проблемы гибрида решаются в индустрии
Использование Kubernetes — подходящее решение для объединения инфрас��руктур, так как он предоставляет единые подходы как для облаков, так и для собственной инфраструктуры.
Провайдеры предлагают на этот случай разные возможности. Посмотрим на пример сервиса AWS Outposts, для которого есть несколько опций:
Local clusters, когда и Kubernetes control plane и ноды находятся в дата‑центре клиента «на земле».
Extended clusters, которая позволяет развернуть control plane у провайдера в регионе, а рабочие узлы держать у себя (в дата‑центре), где есть нагрузка.
Второй вариант позволяет не думать об автомасштабировании мастер‑нод, предиктивном или пороговом скейлинге, так как можно возложить эту ответственность на провайдера и забыть. А ещё это пригодится, когда есть высокие требования по задержкам — воркер‑ноды в таком случае можно держать на периферии.
В свою очередь в Google Cloud Platform есть Anthos — платформа, с помощью которой можно сделать то же самое.
Anthos — расширение традиционных GKE‑кластеров в GCP. Он закрывает гибридные и мультиоблачные сценарии. Можно управлять AWS‑ными EKS, Azure‑ными AKS и другими Kubernetes‑кластерами через единый интерфейс в GCP.
Гибридные сценарии бывают различными. Мы рассмотрели привычный для Outposts вариант, когда рабочая нагрузка находится в собственных дата‑центрах в закрытой среде, а control plane располагается у облачного провайдера.
Но может потребоваться и другой сценарий: нагрузка может находиться не в закрытом контуре, а являться частью облачной платформы, одним из его сервисов, где мы можем арендовать выделенные серверы и использовать их для своих нужд.
Получается отдельная ступень между облачной платформой и on‑premises.
При этом настоящей болью становится ситуация, когда пользователь берёт «ванильный» Kubernetes и пытается собрать «космолёт»: сам разбирается с CSI‑драйверами, автоматическим добавлением нод при высокой утилизации (см. Cluster Autoscaler), балансировщиками и так далее. А в облаках, как п��авило, все эти интеграции уже есть «из коробки».
Но когда у вас нет собственной инфраструктуры и по какой-либо причине вам необходимо использовать выделенный сервер, то первым выбором будут сервисы BareMetal.
Преодолеваем трудности связки BareMetal и Kubernetes
Когда в production‑окружениях рабочими узлами Kubernetes становятся выделенные (baremetal) серверы, а не виртуальные машины, это даёт несколько преимуществ:
Предсказуемая производительность.
Использование бóльших конфигураций, чем для обычных виртуальных машин.
Использование локальных дисков для запуска приложений, требовательных к производительности дисков (например, баз данных).
Стоимость. Железо без виртуализации стоит дешевле, чем облачные мощности. А на больших масштабах аренда выделенных серверов может значительно сэкономить бюджет. Помимо этого, существуют и дополнительные «расходы» на виртуализацию, что может ещё больше склонять выбор в сторону baremetal‑серверов.
В Managed Service for Kubernetes мы добавили поддержку гибридной конфигурации, позволяющей использовать выделенные серверы. Control plane остаётся в облаке Yandex Cloud, обеспечивая управляемость, а вычислительные ресурсы предоставляются выделенными серверами из сервиса BareMetal.
Схема может выглядеть следующим образом.
Выделенные серверы можно связывать с ресурсами в Yandex Cloud или с локальной (on‑premises) площадкой. Для этого используется сервис Cloud Interconnect, кот��рый обеспечивает сетевое соединение между всеми площадками.
VPC‑сегмент, on‑premise, BareMetal — для всех этих сегментов возможно обеспечить сетевую связность, за счёт Routing Instance.
Подключаем выделенные серверы к Managed Kubernetes
Теперь переходим к самой интересной части — как теперь выглядит пошаговое подключение BareMetal‑серверов к управляемому Kubernetes‑кластеру. Для этого мы создадим два сервера — с разными конфигурациями и версиями Ubuntu.
Помимо этого, покажем два способа подключения этих серверов к кластеру: автоматический и полуавтоматический. В процессе подключения этих внешних узлов по отношению к кластеру на них установятся системные компоненты Kubernetes.
Первый способ — автоматический. Для этого нужен уже готовый Managed Kubernetes‑кластер.
Подключаемся к кластеру.
Создаём секрет с приватным SSH‑ключом — он понадобится, чтобы появилась возможность установки системных компонентов на BareMetal‑сервер.
В консоли Kubernetes заходим в раздел управления узлами и создаём новую группу узлов — не облачную, а внешнюю
указываем приватный IP‑адрес нашего BareMetal‑сервера;
задаём имя группы узлов;
выбираем созданный SSH‑секрет.
Через несколько минут в консоли появится информация о том, что появилась новая группа узлов, а компонент maintainer завершил установку необходимых компонентов. BareMetal‑сервер успешно подключился к Kubernetes‑кластеру.
Теперь рассмотрим второй способ — полуавтоматическое подключение BareMetal‑сервера к Kubernetes‑кластеру.
Этот вариант нужен прежде всего, чтобы показать, какие есть альтернативы автоматической установке, а также может пригодиться, если нужно внести отдельные изменения в процесс подключения ноды к кластеру. Чаще мы рекомендуем автоматический способ, так как он проще и требует меньше ручных действий.
Создаём новую группу узлов для второго сервера, и подключаться будем к другому Kubernetes‑кластеру
После создания группы узлов Kubernetes автоматически генерирует секрет с настройками подключения. Из этого секрета нужно извлечь файл kubeconfig.
Переносим kubeconfig на наш Bare Metal‑сервер — с помощью scp, rsync или любой другой утилиты.
На сервере создаём директорию, где будет храниться конфигурация Maintainer‑а. Кладём туда файл kubeconfig.
Далее нужно скачать сам Maintainer, который отвечает за установку системных компонентов. Даём необходимые права на исполнение.
Запускаем Maintainer, и все необходимые системные компоненты устанавливаются на наш сервер
Когда установка завершится, в консоли Kubernetes можно увидеть, что новая группа узлов создана, а сервер успешно подключился. Таким образом, второй Bare Metal‑сервер мы подключили вручную, и результат получили тот же — он стал полноценным узлом Kubernetes.
В ближайшее время мы также добавим возможность заводить группу узлов BareMetal сразу из консоли сервиса Managed Kubernetes.
