Entrega contínua Kubernetes: pipelines GitOps com ArgoCD e Flux

A entrega contínua no Kubernetes evoluiu muito além da simples kubectl apply comandos. As equipes modernas estão adotando o GitOps, um paradigma que usa o Git como a única fonte de verdade para infraestrutura declarativa e configuração de aplicativos. Ao combinar os princípios do GitOps com ferramentas como ArgoCD e Flux CD, as organizações podem obter pipelines de implantação confiáveis, auditáveis ​​e automatizados que podem ser dimensionados em clusters e ambientes.

Este guia aborda a arquitetura, a configuração e as práticas recomendadas para a construção de pipelines de entrega contínua de nível de produção no Kubernetes usando a abordagem GitOps.

Princípios do GitOps

O GitOps é baseado em quatro princípios básicos que mudam fundamentalmente a forma como as equipes gerenciam as implantações:

• Configuração declarativa - Todo o estado desejado do seu sistema é descrito de forma declarativa. Para Kubernetes, isso significa manifestos YAML, gráficos Helm ou sobreposições Kustomize armazenados no Git.
• Versão controlada - Git serve como a única fonte da verdade. Cada mudança passa por uma solicitação pull, fornecendo uma trilha de auditoria completa e permitindo reversões fáceis por meio da reversão de commits.
• Reconciliação Automatizada - Um agente em execução no cluster compara continuamente o estado desejado no Git com o estado real no cluster e reconcilia automaticamente qualquer desvio.
• Observação Contínua - O sistema monitora continuamente o repositório Git e o estado do cluster, alertando sobre divergências e garantindo que o cluster sempre corresponda à configuração declarada.

Esses princípios eliminam etapas manuais de implantação, reduzem erros humanos e fornecem um fluxo de trabalho consistente, independentemente da complexidade do cluster.

Arquitetura e configuração do ArgoCD

ArgoCD é a ferramenta GitOps mais amplamente adotada para Kubernetes. Ele fornece uma UI web poderosa, CLI e API para gerenciar implantações de aplicativos em clusters.

Componentes principais

ArgoCD consiste em vários componentes principais que funcionam juntos:

• Servidor API - Expõe um gRPC/REST API e atende a UI da web. Lida com autenticação, RBAC e integrações externas.
• Servidor de repositório - Clona repositórios Git e gera manifestos Kubernetes a partir de gráficos Helm, Kustomize ou YAML simples.
• Controlador de aplicativos - Monitora continuamente os aplicativos em execução e compara o estado ativo com o estado desejado no Git.
• Redis - Fornece cache para o servidor de repositório e controlador de aplicativo.

Instalação

Implante o ArgoCD em seu cluster usando os manifestos oficiais ou gráfico do Helm:

# Create namespace and install ArgoCD
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Or via Helm
helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd argo/argo-cd \
  --namespace argocd \
  --create-namespace \
  --set server.service.type=LoadBalancer

Definindo Aplicativos

ArgoCD usa um Application recurso personalizado para definir o que implantar e onde. Aqui está uma definição típica de aplicativo:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-web-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/k8s-manifests.git
    targetRevision: main
    path: apps/my-web-app/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

O syncPolicy.automated seção permite a sincronização automática. O prune opção remove recursos que não estão mais definidos no Git, enquanto selfHeal reverte alterações manuais feitas diretamente no cluster.

Flux CD: uma abordagem alternativa

O Flux CD adota uma abordagem arquitetural diferente para GitOps. Em vez de um servidor centralizado com uma UI, o Flux opera como um conjunto de controladores Kubernetes, cada um lidando com uma preocupação específica.

Componentes de fluxo

• Controlador de origem - Gerencia repositórios Git, repositórios Helm e fontes de artefatos OCI.
• Controlador personalizado - Aplica sobreposições Kustomize e manifestos YAML simples.
• Controlador de leme - Gerencia lançamentos de gráficos do Helm por meio de HelmRelease recursos personalizados.
• Controlador de Notificação - Lida com eventos de entrada e saída, integrando-se com Slack, Teams e provedores de webhook.
• Controladores de automação de imagem - Digitalize registros de contêineres e atualize manifestos quando novas imagens estiverem disponíveis.

