28.05.2025 10:17
Andrey_Biryukov 0 2300 Источник

Kubernetes является мощным инструментом для оркестрации контейнеризированных приложений. Построение инфраструктурной платформы на основе K8s является очень нетривиальной задачей и в этой статье мы рассмотрим основные вопросы и проблемы, возникающие при разработке архитектуры платформы.

Стихийное появление

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

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

Не будем долго теоретизировать, а сразу рассмотрим небольшой пример. Представим, что команде разработчиков приложений нужна новая база данных для создаваемого сервиса, они не должны отвечать за подготовку и настройку этого экземпляра базы данных. Они должны сосредоточиться на исправлении ошибок и написании новых функций. До тех пор, пока у них не будет запущена эта база данных, они не смогут выполнять свои задачи, так как им необходимо взаимодействовать с этой базой данных.

Традиционно, эта команда должна была бы подать заявку в отдел инфраструктуры, чтобы подготовить (установить и настроить на нужном компьютере/виртуальной машине) базу данных.

Но так было раньше. Сейчас, в эпоху облачных технологий практически любой может создать новый экземпляр PostgreSQL или Redis в облаке менее чем за пять кликов, но для этого требуется, чтобы у команды была соответствующая учетная запись у облачного провайдера с надлежащим доступом. И давайте не будем обманывать себя, базы данных не существуют сами по себе, вам, вероятно, нужно обезопасить доступ к ним и управлять сертификатами, подготовить хранилище для размещения данных, настроить сетевые параметры, чтобы приложения и ваши разработчики могли получить к ним доступ, и давайте не будем забывать о политиках резервного копирования!

В результате если команда разработки по тем или иным причинам решит развернуть и как‑то сопровождать СУБД самостоятельно в том же облаке, они конечно смогут это сделать, но насколько это будет качественно. Так, в процессе эксплуатации этой СУБД потребуется выполнять рутинные административные задачи по назначению и (что еще важнее) отключению ненужных прав, настройке резервного копирования, масштабированию и многому другому.

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

Но вернемся к Kubernetes. Здесь также инфраструктурную платформу может начать создавать какое‑то одно подразделение, в результате чего в итоге она может получиться «перекошенной» и исправлять этот перекос потом будет очень непросто.

Таким образом, лучше избегать стихийного создания инфраструктурной платформы, так как это слишком важный элемент всей ИТ инфраструктуры, чтобы пускать его создание на самотек.

Платформы и ресурсы

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

Для создания и сопровождения инфраструктурной платформы в компании должна быть создана платформенная команда, специалисты которой будут хорошо разбираться в тех решениях, которые используются для ее работы и прежде всего в k8s.

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

Поговорим о том, как правильно разделять ресурсы между компонентами платформ, используемыми инструментами и приложениями. Хорошо, если ваша платформа будет предоставлять набор API и реализовывать пользовательское поведение, нам понадобится место (серверы) для запуска этих компонентов. Если мы собираемся автоматизировать какую‑то работу с помощью инструментов CI/CD, нам нужно ресурсы для установки и запуска этих инструментов. При этом важно понимать, что эти инструменты не могут работать с нашими приложениями на одних и тех же кластерах. Последнее, чего мы хотим, — это чтобы наши инструменты непрерывной интеграции (CI) боролись за ресурсы с нашими приложениями, обслуживающими запросы наших клиентов. По соображениям безопасности мы хотим гарантировать, что если в наших инструментах CI или средствах автоматизации будут обнаружены уязвимости, наши приложения не будут удалены в результате атаки на эти инструменты, которые непосредственно не используются нашими приложениями.

Когда мы переводим эту задачу на кластеры Kubernetes, становится ясно, что если у нас будут инструменты для всей платформы и отдельные среды, то один кластер Kubernetes не справится с этой задачей.

Чтобы обеспечить достаточную изоляцию между инструментами платформы и средами, в которых будет запускаться приложение, нам необходимо иметь возможность запускать многокластерную настройку. По сути, для выполнения каждой из представленных на рисунке задач, будь то функционирование самих компонентов платформы, стейджинга, сред разработки и продуктива, нам необходимо развернуть отдельный кластер.

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

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

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

