Разработка платформ набирает обороты во всех отраслях, поскольку организации сталкиваются со сложностью разработки в облаке. Команды хотят оптимизировать подготовку, развертывание и наблюдение, одновременно снижая нагрузку на разработчиков приложений. Тем не менее, многие считают, что выход за рамки минимально жизнеспособной платформы (MVP) требует изменения подхода.
В этом тематическом исследовании рассматривается, как Cover Whale, американская фирма, специализирующаяся на страховании грузовых автомобилей, создала свою внутреннюю платформу разработки (IDP) на Kubernetes и AWS, проблемы, с которыми она столкнулась при выходе за рамки MVP, и уроки, извлеченные на этом пути. От управления обширными диаграммами Хелма до интеграции таких систем, как NATS, этот путь иллюстрирует компромиссы, с которыми сталкиваются многие предприятия при расширении своей платформы.
В этой истории также показано, как инструменты оркестрации платформы, такие как Kratix, обеспечивают золотую середину между написанием пользовательских операторов и объединением сценариев, а также то, что это означает для долгосрочной удобства сопровождения.
Инициатива по разработке платформ
Недавно Cover Whale запустила новую страховую платформу для улучшения качества обслуживания клиентов. Чтобы упростить жизненный цикл приложений новой платформы, был реализован IDP для управления подготовкой, сборкой, тестированием, развертыванием и наблюдением каждой новой рабочей нагрузки микросервиса.
IDP построен на базе AWS Elastic Kubernetes Service (EKS), который управляет кластером платформы Kubernetes, управляющим группой кластеров Kubernetes рабочей нагрузки.
Все кластеры и базовая инфраструктура предоставляются OpenTofu и Terramate и загружаются с помощью Argo CD с использованием шаблона App of Apps.
Загрузка кластера выполняется путем инициализации кластера с помощью общих инструментов, таких как Karpenter, внешний DNS, оператор внешнего секрета и входящий контроллер. Затем он развертывает приложение для каждой системы в IDP, который, в свою очередь, развертывает другое приложение для каждой рабочей нагрузки внутри этой системы. Вся эта хореография инкапсулирована в серию диаграмм Helm, загружаемых с помощью Argo CD в кластеры.
Возникшие проблемы
Такая установка позволила быстро и эффективно разработать минимально жизнеспособный продукт.
Развертывание и поддержка всей иерархии рабочих нагрузок при одновременном устранении сложности создания манифестов Kubernetes и конвейеров сборки изменили правила игры и доказали ценность этой инициативы как для разработчиков, так и для руководства.
Тем не менее, выход за рамки MVP потребовал от нас пересмотреть наш подход по нескольким причинам, о которых мы подробно расскажем ниже.
Масштабируемость
Argo CD не предлагает большого выбора для создания манифестов Kubernetes. В результате мы использовали диаграммы Хелма… их много. Что еще хуже, структура Helm повторяла структуру систем и рабочих нагрузок IDP и имела отдельные диаграммы для того, что было развернуто в кластере платформы или кластере рабочих нагрузок.
Следствием этого является то, что ресурсы для конкретной задачи будут распределены по нескольким диаграммам Хелма. По мере роста IDP это привело к очень сложной кодовой базе с соответствующей логикой, распределенной по нескольким диаграммам.
Например, интеграция внешней секретности была разбросана по трем различным диаграммам Хелма.
В результате переход к более масштабируемой системе потребовал смены парадигмы.
Ограниченная интеграция с ресурсами, не относящимися к Kubernetes
MVP опирался на несколько взаимодействий с ресурсами, не относящимися к Kubernetes. Например, мы создаем репозитории Elastic Container Registry (ECR) и соответствующие роли управления идентификацией и доступом (IAM) с помощью контроллеров AWS для Kubernetes.
Однако, поскольку наши рабочие нагрузки основаны на системе обмена сообщениями NATS и Synadia Cloud, динамическое создание пользователей NATS было более чем желательным, и для этого нет оператора. Мы могли бы использовать хуки Helm, но это казалось ненадежным, а написание полноценного оператора казалось более сложной задачей, чем нам хотелось в то время.
Интеграция бэкэнд-фронтенда
Мы использовали Port.io в качестве портала для разработчиков, чтобы предоставить разработчикам единый интерфейс и улучшить наш опыт разработки (DX). На портале представлен обзор развернутых рабочих нагрузок, действия самообслуживания, которые разработчики могут использовать для управления своими рабочими нагрузками, а также ссылки на инструменты наблюдения и репозитории git.
Чтобы точно представить наши системы и структуру рабочей нагрузки на портале, мы использовали метки и аннотации к приложениям Argo CD и набору приложений, представляющим системы. Несмотря на свою функциональность, эта установка была несколько беспорядочной.
Например, система состоит из нескольких приложений и набора приложений. Это привело к некоторой путанице, когда нам пришлось добавить во внешний интерфейс информацию о том, где нужно добавить метки/аннотации.
В идеале нам хотелось бы иметь представление пользовательского определения ресурса (CRD) структуры IDP, которое Port.io мог бы однозначно прочитать. Однако сохранение этих CRD исключительно для этой цели кажется переоцененным.
С другой стороны, использование этих CRD для стимулирования IDP и уменьшения нашей зависимости от диаграмм Helm имело большой смысл!
Представляем Kratix в нашем IDP
Kratix предложил приятную золотую середину между написанием собственного оператора и подключением некоторых скриптов для решения упомянутых выше проблем.
Kratix отслеживает состояние наших ресурсов и позволяет проводить периодические сверки, избавляя нас от специальной рабочей нагрузки по наблюдению за kube-apiserver и в то же время позволяя нам управлять всем жизненным циклом наших ресурсов.
Используя подход обещаний, мы также могли бы собрать вместе конкретные проблемы, не беспокоясь об иерархии ВПЛ.
Доказательство концепции
Во время разработки новой платформы нам пришлось агрегировать API из нескольких сервисов и последовательно предоставлять их внешнему миру, создавая таким образом хороший уровень абстракции между внешними и внутренними сервисами. Сюда вошли API как старых, так и новых клиентских порталов, а также веб-перехватчики для различных внешних сервисов.
Мы решили добавить поддержку этого в наш манифест рабочей нагрузки, что позволит разработчикам управлять своими API распределенным образом и позволить IDP объединять все API под одним доменным именем.
Для этого мы создали два обещания Kratix:
- ApiAggregator, который объявляет имя хоста, которому доступны API.
- ApiAggregatorTarget, который присоединяется к ApiAggregator и определяет список путей и целевую службу, к которой следует отправлять запросы.
За кулисами Kratix создавал все ресурсы API шлюза, чтобы волшебство произошло.
Мы использовали ytt для генерации манифестов внутри нашего конвейера обещаний, что упростило процесс создания шаблонов YAML и позволило избежать всех особенностей YAML, чтобы в результате гарантировать действительный объект YAML.
Поскольку Argo CD уже был на карте, развернуть Kratix было довольно легко. Мы только что создали выделенный репозиторий git для хранилища состояний и добавили кластеры рабочей нагрузки в качестве места назначения в рамках процесса загрузки кластера.
В кратчайшие сроки у нас было рабочее доказательство концепции, и после небольшого исправления для поддержки больших размеров запросов мы быстро почувствовали себя комфортно, выпустив его в производство.
Декларативная поддержка NATS
После проверки концепции мы решили использовать полную настройку Kratix, чтобы исключить необходимость ручного управления пользователями и учетными данными NATS.
Задача была немного сложнее, поскольку обещанию пришлось взаимодействовать с платформой SaaS для генерации пользователей, а также безопасно хранить их учетные данные.
Мы начали с разработки сценария для управления жизненным циклом пользователей NATS в Synadia Cloud и генерации учетных данных. Чтобы упростить взаимодействие с API, мы использовали restish вместо сырых команд Curl.
Интеграция сценария с обещанием Kratix и управление состоянием ресурса для отслеживания истечения срока действия идентификатора пользователя NATS и учетных данных оказались относительно простыми. Мы позаботились о том, чтобы задачи сохранения и загрузки состояния, создания и удаления пользователей и учетных данных были четко разделены.
Тем не менее манипулирование учетными данными было настоящей проблемой. Причина в том, что манифесты Kubernetes хранятся в репозитории git, а хранить необработанные секреты было категорически запрещено.
Манипулирование секретами с помощью Kratix
Изучив несколько вариантов, мы остановились на использовании Sealed Secret. Этот инструмент использует алгоритм асимметричного шифрования для шифрования секрета с помощью открытого ключа, известного кластеру платформы, и его расшифровки с помощью закрытого ключа, известного только кластеру рабочей нагрузки.
Эта установка работала без сбоев — несколько часов! Мы быстро заметили, что наши рабочие нагрузки часто перезагружались.
Kratix ожидает, что ваше обещание будет идемпотентным. Фактически, через несколько часов Kratix запускает задание по сверке. В нашем случае этот прогон сверки создал новый токен аутентификации NATS, который обновил существующий секрет аутентификации, запуская последовательное обновление рабочей нагрузки.
Что еще хуже, мы не можем расшифровать существующий секрет или получить его из облака Synadia. Кроме того, отказ от предоставления запечатанного секретного ресурса приведет к удалению секрета из кластера рабочей нагрузки.
Чтобы обойти эту проблему, мы добавили аннотацию «sealsecrets.bitnami.com/patch» и создали пустой запечатанный секрет, чтобы предотвратить его удаление.
Заключение
Путь Cover Whale отражает проблему, с которой сталкиваются многие предприятия: создание IDP, который может вырасти из доказательства концепции в устойчивую масштабируемую платформу. MVP часто демонстрирует непосредственную ценность, но масштабирование требует переосмысления моделей Helm, CRD и управления секретами.
Команда обнаружила, что принятие подхода, основанного на «обещаниях», с Kratix предлагает прагматичный путь вперед. Однако более общий урок заключается в том, что предприятия должны быть готовы развивать свою архитектуру по мере появления новых требований. Ключевые выводы для других команд включают в себя:
- Будьте осторожны с разрастанием Хелма; подход, основанный на CRD, может обеспечить более четкие границы и снизить сложность.
- При интеграции с системами SaaS заранее планируйте управление жизненным циклом и идемпотентность.
- Управление секретами остается непростой задачей; стратегии примирения и ротации должны быть проверены в реальных условиях.
Переосмыслив IDP с учетом этих уроков, Cover Whale создал более последовательную и удобную в обслуживании основу платформы, которая продолжает развиваться по мере роста потребностей разработчиков.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Лоран Сибилла — внештатный консультант по разработке платформ, увлеченный DevOps и автоматизацией. Он активно продвигает лучшие практики DevOps и внедряет внутренние платформы разработчиков в качестве основы для создания высококачественного программного обеспечения, обеспечивая при этом высокие стандарты безопасности и надежности. Узнайте больше от Лорана Сибиллы