Fluxo de inicialização

# Bootstrap Flux on a cluster with a GitHub repository
flux bootstrap github \
  --owner=myorg \
  --repository=fleet-infra \
  --branch=main \
  --path=clusters/production \
  --personal

# Define a HelmRelease
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx-ingress
  namespace: ingress-system
spec:
  interval: 5m
  chart:
    spec:
      chart: ingress-nginx
      version: "4.x"
      sourceRef:
        kind: HelmRepository
        name: ingress-nginx
        namespace: flux-system
  values:
    controller:
      replicaCount: 3
      metrics:
        enabled: true

ArgoCD vs Flux: quando escolher qual

O ArgoCD é ideal quando você precisa de uma interface de usuário da web avançada para visibilidade, multilocação com RBAC refinado e um plano de gerenciamento centralizado. O Flux brilha em ambientes que preferem uma arquitetura leve baseada em controlador, precisam de recursos de automação de imagem ou desejam uma integração mais profunda com o ecossistema Kubernetes API.

Gerenciamento de gráficos Helm em GitOps

Os gráficos Helm são o formato de empacotamento de fato para aplicativos Kubernetes. Em um fluxo de trabalho GitOps, o gerenciamento de valores do Helm em vários ambientes requer uma organização cuidadosa.

# Repository structure for multi-environment Helm management
k8s-manifests/
  base/
    my-app/
      Chart.yaml
      values.yaml          # Default values
      templates/
        deployment.yaml
        service.yaml
        ingress.yaml
  environments/
    dev/
      my-app/
        values.yaml        # Dev overrides
    staging/
      my-app/
        values.yaml        # Staging overrides
    production/
      my-app/
        values.yaml        # Production overrides

Tanto o ArgoCD quanto o Flux oferecem suporte nativo ao Helm. ArgoCD renderiza gráficos do lado do servidor por meio de seu servidor de repositório, enquanto o Flux usa o Helm SDK diretamente em seu Helm Controller.

Estratégias de implantação

A escolha da estratégia de implantação correta minimiza o risco e garante versões sem tempo de inatividade.

Atualizações contínuas

A estratégia Kubernetes padrão. Os pods são gradualmente substituídos por novas versões. Configurar maxSurge e maxUnavailable para controlar a velocidade de implementação.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
        - name: app
          image: myapp:v2.1.0
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

Implantações Azul-Verde

Execute dois ambientes idênticos (azul e verde). Implante a nova versão no ambiente inativo, verifique-a e alterne o tráfego. Isso fornece reversão instantânea, voltando para o ambiente anterior. Implemente com seletores de rótulos de serviço ou gerenciamento de tráfego do Istio.

Implantações Canário

Direcione gradualmente uma pequena porcentagem do tráfego para a nova versão, aumentando a porcentagem à medida que a confiança aumenta. Ferramentas como Flagger e Argo Rollouts automatizam a análise canário com promoção baseada em métricas.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 30
        - pause: { duration: 5m }
        - setWeight: 60
        - pause: { duration: 5m }
      canaryService: my-app-canary
      stableService: my-app-stable
      trafficRouting:
        istio:
          virtualService:
            name: my-app-vsvc
            routes:
              - primary

Reversões automatizadas

O GitOps simplifica as reversões: basta reverter o commit do Git. No entanto, reversões automatizadas baseadas em verificações de integridade fornecem uma rede de segurança adicional.

ArgoCD oferece suporte a reversões automatizadas por meio de seu sistema de sincronização e avaliação de integridade. Se um aplicativo entrar em um estado degradado após uma sincronização, o ArgoCD poderá reverter automaticamente para o último estado bom conhecido.