Для того, чтобы иметь возможность в принципе реализовать подобный функционал нужно изначально выбрать правильные инструменты для реализации. Так, облачный провайдер должен поддерживать возможность создания кластера с помощью запросов к API. В случае, если используется собственная инфраструктура, то необходимо использовать решения на основе инфраструктуры как код (IaC) для того, чтобы быстро разворачивать новые кластеры. Кроме того, задача создания нового кластера должна быть максимально автоматизирована и запускаться с помощью конвейера, например Jenkins или GitLab.

В целом задача создания кластера k8s по требованию хотя и является достаточно сложной, но при наличии необходимых ресурсов и знаний она выполнима.

Динамическая настройка нескольких кластеров в облаках

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

Давайте предположим, что команда разработчиков платформы имеет свой собственный кластер Kubernetes для размещения всех компонентов, связанных с платформой. Также мы предположим, что производственная среда размещена в облачном провайдере A и также является кластером Kubernetes. Компания использует облачного провайдера B для размещения сред разработки, в которых команды разработчиков приложений могут экспериментировать и создавать новые функции. Сейчас мы имеем дело с мультиоблачной и мультикластерной системой, которая требует обслуживания, управления затратами и должна быть достаточно гибкой, чтобы эти различные команды могли эффективно выполнять свою работу.

Каждый облачный провайдер предоставляет нам доступ к своим API‑интерфейсам для создания облачных ресурсов, и для подключения к этим API‑интерфейсам кластеру платформы необходимо обеспечить их доступность, чтобы платформа могла автоматически создавать ресурсы, управлять ими и удалять их, когда это необходимо.

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

Так или иначе, но при создании платформы нам необходимо ответить на несколько вопросов, связанных с непрерывной интеграцией и непрерывным развертыванием. Так, для обеспечения непрерывной интеграции нам необходимо понимать, как и где мы будем создавать, тестировать и упаковывать свои приложения. То есть в каких облачных компонентах будут выполняться данные задачи и какие для этого потребуются ресурсы.

Аналогично с непрерывным развертыванием. Мы должны знать, какие компоненты отвечают за развертывание новых версий наших приложений, когда они будут готовы. Какие стратегии выпуска (синий/зеленый, флаги функций, канареечный релиз, A/B‑тестирование) мы будем использовать и какие компоненты платформы будут в этом участвовать.

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

Преимущество использования Kubernetes в качестве основы для управления нашими вычислительными ресурсами заключается в том, что оно обеспечивает четкое разделение задач между инфраструктурой (компьютерами, виртуальными машинами и облачными провайдерами) и их потребителями, которые могут полагаться на API‑интерфейсы Kubernetes для настройки рабочих нагрузок и, в этих случаях, инструментов и компонентов, которые будут работать на платформе.

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

Заключение

Подведем итоги тому, что мы рассмотрели в этой статье. Наша инфраструктурная платформа построена на базе нескольких кластеров Kubernetes и мы имеем возможность создавать новые кластеры по требованию, когда они понадобятся командам. Также в этих кластерах развернуты сервисы необходимые для работы компонентов кластера и обеспечения процессов CI/CD. Таким образом, теперь платформа будет отвечать не только за подготовку новых кластеров Kubernetes, но и за установку на них инструментов и их настройку для любого назначения этих кластеров.

В условиях, когда Kubernetes становится фундаментом современных инфраструктур, понимание тонкостей сетевого взаимодействия и безопасного управления данными выходит на первый план. Для тех, кто хочет углубить свои знания и получить практические инструменты для решения повседневных задач, рекомендуем открытые уроки, которые пройдут в рамках онлайн-курса «Инфраструктурная платформа на основе Kubernetes»:

Хотите понять, насколько вы разбираетесь в K8s? Пройдите вступительное тестирование — это поможет оценить уровень и понять, подойдёт ли вам курс.

Комментарии (0)