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

Мы хотим помочь разработчикам перейти от управления задачами непрерывной интеграции к самостоятельному применению ресурсов, с использованием модульного подхода к каталогизации GitOps через Argo CD.

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

• Разбиваете свою платформу на многоразовые строительные блоки

• Проектируете слои, абстрагирующие сложность

• Максимально автоматизируете развертывание и валидацию

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

Модульное строительство

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

Мы разделяем стек на три компонуемых уровня:

• Уровень 1 — Инфраструктура: Инструменты, Terraform или Crossplane, используются для предоставления инфраструктуры, такой как управляемые кластеры Kubernetes и базы данных. Это ваши фундаментальные строительные блоки.

• Уровень 2 — Сервисы платформы: После создания инфраструктуры вы используете Helm Charts для развертывания инструментов, таких как Cert-Manager, Ingress-NGINX или External-DNS, — все они необходимы для работы платформы.

• Уровень 3 — Приложения: Наконец, разработчики создают и развертывают свои собственные приложения с помощью инструментов, таких как Kustomize, Timoni или Helm, управляя конфигурациями сервисов понятным и многоразовым способом.
  «Первый этаж» здесь — ваш облачный провайдер или API платформы, который предоставляет ресурсы по требованию.

Планирование и моделирование

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

Постоянно доступные API

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

Kubernetes или облачные API всегда доступны или по крайней мере, должны быть. Соблюдение SLA по времени безотказной работы — ключевая обязанность команды платформы.

Используя модули Terraform, диаграммы Helm или повторно используемые CRD, вы применяете проверенные, воспроизводимые шаблоны, которые ускоряют доставку и сокращают количество ошибок.

Ресурсы облачного масштабирования

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

Из всех принципов, модульное строительство является особенно мощным. В терминах платформы мы называем это композицией. Хотя термин «композиция» пока не стал общепринятым в платформенной среде, он более интуитивно понятен, чем «абстракция», для того, что мы делаем — разумного объединения ресурсов.

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

Понимание трёх уровней компоновки в проектировании платформы

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

Уровень компоновки 1 — Инфраструктура как код

Это фундаментальный уровень, сравнимый с бетонным основанием и стальным каркасом небоскреба. В большинстве случаев мы используем модули Terraform для объединения и предоставления компонентов облачной инфраструктуры, таких как:
• Управляемые кластеры Kubernetes
• Сетевые компоненты
• Базы данных и хранилища
• и т. д.

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

Для ещё б��льшей гибкости Terraform можно комбинировать с Crossplane или kro.run, что позволяет определять инфраструктуру как собственные CRD-файлы Kubernetes. Таким образом, можно декларативно запрашивать ресурсы (например, кластер) с помощью простого YAML-файла.

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

Уровень 2 — Сервисы платформы

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

Сюда входят такие инструменты, как:
• Cert-Manager для автоматизации TLS
• Ingress-NGINX для маршрутизации трафика
• External-DNS для управления доменами
• External Secrets Operator (ESO) для управления секретами
• и т. д.

Эти инструменты часто упаковываются с помощью Helm Charts, которые абстрагируют множество задействованных объектов Kubernetes (например, Deployments, ConfigMap, ClusterRoles и т. д.) и предоставляют только необходимую конфигурацию.

Этот уровень отвечает за упаковку и шаблонизацию, упрощая единообразное развертывание сложных сервисов. Даже операторы баз данных, например CloudNativePG, часто устанавливаются таким образом. Хотя оператор может заботиться о внутренней структуре базы данных, установка по-прежнему зависит от Helm или Kustomize. Команда платформы под��ерживает эти пакеты для обеспечения согласованности, безопасности и применения политик.

Уровень 3 — Разработка приложений

Теперь мы переходим к самому изменчивому и сложному уровню — развертыванию приложений. Здесь разработчики создают собственные сервисы, используя Helm, Kustomize, ytt, timoni или даже декларативные API на базе Crossplane v2 или kro.run.

Здесь абстракция имеет первостепенное значение. Почему? Потому что теперь разработчики отвечают за:
• Понимание структуры манифеста Kubernetes
• Написание и поддержку файлов конфигурации
• Интеграцию изменений в конвейеры непрерывной интеграции
• Управление версиями (например, тегами изображений)
• Управление операциями второго дня
• И, конечно же, соблюдение всех требований ://

Давайте разберёмся, что на самом деле означает «простое веб-приложение».

Даже для простого приложения требуется несколько файлов YAML, определений сервисов, настроек автомасштабирования, контекстов безопасности и логики непрерывной интеграции (поскольку в нашем случае CD будет реализован в Argo CD).

Разработчикам необходимо:

• Знать правильную конфигурацию SecurityContext, чтобы избежать проблем безопасности;

• Корректно настроить запросы/ограничения ресурсов для включения HPA;

• Понимать, что сервер метрик не всегда развёрнут (особенно на периферийных кластерах);

• Учитывать особенности Helm или Kustomize при попытке динамической передачи значений. Всё это происходит на фоне разработки, тестирования и поддержки самого приложения.

И все-таки Kubernetes

Да, инструменты GitOps, такие как Argo CD, упрощают развёртывание. Но для этого разработчикам часто требуется выполнить слишком много работы с YAML и нужно понимание платформы — а у многих нет специальной подготовки. Итак, возникает естественный вопрос…

Неужели Kubernetes — неподходящая абстракция для разработчиков?

Некоторые скажут «да». Именно поэтому появились альтернативы, такие как Heroku, Choreo, CloudFoundry или многообещающий новичок ConfigHub, предлагающие разработчикам абстракции более высокого уровня.
Эти инструменты снижают нагрузку, позволяя разработчикам сосредоточиться на коде, а не на инфраструктуре.

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

Чтобы упростить жизнь разработчиков и снизить нагрузку, команды разработчиков платформы могут предварительно создавать шаблоны приложений, используя те же принципы Compose. Такие инструменты, как:
• Score
• kro.run
• Crossplane v2
• Kratix
• Helm
• …..
…могут использоваться для определения повторно используемых шаблонов для приложений. Эти шаблоны объединяют всё необходимое приложению: службы, развертывание, HPA, Ingress, RBAC и безопасные значения по умолчанию.

Затем вы можете представить эти шаблоны как:
• Helm Charts
• Определения пользовательских ресурсов (CRD), такие как WebAppOnEdge или WebAppOnCloud… как бы вы их ни называли!

После установки CRD в целевой кластер разработчика ему остаётся только создать WebApp CustomResource. Всё остальное — от запросов ресурсов до правил автоматического масштабирования — предварительно настраивается командой платформы. Это обеспечивает настоящее самообслуживание с минимальной когнитивной нагрузкой на разработчика.

Такой подход к компонуемой платформе хорошо работает, когда Kubernetes перестаёт быть просто «кластером» и становится опорой для всего жизненного цикла продукта. Если хочется собрать это воедино — от экосистемы и IaC до эксплуатации своих кластеров — в OTUS есть профильный курс по инфраструктурной платформе на базе Kubernetes, который как раз готовит к роли платформенного инженера.

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

Чтобы узнать больше о формате обучения и познакомиться с преподавателями, приходите на бесплатные демо-уроки:

• 3 декабря: Custom Resource Definitions (CRD) в Kubernetes. Операторы: автоматизация на новом уровне. Записаться

• 17 декабря: Инструменты и механизмы Kubernetes для обеспечения высокой нагрузки. Записаться

• 23 декабря: GitOps + Flux: стабильный деплой в Kubernetes без ручного вмешательства. Записаться