Как Okta масштабировала кластеры Kubernetes с 12 до 1000 с помощью Argo CD

АТЛАНТА — Скажем так, клиенты платформы Okta Auth0 для частного облака не получили того, чего они, вероятно, хотели. Поддержка Okta была в лучшем случае проблематичной, особенно для крупных клиентов.

Это привело к решению сделать огромную ставку на открытый исходный код для GitOps, в частности на проект Argo CD, выпущенный CNCF (ранее называвшийся Argo Workflows). Это был не просто подъем и сдвиг; для его внедрения в столь широком масштабе операций потребовалось более пяти лет. Во время KubeCon + CloudNativeCon инженеры Okta Жереми Альбюшех и Каху Лей подробно рассказали о своих испытаниях и невзгодах в своем докладе «От десятка до тысячи кластеров: как Арго выдержала темпы нашего масштабирования».

Конечный результат: «Мы можем с уверенностью сказать, что теперь результаты показывают, что они могут масштабироваться более чем на тысячу кластеров по сравнению с дюжиной или около того несколько лет назад», — сказал Альбуишеш во время выступления.

Кредитный срок

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

Операторы GitOps, такие как Argo CD и Flux, отслеживают git как неизменяемый источник истинного желаемого состояния и применяют это желаемое состояние к фактическому состоянию. Неизменяемая структура Git также автоматизирует изменения в приложениях и коде в кластерах при обнаружении уязвимостей (а они всегда будут) во время выполнения. Аналогично, если кто-то напрямую изменит среду выполнения (например, во время нарушения безопасности), операторы GitOps автоматически обнаружат эти изменения и перезапишут их желаемым состоянием в Git.

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

Правда с открытым исходным кодом

Вернемся более чем на пять лет назад. В своей первой итерации Албуйшеч и Лей описали, что платформа Auth0 от Okta была главным образом способом размещения сервисов для клиентов, которые хотели, чтобы их инфраструктура и конфигурация хранились в учетной записи частного облака. Он был ориентирован на очень небольшую группу клиентов и, как следствие, не создавался с учетом приоритетов масштабирования и автоматизации. Он имел конфигурации и инфраструктуру Snowflake. Обновления выполнялись оператором вручную, доступ не был настолько безопасным, насколько мог бы быть, и он опирался на облачную инфраструктуру первых дней существования — в основном код, выполняющийся на виртуальных машинах (ВМ).

«Поскольку спрос увеличился, нам понадобился новый дизайн платформы», — сказал Альбуишеш. «После исследований и проверки концепций мы получили облачную архитектуру, активно использующую проект Argo». Argo CD занимается предоставлением услуг, Argo Workflows занимается развертыванием, Terraform (с настраиваемым поставщиком) обрабатывает инфраструктуру как код (IaC), и все это управляется службами плоскости управления, поэтому мы можем управлять всеми средами клиентов, сказал Альбушеч.

тяжелая работа

Одна из прекрасных особенностей проектов с открытым исходным кодом — это то, что пользователи сообщества постоянно предлагают изменения по мере роста новостей и самого проекта. Тем не менее, компакт-диск Argo с открытым исходным кодом сталкивается с несколькими «значительными» проблемами, о чем подробно рассказали Альбуишеш и Лей во время своего разговора.

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

Как описал Лей, автосинхронизация Argo CD гарантирует, что состояние кластера Kubernetes всегда соответствует Git. «Однако мы не можем использовать автоматическую синхронизацию в нашем конвейере развертывания из-за нашей модели выпуска. Каждый кандидат на выпуск представляет собой пакет, содержащий версии образа службы, код Terraform, манифесты Kubernetes, плагины и пользовательскую логику», — сказал Лэй.

«Самородной плагин application-X изначально приводил к тому, что операции обновления занимали минуты, поскольку настройка порождала подпроцесс для каждого плагина, что требовало раздвоенного двоичного файла. Запуск разных версий плагина для каждого клиента требовал подхода Docker-in-Docker, что еще больше усложняло работу», — сказал Лей.

По словам Лей, один манифест выпуска соответствует одному приложению Argo, а одно приложение Argo представляет целый кластер клиентов. Поскольку инфраструктура, созданная Terraform, влияет на конфигурацию и секреты, необходимые службам, Terraform должен запускаться до синхронизации Argo CD. Автоматическая синхронизация не может учесть эту зависимость и не учитывает окна развертывания, специфичные для клиента. Обходной путь: «Поэтому мы реализуем нашу собственную «автосинхронизацию», используя рабочие процессы Argo плюс плоскость управления», — сказал Лей.

Другие проблемы заключались в том, что временные сбои при развертывании, в том числе циклические сбои, конфликты синхронизации, сбои плагинов и зависания синхронизации, были обычным явлением. Чтобы управлять ими, команда создала оболочку интерфейса командной строки (CLI), которая классифицирует сбои, обеспечивает соблюдение тайм-аутов и контролирует повторные попытки, описали Албуишеш и Лей. «При масштабировании контроллер приложений часто выходит из строя под нагрузкой, пользовательский интерфейс становится очень медленным, а статусы приложений могут вводить в заблуждение, что требует масштабирования контроллера, улучшения инфраструктуры, инструментов CLI и настроек игнорирования ресурсов», — сказал Лей. Ошибки восходящего потока, такие как состояние гонки в контроллере приложений и проблемы с производительностью из-за неотслеживаемых ресурсов, приходилось устранять внутри компании.

Рабочие процессы, состоящие из 50 и более шагов, поддерживаемые несколькими командами, сопряжены с риском конфликтов и требуют динамического управления подпроцессами. Большие рабочие процессы для обновлений Kubernetes, сине-зеленых обновлений Postgres, нагрузочных тестов, тестов хаоса и проверки CI могут перегрузить пользовательский интерфейс Argo, вызывая необходимость обходных решений, таких как запуск помеченных дочерних рабочих процессов. Некоторые ограничения пользовательского интерфейса вынудили использовать необычные решения, такие как плагин Chrome для удаления кнопки «Завершить», что позволяло обходить перехватчики выхода и нарушать автоматизацию. Несмотря на эти проблемы, платформа продолжает масштабироваться за счет обширного пользовательского инструментария, координации рабочих процессов и тщательного оперативного управления, сказал Лей.

Удивительно, правда

Учитывая сканирование выданных запросов на включение и отзывы на GitHub об этом чрезвычайно успешном проекте с открытым исходным кодом, это очень распространенные проблемы, с которыми они столкнулись, и предлагаются совместные исправления. Также полезно иметь в виду, что это огромный успех для крупного проекта с открытым исходным кодом с точки зрения его реализации. Это не просто очень крутая технология платформы GitOps, но по мере ее развития Argo CD продолжает демонстрировать свои преимущества для Kubernetes, особенно в GitOps в масштабе. И не стоит забывать о Flux, так как он также хорошо зарекомендовал себя.

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

ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. BC Gain — основатель и главный аналитик ReveCom Media. Его одержимость компьютерами началась, когда в начале 1980-х он взломал консоль Space Invaders, чтобы играть весь день за 25 центов в местном игровом зале. Затем он… Подробнее от Б. Кэмерона Гейна.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *