В чем сложности оркестрации параллельных заданий в Kubernetes и как их решить с помощью Argo Workflows: обзор фреймворка и практический пример YAML-спецификации шаблона рабочего процесса для развертывания веб-приложения.
Что такое Argo Workflows и зачем он нужен
Оркестрация параллельных заданий на платформе Kubernetes довольно сложна из-за их внутренних зависимостей друг от друга и специфики настройки самой платформы управления контейнерными приложениями. Кроме того, параллельные задания обработки больших объемов данных могут требовать много ресурсов, которые надо эффективно распределять между конкурирующими вычислениями, избегая переполнения или недостаточной утилизации. При отказе отдельного задания необходимо предусмотреть механизмы для его повторного запуска или корректного завершения, чтобы это не повлияло на другие процессы.
Справиться с этими проблемами можно с помощью Argo Workflows — контейнерного движка рабочих процессов с открытым исходным кодом для оркестровки параллельных заданий в Kubernetes. Argo Workflows реализован как пользовательское определение ресурсов Kubernetes (CRD, Custom Resource Definition), которое позволяет выполнять следующие функции:
- определять рабочие процессы Kubernetes, используя отдельные контейнеры для каждого шага;
- моделировать рабочие процессы с помощью направленных ациклических графов (DAG) для фиксации зависимостей между несколькими шагами или определения последовательностей задач;
- выполнять задачи обработки данных, требующие больших вычислительных ресурсов, или машинного обучения;
- запускать конвейеры CI/CD на Kubernetes без настройки сложного решения для разработки приложений.
В настоящее время Argo Workflows считается одним из наиболее популярных движков выполнения рабочих процессов для Kubernetes. Он масштабируемый и простой в использовании, разработано специально для контейнеров без накладных расходов и ограничений устаревших виртуальных машин и серверных сред. Argo Workflows не зависит от облака и может работать в любом кластере Kubernetes.
Как работает Argo Workflows
Argo Workflows позволяет определить шаги CI/CD-конвейера в виде YAML-файла конфигурации. Каждый из этих шагов выполняется в отдельном контейнере в кластере Kubernetes. CRD под названием Workflows предоставляет generateName – имя, которое становится префиксом всех запускаемых подов.
После настройки базовой конфигурации рабочего процесса можно определить шаблоны для каждого этапа процесса CI/CD. Лучше всего определить центральный шаблон с несколькими шагами (точка входа), где каждый шаг запускает один из шаблонов в рабочем процессе. Шаблоны имеют входные аргументы, которые можно использовать для передачи данных между шагами. Процесс может иметь любое количество шагов, чтобы автоматизировать любые сложные CI/CD -процессы. При этом Argo Workflows запускает все этапы конвейера на существующих ресурсах в кластере Kubernetes без внешних зависимостей: не нужно запускать дополнительные вычислительные экземпляры для сервера сборки или других компонентов.
Рабочий процесс — это центральный stateful-ресурс фреймворка. Спецификация шаблона рабочего процесса определяет инструкции, которые надо выполнить, включая определения контейнеров, операции над ресурсом кластера, скрипты, дополнительные вызовы других шаблонов и управления их выполнением, включая шаги и задачи в DAG. Фреймворк имеет веб-GUI, который позволяет просматривать завершенные и текущие рабочие процессы и логи контейнеров, создавать и просматривать cron-задания, а также новые шаблоны.
Практический пример YAML-спецификации шаблона рабочего процесса
Чтобы посмотреть, как работает Argo Workflows, напишем шаблон рабочего процесса, который запускает контейнерное Flask-приложение. Предположим, последняя версия Docker-образа этого Flask-приложения хранится в директории docker-registry/flask-app:latest. Тогда спецификация шаблона Argo Workflows будет выглядеть так:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: flask-app-workflow-
spec:
entrypoint: flask-app
templates:
- name: flask-app
container:
image: docker-registry/flask-app:latest
command: ["/bin/sh", "-c"]
args: ["flask run --host=0.0.0.0 --port=5000"]
resources:
limits:
memory: "512Mi"
cpu: "500m"
В Kubernetes и других системах, использующих манифесты YAML для описания ресурсов, поле apiVersion определяет версию API, которую использует этот ресурс.
Строка apiVersion: argoproj.io/v1alpha1 указывает, что ресурс относится к API, предоставляемому проектом Argo, и использует альфа-версию v1alpha1. Поле generateName используется для автоматического создания уникальных имён. Обычно оно оканчивается на дефис (-), чтобы добавить случайные строки к прификсу всех подов, созданных шаблоном. Точка входа entrypoint указывает, что будет запущено при вызове шаблона. В реальном рабочем процессе обычно несколько шаблонов, и точка входа запускает многошаговый процесс. В этой спецификации указаны ограничения ресурсов для контейнера с Flask-приложением, запускаемом на локальном хосте и порту 5000. Контейнер не сможет использовать более 512 мегабайт памяти и более половины мощности одного процессорного ядра. Эти ограничения помогают управлять ресурсами в кластере Kubernetes, гарантируя, что ни один контейнер не сможет превысить заданные пределы и не повлияет на производительность других контейнеров. Таким образом, этот конфигурационный YAML-файл Argo Workflows описывает, как будет запущено Flask-приложение в контейнере, используя конкретный образ из Docker-реестра. Читайте в нашей новой статье про управление развертыванием контейнерных приложений в Kubernetes с Argo Rollouts.
Научитесь работать с Kubernetes и Argo Workflows на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
