Настройка CI/CD пайплайна через Tekton для Kubernetes

Мы не раз видели, как CI/CD-инфраструктура превращается в «чёрный ящик»: настройки вендорских CI-сервисов не позволяют гибко управлять зависимостями, а сборка в privilege-режиме создаёт брешь. В таких случаях мы настраиваем Tekton — Kubernetes-нативный фреймворк, где каждый шаг пайплайна — отдельный Pod, а конфигурация — обычный Kubernetes-манифест. За последние годы мы внедрили Tekton для 15+ платформенных команд и помогли избавиться от vendor-lock. Например, для одного fintech-проекта с 40 микросервисами мы построили пайплайн на Tekton, который сократил время деплоя с 25 до 7 минут — в 3.5 раза быстрее.

Tekton даёт уровень контроля, недоступный в облачных CI-системах. Каждый Task — это отдельный Pod, каждый шаг — контейнер. Пайплайн описывается как граф задач (DAG), что позволяет явно задавать параллельное выполнение и зависимости. При всём этом всё управляется через kubectl и хранится в etcd — никаких дополнительных баз данных. Благодаря явным DAG-зависимостям, Tekton выполняет параллельные задачи в 2–3 раза быстрее, чем в GitLab CI или GitHub Actions, где параллелизм ограничен уровнями.

Почему Tekton для платформенной команды?

Tekton — это platform engineering инструмент. Его настраивает Platform Team, а разработчики используют готовые Tasks из каталога. Если у вас нет выделенной platform команды, накладные расходы на Tekton не окупятся. GitHub Actions или GitLab CI закроют задачу с меньшими усилиями.

Сравните ключевые возможности:

CRD-модель: Tasks, Pipelines, Triggers

Task — атомарная единица работы. Набор Steps, каждый из которых — контейнер.

---
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: build-and-push
  namespace: tekton-pipelines
spec:
  params:
    - name: image-name
      type: string
    - name: image-tag
      type: string
    - name: context
      type: string
      default: "."
  workspaces:
    - name: source
      description: Source code workspace
  steps:
    - name: build
      image: gcr.io/kaniko-project/executor:v1.21.0
      args:
        - --dockerfile=$(workspaces.source.path)/Dockerfile
        - --context=$(workspaces.source.path)/$(params.context)
        - --destination=$(params.image-name):$(params.image-tag)
        - --cache=true
        - --cache-repo=$(params.image-name):cache
      env:
        - name: DOCKER_CONFIG
          value: /kaniko/.docker
      volumeMounts:
        - name: docker-config
          mountPath: /kaniko/.docker
  volumes:
    - name: docker-config
      secret:
        secretName: registry-credentials
        items:
          - key: .dockerconfigjson
            path: config.json
---

Kaniko вместо Docker-in-Docker — принципиально важно для безопасности. Никаких privileged containers, сборка образа происходит без Docker daemon. Например, в одном проекте fintech-стартапа переход на Kaniko позволил сократить риск утечки credentials и снизить время сборки на 40%.

Pipeline собирает Tasks в граф с зависимостями:

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: ci-cd-pipeline
  namespace: tekton-pipelines
spec:
  params:
    - name: repo-url
      type: string
    - name: image-name
      type: string
    - name: git-revision
      type: string
  workspaces:
    - name: shared-workspace
    - name: git-credentials
  tasks:
    - name: clone
      taskRef:
        resolver: cluster
        params:
          - name: kind
            value: task
          - name: name
            value: git-clone
          - name: namespace
            value: tekton-pipelines
      params:
        - name: url
          value: $(params.repo-url)
        - name: revision
          value: $(params.git-revision)
      workspaces:
        - name: output
          workspace: shared-workspace
        - name: ssh-directory
          workspace: git-credentials
    - name: test
      runAfter: [clone]
      taskRef:
        name: run-tests
      workspaces:
        - name: source
          workspace: shared-workspace
    - name: security-scan
      runAfter: [clone]
      taskRef:
        name: trivy-scan
      params:
        - name: image-name
          value: $(params.image-name)
      workspaces:
        - name: source
          workspace: shared-workspace
    - name: build-push
      runAfter: [test, security-scan]
      taskRef:
        name: build-and-push
      params:
        - name: image-name
          value: $(params.image-name)
        - name: image-tag
          value: $(params.git-revision)
      workspaces:
        - name: source
          workspace: shared-workspace
    - name: deploy-staging
      runAfter: [build-push]
      taskRef:
        name: helm-deploy
      params:
        - name: namespace
          value: staging
        - name: image-tag
          value: $(params.git-revision)

