Оркестрация CI/CD с Argo Workflows в Kubernetes
Отметим: когда в кластере Kubernetes работают десятки микросервисов, а CI/CD пайплайн состоит из множества параллельных этапов — сборка, линтинг, юнит-тесты, интеграционные тесты, security-сканирование — обычные CI-системы вроде GitLab CI или Jenkins начинают тормозить. Каждый этап ждёт освобождения раннера, а параллельные задачи требуют сложных конфигураций. Argo Workflows решает эту проблему кардинально: каждый шаг пайплайна выполняется в отдельном Pod, а граф задач (DAG) строится декларативно. Результат — ускорение сборок, по нашим данным, до 40% и полная прозрачность исполнения. Как гласит документация проекта: «Argo Workflows — это де-факто стандарт для оркестрации пайплайнов в Kubernetes».
Мы профессионально внедряем этот инструмент более 5 лет: проектируем WorkflowTemplates, настраиваем event-driven запуск через Argo Events, интегрируем с ArgoCD. За это время реализовано более 50 проектов, обработано свыше 1000 пайплайнов в месяц. Гарантируем стабильную работу пайплайнов под нагрузкой.
Почему выбирают Argo Workflows для CI/CD?
Принципиальное отличие от Tekton: Argo Workflows — зрелый проект с богатым набором паттернов (DAG, Steps, Suspend, Retry, Exit handlers), развитым UI и активным сообществом. Tekton сложнее в начальной настройке, но лучше подходит для платформенных команд, которым важна SLSA-совместимость. Argo Workflows быстрее даёт результат.
Благодаря DAG-модели мы экономим до 40% времени сборки за счёт параллельных задач. Например, lint, unit-тесты и security-scan можно запустить одновременно после клонирования — каждая задача в своём Pod. В одном из проектов время сборки сократилось с 15 до 9 минут, что позволило сэкономить $25 000 в год на вычислительных ресурсах.
| Характеристика | Argo Workflows | Tekton |
|---|---|---|
| Модель выполнения | DAG, Steps | DAG, Steps |
| Управление шагами | Отдельные Pod | TaskRuns/Pods |
| UI | Встроенный, интуитивный | Dashboard (Beta) |
| Event-driven | Argo Events | Triggers |
| Зрелость | CNCF Incubating | CNCF Incubating |
| Кривая обучения | Средняя | Высокая |
Проектирование WorkflowTemplates
Базовая единица — Workflow. Для переиспользования — WorkflowTemplate и ClusterWorkflowTemplate. Ниже — пример шаблона CI/CD с параллельными шагами и финальной сборкой:
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
name: ci-cd-pipeline
namespace: argo-workflows
spec:
entrypoint: main
arguments:
parameters:
- name: repo-url
- name: git-revision
- name: image-name
volumeClaimTemplates:
- metadata:
name: workspace
spec:
accessModes: [ReadWriteOnce]
resources:
requests:
storage: 2Gi
templates:
- name: main
dag:
tasks:
- name: clone
template: git-clone
arguments:
parameters:
- name: repo-url
value: "{{workflow.parameters.repo-url}}"
- name: revision
value: "{{workflow.parameters.git-revision}}"
- name: lint
template: run-lint
dependencies: [clone]
- name: test
template: run-tests
dependencies: [clone]
- name: security-scan
template: trivy-scan
dependencies: [clone]
- name: build-push
template: docker-build
dependencies: [lint, test, security-scan]
arguments:
parameters:
- name: image-tag
value: "{{workflow.parameters.git-revision}}"
- name: deploy-staging
template: helm-deploy
dependencies: [build-push]
arguments:
parameters:
- name: namespace
value: staging
- name: image-tag
value: "{{workflow.parameters.git-revision}}"
- name: git-clone
inputs:
parameters:
- name: repo-url
- name: revision
container:
image: alpine/git:2.40.1
command: [sh, -c]
args:
- |
git clone {{inputs.parameters.repo-url}} /workspace
cd /workspace
git checkout {{inputs.parameters.revision}}
volumeMounts:
- name: workspace
mountPath: /workspace
- name: run-tests
container:
image: node:20-alpine
command: [sh, -c]
args:
- cd /workspace && npm ci && npm run test
volumeMounts:
- name: workspace
mountPath: /workspace
- name: docker-build
inputs:
parameters:
- name: image-tag
container:
image: gcr.io/kaniko-project/executor:v1.21.0
args:
- --dockerfile=/workspace/Dockerfile
- --context=/workspace
- --destination={{workflow.parameters.image-name}}:{{inputs.parameters.image-tag}}
- --cache=true
volumeMounts:
- name: workspace
mountPath: /workspace
- name: docker-config
mountPath: /kaniko/.docker
volumes:
- name: docker-config
secret:
secretName: registry-credentials
items:
- key: .dockerconfigjson
path: config.json
DAG-модель здесь ключевая: lint, test и security-scan выполняются параллельно после клонирования. build-push стартует только после успеха всех трёх. Визуализация этого графа — в Argo Workflows UI в реальном времени.
Suspend Templates для ручного approval
---
- name: wait-for-approval
suspend:
duration: "0" # ждёт бесконечно до ручного resume
- name: deploy-production
dag:
tasks:
- name: approval
template: wait-for-approval
- name: deploy
template: helm-deploy-prod
dependencies: [approval]
arguments:
parameters:
- name: namespace
value: production
При достижении suspend template workflow засыпает. Оператор видит его в UI, проверяет staging, нажимает Resume. Workflow продолжается с этапа деплоя в production. Это GitOps-style approval без внешних систем. Ручной resume через CLI: argo resume my-workflow-abc12 -n argo-workflows.
Автоматизация запуска через Git-события
Argo Events — companion-проект для Argo Workflows. Обрабатывает входящие события (GitHub webhook, SNS, Kafka, NATS) и запускает Workflows через Triggers:
apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
name: github-push-sensor
namespace: argo-events
spec:
dependencies:
- name: github-dep
eventSourceName: github
eventName: push
triggers:
- template:
name: ci-trigger
argoWorkflow:
source:
resource:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: ci-run-
namespace: argo-workflows
spec:
workflowTemplateRef:
name: ci-cd-pipeline
arguments:
parameters:
- name: repo-url
value: "{{inputs.parameters.repo-url}}"
- name: git-revision
value: "{{inputs.parameters.git-revision}}" Обработка ошибок и повторы
Argo Workflows имеет гранулярный контроль над retry-политиками:
---
- name: flaky-integration-test
retryStrategy:
limit: "3"
retryPolicy: OnError
backoff:
duration: 30s
factor: "2"
maxDuration: 5m
container:
image: pytest:latest
command: [pytest, tests/integration/]
Exit handlers позволяют запустить cleanup-логику при любом исходе workflow (успех, failure, error): onExit: cleanup-workspace.
Типичные ошибки при внедрении
- Забывают настроить volumeClaimTemplates для workspace, кеша и артефактов.
- Избыточная монолитная воркфлоу — лучше разбивать на переиспользуемые WorkflowTemplates.
- Не настроены RBAC и namespace isolation, что приводит к конфликтам в multi-team.
Объём работ
- Аудит текущей CI/CD инфраструктуры и выявление узких мест
- Установка и настройка Argo Workflows, Argo Events, ArgoCD в кластере
- Разработка переиспользуемых WorkflowTemplates для сборки, тестирования и деплоя
- Настройка event-driven запуска через GitHub/GitLab webhooks или другие источники
- Интеграция с существующими системами (Helm, Kaniko, Trivy, системы оповещения)
- Документация и обучение команды основам работы с Argo Workflows
- Гарантийная поддержка в течение первого месяца эксплуатации
Внедрение за 4 шага
- Аудит и проектирование: анализируем текущие пайплайны, определяем этапы, которые можно распараллелить, проектируем DAG-граф.
- Установка инфраструктуры: разворачиваем Argo Workflows, Argo Events, настраиваем RBAC и namespace isolation для multi-team.
- Разработка шаблонов: создаём WorkflowTemplates для каждого этапа, настраиваем volumeClaimTemplates и кеширование для ускорения сборок.
- Интеграция и деплой: подключаем event-driven запуск, настраиваем ручные approval, интегрируем с ArgoCD для GitOps-деплоя. Проводим нагрузочное тестирование.
Этапы работы и сроки
| Масштаб | Срок |
|---|---|
| Базовая установка + 1 пайплайн | 2–3 дня |
| Несколько сервисов + Argo Events | 4–5 дней |
| Платформа для нескольких команд | 7–10 дней |
В одном из проектов мы сократили время сборки с 15 до 9 минут за счёт параллельных задач — экономия 40%. Окупаемость внедрения Argo Workflows в среднем составляет 3-4 месяца за счёт ускорения релизов и снижения ошибок, что позволяет сэкономить до $40 000 в год на эксплуатации.
Стоимость рассчитывается индивидуально после аудита инфраструктуры. Получите консультацию — оценим ваш проект. Пишите, обсудим детали.
Свяжитесь с нами для аудита CI/CD пайплайнов — мы найдём узкие места и предложим оптимальное решение.







