В Asana мы используем Kubernetes для развертывания сервисов и управления ими независимо от монолитной инфраструктуры.
Поначалу у нас были некоторые проблемы, и для стандартизации создания и обслуживания приложений Kubernetes мы создали фреймворк под названием KubeApps. За последние два года наша команда по инфраструктурной платформе улучшала KubeApps, чтобы упростить развертывание сервисов в Asana. Здесь мы расскажем, какие проблемы мы хотели решить в Kubernetes и как мы это сделали с помощью фреймворка KubeApp.
Введение
Мы уже говорили о устаревшая система развертывания в Asana — наша основная инфраструктура организована как монолит экземпляров AWS EC2 с настраиваемыми сценариями настройки для каждого сервиса.Никакого масштабирования у нас не было: посылаешь новый код в монолит — перенастраиваешь все хосты.
Для добавления новой службы потребовался новый набор пользовательских сценариев настройки.
Все это было сложно поддерживать, плюс был риск повышения нестабильности развертываний в монолите.
Когда мы думали об инфраструктуре для Луна2 , решил использовать Kubernetes для развертывания сервисов и управления ими независимо от монолита.
Оркестровка контейнеров прошла хорошо, и остальные инженеры захотели использовать Kubernetes для других систем Asana. Мы улучшили эти инструменты, чтобы другие команды могли собирать и развертывать сервисы в контейнерах.
Кубернетес в Асане
С Kubernetes управлять сервисами стало намного проще, поскольку у нас есть четкие границы между процессами и средами, в которых они выполняются.В результате разработчики приложений могут собирать и обновлять одни сервисы, не опасаясь причинить вред другим.
Выводить инфраструктуру за пределы монолита EC2, конечно, стало проще, но Kubernetes еще не решил всех наших проблем ( примечание: в Kubernetes есть Менеджер облачного контроллера , который управляет узлами, настраивает маршруты между контейнерами и интегрируется с компонентами облачной инфраструктуры.
).
- Управление ресурсами AWS не имеет ничего общего с Kubernetes. Разработчикам приходилось заранее создавать ASG и готовить их для контейнеров Docker и любых других ресурсов, которые могли понадобиться приложению.
- Мы тратили слишком много времени на инструментирование всех сервисов, например сбор метрик и настройку секретных разрешений, и постоянно занимались одним и тем же — настройкой ELB, управлением группами конфигурации для каждого приложения…
- Непрерывная доставка не встроена в Kubernetes. На уровне абстракции Kubernetes логика приложения должна быть упакована в образы, доступные в реестре контейнеров.
Каждое KubeApp определяется набором требований к оборудованию, определениями модулей и спецификациями услуг.
Конфигурация как код
Все конфигурации KubeApp существуют в виде кода Python, поэтому они поддерживают конфигурации, создаваемые программным путем, и обеспечивают согласованность через общие библиотеки.С помощью этих конфигураций мы можем объявить и настроить внешние ресурсы, необходимые KubeApp. На диаграмме показаны характеристики примера веб-приложения и то, как оно будет представлено в системе конфигурации KubeApp. Для развертывания требуется оборудование, ELB и сборки образа.
Мы предоставляем спецификации по умолчанию для обработки конфигураций DNS и включаем определения модулей для обработки метрик и ведения журналов.
Образы Docker с непрерывным развертыванием
Код приложения упаковывается в образы Docker с использованием образов Bazel или традиционных файлов Dockerfile. Наши KubeApps собирают и отправляют эти образы как часть конвейера компакт-дисков, поэтому образы для любого сервиса доступны в нашем реестре.Для построения и управления зависимостями в большинстве случаев мы используем Базель .
Это особенно полезно для контейнерных приложений, поскольку таким образом мы объявляем зависимости и упаковываем сторонние библиотеки в исполняемые файлы.
Это дает нам детерминированный результат при настройке контейнерной среды для каждого приложения.
Один кластер на KubeApp
При использовании Kubernetes вам необходимо решить, как распределять сервисы между кластерами ( Примечание.Некоторые соображения по поводу компромиссов при выборе количества кластеров представлены в этой статье на сайте Learnk8s.io: Проектирование кластеров Kubernetes: сколько их должно быть?
).Развертывание сервисов в одном кластере Kubernetes экономично и удобно с точки зрения администрирования, поскольку сервисы используют одни и те же ресурсы главного узла, а такие операции, как обновление версий Kubernetes и развертывание, необходимо выполнить только один раз.
Но модель одного кластера не особенно хороша для мультитенантности, и кластер становится единой точкой отказа.
Один кластер Kubernetes ограничен с точки зрения масштабируемости, поэтому, как только он достигнет определенного размера, рекомендуется разделить его.
В Asana каждое KubeApp развертывается в собственном кластере Kubernetes через AWS EKS. Такой подход обеспечивает безопасность и стабильность приложения.
Каждый кластер отвечает за один сервис, поэтому нет необходимости беспокоиться о конкуренции ресурсов между сервисами, а в случае сбоя кластера пострадает только один сервис.
Управление несколькими кластерами затруднено, поскольку инструменты Kubernetes по умолчанию могут взаимодействовать только с одним кластером одновременно.
Вот почему мы создали инструменты для одновременного управления несколькими кластерами в KubeApps. Мы также обнаружили, что эта модель позволяет владельцам отдельных KubeApps независимо управлять кластером (обновлять узлы, масштабировать развертывания и т. д.).
Процесс развертывания KubeApp
Для развертывания KubeApp мы используем центр центрального управления, который мы называем kubecontrol. Его можно настроить для обновления вручную или автоматически через cron. Развертывание KubeApp включает в себя несколько шагов:
- Чтобы обновить или создать KubeApp, мы вводим команды в kubecontrol.
- Из спецификаций приложения мы запрашиваем набор ресурсов, необходимых KubeApp (группы автоматического масштабирования, спотовые инстансы и т. д.).
Создается новый кластер EKS.
- Делаем запрос к сервису сборки образа на сборку образа докера с определенной версией кода.
Построитель образов компилирует код для KubeApp и отправляет образ в ECR (Реестр эластичных контейнеров), если его там еще нет.
- После сборки всех ресурсов мы передаем спецификации компонентов в кластер Kubernetes, чтобы он получил необходимые докер-контейнеры от ECR и развернул их на узлах.
В KubeApps вы можете выполнить скользящее обновление, при котором обновляются изображения в работающем кластере.
Это позволяет быстро и плавно переходить от одной версии кода к другой, не запуская целый новый кластер.
Консоль управления KubeApp
До недавнего времени единственным способом прямого мониторинга или управления KubeApp было подключение к kubecontrol по ssh и взаимодействие с приложением через CLI. Найти информацию о развертываниях было сложно, поэтому пользователям приходилось изучать логи, чтобы понять, когда в KubeApp была развернута конкретная версия кода.Чтобы внести больше ясности, мы создали консоль управления KubeApp (KMC), которая отвечает за запись информации о прошлых развертываниях.
Мы хотим использовать эту консоль в качестве централизованного веб-интерфейса, где пользователи смогут взаимодействовать с KubeApps.
Что такое KubeApps сегодня и что будет дальше
Сейчас у нас в Asana более 60 KubeApps, которые поддерживают самые разные рабочие нагрузки — от управление релизами до распределенное кэширование .Пока мы поддерживаем монолит инстансов EC2, но уже конвертируем эти сервисы в контейнеры в KubeApps. Команда инфраструктурной платформы продолжает активно работать над KubeApps. В будущем мы планируем поддерживать больше архитектур (ARM64) и поставщиков инфраструктуры (AWS Fargate).
Мы также планируем создать инструменты для более удобной разработки в KubeApps, чтобы их можно было запускать в песочницах и локальных средах.
Благодаря этим и другим изменениям инфраструктуру KubeApps можно будет адаптировать к любой рабочей нагрузке, которая может нам понадобиться.
Теги: #Системное администрирование #Администрирование серверов #Kubernetes #DevOps #Microservices #k8s #monolith #bazel
-
Видеорегистратор Jassun L401Mini
19 Oct, 24 -
Кроссплатформенный Хабр
19 Oct, 24 -
Карты Google Внутри Зданий
19 Oct, 24 -
Установка Oracle 10G На Centos 6.2 X64
19 Oct, 24 -
Смысл, Смысл, Смысл, Смысл, Смысл, Смысл
19 Oct, 24 -
Шутка - Это Красиво...
19 Oct, 24