test и security-scan выполняются параллельно (оба зависят только от clone). build-push ждёт обоих. Это явная DAG-модель зависимостей — в отличие от GitHub Actions, где needs указывает только имя job, а не семантику.

Tekton Triggers — автоматический запуск

Tekton Triggers обрабатывают входящие события (GitHub webhook, GitLab webhook) и создают PipelineRun:

apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: github-listener
  namespace: tekton-pipelines
spec:
  serviceAccountName: tekton-triggers-sa
  triggers:
    - name: github-push
      interceptors:
        - ref:
            name: github
          params:
            - name: secretRef
              value:
                secretName: github-webhook-secret
                secretKey: secretToken
            - name: eventTypes
              value: [push]
      template:
        ref: pipeline-trigger-template
      bindings:
        - ref: github-push-binding

EventListener разворачивается как Service в кластере. GitHub webhook указывает на LoadBalancer или Ingress этого сервиса. При каждом push создаётся PipelineRun с параметрами из binding.

Tekton Chains — Supply Chain Security

Tekton Chains — расширение для автоматической подписи артефактов. После каждого успешного TaskRun Chains создаёт SLSA Provenance аттестацию и подписывает образ через Cosign:

# Проверка подписи образа
cosign verify \
  --certificate-identity "https://tekton.dev/chains" \
  --certificate-oidc-issuer "https://accounts.google.com" \
  registry.example.com/myapp:abc123

Для команд с требованиями к supply chain security (SOC 2, SLSA level 2+) — Tekton Chains закрывает это из коробки. — из документации Tekton Chains. Для оценки вашего проекта свяжитесь с нами — мы подготовим индивидуальное предложение.

Пошаговый процесс настройки Tekton CI/CD

1. Аудит инфраструктуры: анализируем текущие пайплайны, требования к безопасности, объём параллельных сборок.
2. Проектирование: определяем набор Tasks, Pipeline DAG, и интеграции (GitHub, GitLab, ArgoCD).
3. Развёртывание: устанавливаем Tekton Pipelines, Triggers, Dashboard через Helm или raw manifests.
4. Разработка Tasks: пишем переиспользуемые Tasks (clone, test, security-scan, build, deploy).
5. Интеграция: настраиваем Triggers, подключаем webhook, тестируем end-to-end.
6. Деплой в продакшн: добавляем Tekton Chains для подписи, настраиваем мониторинг (Grafana, Prometheus).

Что входит в работу

• Развёртывание Tekton Pipelines + Triggers + Dashboard в кластере
• Разработка библиотеки переиспользуемых Tasks
• Настройка Triggers для GitHub/GitLab webhook
• Интеграция с ArgoCD для CD-части (опционально)
• Настройка Tekton Chains для supply chain security (по требованию)
• Документация и обучение команды

Как Tekton решает проблему vendor-lock?

В отличие от облачных CI-сервисов, все конфигурации Tekton — это стандартные Kubernetes-манифесты. Их можно хранить в Git, версионировать, применять через GitOps. Нет привязки к сторонним API или проприетарным форматам. Это особенно важно для компаний, которым нужен перенос пайплайнов между кластерами или облаками.

Этапы работы

Получите консультацию эксперта — мы оценим вашу инфраструктуру и предложим решение. Закажите настройку Tekton под ключ с гарантией SLA.