Para cenários de reversão mais sofisticados, Argo Rollouts e Flagger podem analisar métricas do Prometheus, executar testes automatizados e abortar implementações que mostram desempenho degradado.

Gerenciamento de segredos com segredos selados

Armazenar segredos no Git é um desafio crítico para o GitOps. Sealed Secrets resolve isso criptografando segredos que só podem ser descriptografados pelo controlador em execução no cluster de destino.

# Install Sealed Secrets controller
helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
helm install sealed-secrets sealed-secrets/sealed-secrets \
  --namespace kube-system

# Encrypt a secret
kubectl create secret generic db-credentials \
  --from-literal=username=admin \
  --from-literal=password=s3cure-p@ss \
  --dry-run=client -o yaml | \
  kubeseal --format yaml > db-credentials-sealed.yaml

O resultado SealedSecret recurso pode ser comprometido com segurança no Git. Somente o controlador Sealed Secrets no cluster de destino contém a chave privada necessária para descriptografá-lo. Abordagens alternativas incluem Operador de Segredos Externos (para extrair do AWS Secrets Manager, HashiCorp Vault, etc.) e SOPS para criptografia em nível de arquivo.

Monitorando implantações

A visibilidade do status de implantação é essencial para pipelines de produção de GitOps. Implementar monitoramento em vários níveis:

• Métricas ArgoCD - ArgoCD expõe métricas do Prometheus para status de sincronização, integridade e duração da operação. Crie painéis Grafana para rastrear a frequência de implantação e as taxas de falha.
• Eventos Kubernetes - Monitore eventos de agendamento de pod, extração de imagem e sondagem de prontidão para detectar problemas antecipadamente.
• Verificações de integridade do aplicativo - Configure verificações de integridade personalizadas no ArgoCD usando scripts Lua para definir o que "saudável" significa para seus recursos específicos.
• Alerta - Integre notificações do ArgoCD com Slack, PagerDuty ou e-mail para alertar sobre falhas de sincronização, degradação da saúde ou detecção de desvios.

# ArgoCD Notification ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  trigger.on-sync-failed: |
    - when: app.status.operationState.phase in ['Error', 'Failed']
      send: [slack-notification]
  template.slack-notification: |
    message: |
      Application {{.app.metadata.name}} sync {{.app.status.operationState.phase}}.
      Revision: {{.app.status.sync.revision}}
  service.slack: |
    token: $slack-token
    channel: deployments

Entrega multicluster

À medida que as organizações crescem, a implantação em vários clusters torna-se necessária. ArgoCD oferece suporte nativo ao gerenciamento de vários clusters, registrando clusters externos. O Flux consegue isso por meio de um cluster de gerenciamento que inicializa clusters de carga de trabalho.

O controlador ApplicationSet no ArgoCD é particularmente poderoso para cenários de vários clusters. Ele pode gerar recursos de aplicativos dinamicamente com base em listas de clusters, diretórios Git ou eventos de pull request.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-app-set
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: 'my-app-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/myorg/k8s-manifests.git
        targetRevision: main
        path: 'apps/my-app/overlays/{{metadata.labels.region}}'
      destination:
        server: '{{server}}'
        namespace: my-app

Conclusão

GitOps com ArgoCD ou Flux CD fornece uma base robusta para entrega contínua Kubernetes. Ao tratar o Git como a fonte da verdade, automatizando a reconciliação e aproveitando estratégias de entrega progressiva, as equipes podem implantar com confiança e se recuperar rapidamente de falhas. Comece com uma configuração simples de cluster único, estabeleça sua estrutura de repositório Git e adote gradualmente padrões avançados, como implantações canário, gerenciamento de vários clusters e políticas de reversão automatizadas à medida que sua plataforma amadurece.

O investimento na infraestrutura GitOps rende dividendos por meio de maior confiabilidade, resposta mais rápida a incidentes, trilhas de auditoria completas e uma experiência de desenvolvedor que torna as implantações tão simples quanto mesclar uma solicitação pull.