GitLab CI/CD для Kubernetes: как настроить pipeline без ручного деплоя

GitLab CI/CD для Kubernetes должен не просто собирать image и запускать deploy. Нормальный pipeline фиксирует путь от commit до production: сборка, проверки, registry, deploy, approvals, rollback и post-release smoke.

Обновлено 13 июня 2026 г.10 минут

Когда пора настраивать CI/CD заново

Часто pipeline вроде бы есть, но production-релиз всё равно держится на ручных командах: кто-то локально пересобирает image, вручную меняет tag, запускает kubectl apply или помнит порядок действий только в голове.

В такой схеме GitLab CI становится не системой доставки, а журналом частично автоматизированных действий. Настройка CI/CD должна убрать неясность: что собирается, где хранится, кто может выкатить и как откатиться.

deploy в Kubernetes запускается вручную или доступен слишком многим;

image tags не связаны с commit, окружением и релизом;

секреты и variables разрослись без понятных protected/masked правил;

staging отличается от production и не ловит реальные ошибки;

rollback не проверен или описан только устно.

1. Структура GitLab CI/CD pipeline

Хороший pipeline читается как маршрут изменения. Команда должна видеть, какие stages обязательны, где собирается Docker image, какие проверки блокируют релиз и где начинается deploy в Kubernetes.

stages: lint/test/build/scan/package/deploy/smoke;

GitLab runners с понятными правами, cache и доступом к registry;

Docker image build с воспроизводимыми tags: commit SHA, branch, release;

artifacts и reports для тестов, security checks и deployment evidence;

rules/only/except без неожиданных ручных запусков production job.

2. Deploy в Kubernetes: Helm, kubectl или Argo CD

В Kubernetes опасно смешивать все способы доставки одновременно. Если часть релизов идёт через Helm, часть через kubectl, часть через Argo CD, а часть вручную, команда быстро теряет понимание реального состояния.

Нужно выбрать основной путь и явно описать исключения. Для GitLab CI это обычно Helm/kubectl deploy или GitOps-модель через Argo CD. В обоих случаях важны namespaces, service accounts, image tags, approvals и smoke-проверки.

разделить staging/production namespaces и credentials;

использовать protected environments и approvals для production;

не хранить kubeconfig и tokens в открытых variables;

фиксировать values, image tag и параметры релиза в Git;

после deploy запускать smoke checks и проверку ключевых метрик.

3. Secrets, variables и security-проверки

CI/CD часто становится местом, где незаметно копятся production-секреты. Если variables не protected/masked, runners имеют лишние права, а service accounts не ограничены, один pipeline может стать точкой компрометации всего контура.

разделить variables по окружениям и включить protected/masked там, где это нужно;

ограничить service accounts для deploy минимальными правами;

добавить dependency/image scan, если это влияет на production-риск;

не печатать секреты в job logs и не передавать их через artifacts;

описать offboarding и ротацию tokens, registry credentials и deploy keys.

4. Rollback и post-release checks

Автоматический deploy без rollback — это ускорение аварии. Перед production-релизом должно быть понятно, как вернуть предыдущую версию, кто принимает решение и какие проверки показывают, что релиз действительно успешен.

описать rollback для Helm/Argo CD/kubectl-схемы;

проверить readiness/liveness, ingress, ключевые HTTP endpoints и фоновые jobs;

связать deploy с Grafana/Prometheus: error rate, latency, saturation, pod restarts;

оставить manual approval там, где автоматизация может увеличить риск;

вести короткий release guide для команды.

Что должно быть на выходе

Результат настройки GitLab CI/CD — не большой YAML, а спокойный повторяемый релиз. Команда понимает, как изменение попадает в production, где оно проверяется, как ограничены права и что делать при проблеме.

читаемый .gitlab-ci.yml с понятными stages и rules;

контролируемый deploy в Kubernetes через Helm/kubectl или Argo CD;

protected environments, approvals и безопасная работа с secrets;

rollback-сценарий и post-release smoke checks;

связь релиза с мониторингом и коротким runbook.

FAQ

Можно ли настроить GitLab CI/CD для Kubernetes с нуля?

Да. Обычно начинаем с маршрута изменения: build, tests, image, registry, deploy, smoke checks и rollback. Затем настраиваем runners, variables, protected environments и Kubernetes service accounts.

Что лучше для deploy в Kubernetes: Helm или Argo CD?

Helm проще как прямой deploy из pipeline. Argo CD лучше подходит, когда нужна GitOps-модель, история desired state и отдельный контроль синхронизации. Выбор зависит от зрелости команды и текущей инфраструктуры.

Как безопасно хранить kubeconfig и secrets в GitLab CI?

Минимум — protected/masked variables и service account с ограниченными правами. Лучше — внешний secret store, короткоживущие credentials и отдельные права для staging и production.

Нужен ли rollback в CI/CD pipeline?

Да. Rollback должен быть описан и проверен до аварии. Для Kubernetes это может быть Helm rollback, возврат GitOps-состояния, предыдущий image tag или другой заранее согласованный сценарий.