Налаштування 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.