поставка по GitOps с Argo CD или Flux в Kubernetes
GitOps с Argo CD и Flux: согласованность и соответствие требованиям в Kubernetes
12 минут
Git как контракт убирает тихий дрейф между кластерами. Сравниваем практики Argo CD и Flux — от установки до политики — и собираем рамки для секретов, наблюдаемости и выкатов, готовых к аудиту.
Почему без GitOps развертывания в Kubernetes снова расходятся с реальностью
Современные контуры должны удерживать желаемое состояние кластеров согласованным и при этом отвечать аудиторам вопросом «кто, что и когда менял». Императивный стиль с ручными правками усиливает дрейф конфигураций, концентрирует знания в отдельных людях и ухудшает историю откатов. Чаще всего всплывают четыре пробела: расхождение факта в API с тем, что описано в Git, размытая evidence для внутренней политики и регуляторов, self-service без рамок безопасности и неполная история изменений при инцидентах.
Что меняет GitOps при выборе Argo CD или Flux
GitOps закрепляет декларативные манифесты в Git как контракт. Argo CD или Flux непрерывно сводят состояние API-сервера к этому контракту, заменяя ручную «сходимость» автоматикой. Вы получаете непрерывную синхронизацию, версионируемые выкаты, обнаружение дрейфа с опциональным self-heal, RBAC, привязанный к изменениям в Git, и неизменяемую историю для аудита. Для внедрения стандартизируйте структуру репозитория (например, каталоги environments/prod и environments/staging), установите в кластере один оператор, описывайте приложения через Helm, Kustomize или «голый» YAML, при необходимости подключайте движки политик вроде OPA, а здоровье синхронизации выводите в дашборды и метрики.
Пример: Argo CD — от установки до Application
Argo CD отслеживает ветки или теги в Git, материализует манифесты и сравнивает живое состояние кластера с желаемым. Создайте namespace argocd и примените штатный install-манифест. Для доступа к UI на время отладки удобен port-forward; для боевого контура настройте ingress и TLS. Каждую развёртываемую единицу оформляйте как ресурс Application, чтобы политика синхронизации, prune и self-heal оставались декларативными. Для корпоративной аутентификации подключайте Dex или LDAP так, чтобы учётные записи согласовывались с доступом к Git и с RBAC в кластере.
# Create namespace
kubectl create namespace argocd
# Install Argo CD
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml# Port-forward to access the UI locally
kubectl port-forward svc/argocd-server -n argocd 8080:443
# Get initial admin password
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -dapiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
server: https://kubernetes.default.svc
namespace: guestbook
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=truekubectl apply -f application.yaml# argocd-cm ConfigMap snippet
data:
url: https://argocd.example.com
dex.config: |
connectors:
- type: ldap
id: ldap
name: LDAP
config:
host: ldap.example.com
port: 389
insecureNoSSL: true
baseDN: ou=users,dc=example,dc=com
username: cn=admin,dc=example,dc=com
password: secret
userSearch:
filter: "(mail=%s)"Пример: Flux — bootstrap, Kustomization и HelmRelease
Flux распределяет задачи между контроллерами источников, сведения Kustomize или Helm и уведомлений. Установите CLI Flux локально, затем выполните flux bootstrap github, ограничив --path только нужным поддеревом репозитория. Кластерный Kustomization связывает каталог в клоне репозитория с непрерывным применением. HelmRelease фиксирует версию чарта, а значения можно держать в Git как overlay. При жёстких требованиях к политике тот же шаблон распространяется на политику, поставляемую как OCI-артефакты.
# Install Flux CLI
curl -s https://fluxcd.io/install.sh | sudo bash
# Bootstrap Flux on a GitHub repository
flux bootstrap github \
--owner=<GITHUB_USERNAME> \
--repository=<REPO_NAME> \
--branch=main \
--path=./clusters/my-cluster \
--personal# ./clusters/my-cluster/kustomization.yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: cluster-config
namespace: flux-system
spec:
interval: 1m0s
sourceRef:
kind: GitRepository
name: flux-system
path: ./cluster
prune: true
validation: client
healthChecks:
- apiVersion: v1
kind: Pod
name: coredns
namespace: kube-system# ./cluster/apps/helmrelease.yaml
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
name: podinfo
namespace: default
spec:
interval: 5m
chart:
spec:
chart: podinfo
sourceRef:
kind: HelmRepository
name: podinfo-chart
namespace: flux-system
version: 6.x.x
install:
remediation:
retries: 3
upgrade:
remediation:
retries: 3
values:
replicaCount: 2# ./cluster/policies/kustomization.yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: policies
namespace: flux-system
spec:
interval: 30s
sourceRef:
kind: GitRepository
name: flux-system
path: ./policies
prune: true
validation: clientРепозиторий, безопасность, наблюдаемость и комплаенс
Разделяйте платформенные аддоны кластера и продуктовые микросервисы — отдельными репозиториями или чёткими зонами монорепозитория. Продвигайте изменения от dev к staging и prod через ветки, теги или «ворота» по каталогам, а не внезапными правками в продовых кластерах. Соблюдайте принцип наименьших привилегий для токенов Git, service account-ов операторов и контроллеров; не храните долгоживущие секреты в открытом Git — используйте внешние хранилища с CSI или sealed-подходы, включайте подпись коммитов, если политика безопасности требует неотказуемости. Экспортируйте метрики в Prometheus, настраивайте оповещения на сбои синхронизации и деградацию health, централизуйте логи для разборов, резервируйте Git и при необходимости снимки etcd, а на уровне допуска закрепляйте политику через Gatekeeper или Kyverno, чтобы нарушения всплывали до запуска рабочей нагрузки.
Вывод: пилот, метрики сведения, затем масштабирование
Выбор между Argo CD и Flux не отменяет главного операционного эффекта: воспроизводимые выкаты, прозрачная работа с дрейфом и аудит, опирающийся на Git. Начните с пилота на одном классе сервисов, зафиксируйте политику sync и RBAC по умолчанию и расширяйтесь на новые кластеры, когда метрики покажут стабильные циклы сведения и команды доверяют процессу.
Между Git и кластером по-прежнему нужна дисциплина работы с секретами — разобрать подход можно в материале про управление секретами в DevOps и CI/CD.
Статус синхронизации полезен только при качественной телеметрии, поэтому сочетайте операторы с практиками из гайда по наблюдаемости для небольших платформенных команд.