Entrega continua de Kubernetes: canalizaciones de GitOps con ArgoCD y Flux

La entrega continua en Kubernetes ha evolucionado mucho más allá de lo simple kubectl apply comandos. Los equipos modernos están adoptando GitOps, un paradigma que utiliza Git como única fuente de verdad para la infraestructura declarativa y la configuración de aplicaciones. Al combinar los principios de GitOps con herramientas como ArgoCD y Flux CD, las organizaciones pueden lograr procesos de implementación confiables, auditables y automatizados que se escalan en clústeres y entornos.

Esta guía cubre la arquitectura, la configuración y las mejores prácticas para crear canales de entrega continua de nivel de producción en Kubernetes utilizando el enfoque GitOps.

Principios de GitOps

GitOps se basa en cuatro principios básicos que cambian fundamentalmente la forma en que los equipos gestionan las implementaciones:

• Configuración declarativa - Todo el estado deseado de su sistema se describe de forma declarativa. Para Kubernetes, esto significa manifiestos YAML, gráficos Helm o superposiciones de Kustomize almacenados en Git.
• Versión controlada - Git sirve como única fuente de verdad. Cada cambio pasa por una solicitud de extracción, lo que proporciona un seguimiento de auditoría completo y permite reversiones sencillas al revertir las confirmaciones.
• Conciliación automatizada - Un agente que se ejecuta en el clúster compara continuamente el estado deseado en Git con el estado real en el clúster y concilia automáticamente cualquier desviación.
• Observación continua - El sistema monitorea continuamente tanto el repositorio Git como el estado del clúster, alertando sobre divergencias y asegurando que el clúster siempre coincida con la configuración declarada.

Estos principios eliminan los pasos de implementación manual, reducen los errores humanos y proporcionan un flujo de trabajo consistente independientemente de la complejidad del clúster.

Arquitectura y configuración de ArgoCD

ArgoCD es la herramienta GitOps más adoptada para Kubernetes. Proporciona una potente interfaz de usuario web, CLI y API para gestionar implementaciones de aplicaciones en clústeres.

Componentes principales

ArgoCD consta de varios componentes clave que funcionan juntos:

• Servidor API - Expone un gRPC/REST API y sirve la interfaz de usuario web. Maneja la autenticación, RBAC y las integraciones externas.
• Servidor de repositorio - Clona repositorios de Git y genera manifiestos Kubernetes a partir de gráficos de Helm, Kustomize o YAML simple.
• Controlador de aplicaciones - Supervisa continuamente las aplicaciones en ejecución y compara el estado activo con el estado deseado en Git.
• Redis - Proporciona almacenamiento en caché para el servidor del repositorio y el controlador de aplicaciones.

Instalación

Implemente ArgoCD en su clúster utilizando los manifiestos oficiales o el gráfico 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

Definición de aplicaciones

ArgoCD utiliza un Application recurso personalizado para definir qué implementar y dónde. A continuación se muestra una definición de aplicación típica:

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

El syncPolicy.automated La sección permite la sincronización automática. El prune La opción elimina recursos que ya no están definidos en Git, mientras que selfHeal devierte los cambios manuales realizados directamente en el clúster.

Flux CD: un enfoque alternativo

Flux CD adopta un enfoque arquitectónico diferente a GitOps. En lugar de un servidor centralizado con una interfaz de usuario, Flux opera como un conjunto de controladores Kubernetes, cada uno de los cuales maneja una preocupación específica.

Componentes de fundente

• Controlador de fuente - Gestiona repositorios Git, repositorios Helm y fuentes de artefactos OCI.
• Personalizar controlador - Aplica superposiciones de Kustomize y manifiestos YAML simples.
• Controlador de timón - Gestiona los lanzamientos de gráficos de Helm a través de HelmRelease recursos personalizados.
• Controlador de notificaciones - Maneja eventos entrantes y salientes, integrándose con Slack, Teams y proveedores de webhooks.
• Controladores de automatización de imágenes - Escanear registros de contenedores y actualizar manifiestos cuando haya nuevas imágenes disponibles.

Arranque de flujo

# 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: cuándo elegir cuál

ArgoCD es ideal cuando necesita una interfaz de usuario web rica para visibilidad, multiinquilino con RBAC detallado y un plano de administración centralizado. Flux brilla en entornos que prefieren una arquitectura liviana basada en controladores, necesitan capacidades de automatización de imágenes o desean una integración más profunda con el ecosistema Kubernetes API.

Gestión de gráficos de timón en GitOps

Los gráficos de timón son el formato de empaquetado de facto para aplicaciones Kubernetes. En un flujo de trabajo de GitOps, administrar los valores de Helm en todos los entornos requiere una organización 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 ArgoCD como Flux son compatibles con Helm de forma nativa. ArgoCD representa gráficos del lado del servidor a través de su servidor de repositorio, mientras que Flux usa el Helm SDK directamente dentro de su Helm Controller.

Estrategias de implementación

Elegir la estrategia de implementación adecuada minimiza el riesgo y garantiza lanzamientos sin tiempo de inactividad.

Actualizaciones continuas

La estrategia Kubernetes predeterminada. Los pods se reemplazan gradualmente con nuevas versiones. Configurar maxSurge y maxUnavailable para controlar la velocidad de despliegue.

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

Implementaciones azul-verde

Ejecute dos entornos idénticos (azul y verde). Implemente la nueva versión en el entorno inactivo, verifíquela y luego cambie el tráfico. Esto proporciona una reversión instantánea al volver al entorno anterior. Implemente con selectores de etiquetas de servicio o gestión de tráfico de Istio.

Implementaciones canarias

Enrute gradualmente un pequeño porcentaje del tráfico a la nueva versión, aumentando el porcentaje a medida que crece la confianza. Herramientas como Flagger y Argo Rollouts automatizan el análisis canary con promoción basada en 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

Reversiones automatizadas

GitOps hace que las reversiones sean sencillas: simplemente revierta la confirmación de Git. Sin embargo, las reversiones automatizadas basadas en controles de estado proporcionan una red de seguridad adicional.

ArgoCD admite reversiones automatizadas a través de su sistema de sincronización y evaluación de estado. Si una aplicación entra en un estado degradado después de una sincronización, ArgoCD puede retroceder automáticamente al último estado bueno conocido.

Para escenarios de reversión más sofisticados, Argo Rollouts y Flagger pueden analizar métricas de Prometheus, ejecutar pruebas automatizadas y cancelar implementaciones que muestren un rendimiento degradado.

Gestión de secretos con secretos sellados

Almacenar secretos en Git es un desafío crítico para GitOps. Sealed Secrets resuelve este problema cifrando secretos que solo puede descifrar el controlador que se ejecuta en el clúster 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

El resultado SealedSecret El recurso se puede enviar de forma segura a Git. Solo el controlador de Sealed Secrets en el clúster de destino posee la clave privada necesaria para descifrarlo. Los enfoques alternativos incluyen el Operador de secretos externos (para extraer de AWS Secrets Manager, HashiCorp Vault, etc.) y SOPS para el cifrado a nivel de archivos.

Monitoreo de implementaciones

La visibilidad del estado de implementación es esencial para los canales de producción de GitOps. Implementar el monitoreo en múltiples niveles:

• Métricas de ArgoCD - ArgoCD expone métricas de Prometheus para el estado de sincronización, el estado y la duración de la operación. Cree paneles de Grafana para realizar un seguimiento de la frecuencia de implementación y las tasas de falla.
• Eventos Kubernetes - Supervise la programación de pods, la extracción de imágenes y los eventos de sondeo de preparación para detectar problemas de manera temprana.
• Comprobaciones de estado de la aplicación - Configure controles de estado personalizados en ArgoCD usando scripts Lua para definir qué significa "saludable" para sus recursos específicos.
• alertando - Integre las notificaciones de ArgoCD con Slack, PagerDuty o correo electrónico para alertar sobre fallas de sincronización, degradación del estado o detección de desviaciones.

# 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 de múltiples clústeres

A medida que las organizaciones escalan, se hace necesaria la implementación en múltiples clústeres. ArgoCD admite la gestión de múltiples clústeres de forma nativa mediante el registro de clústeres externos. Flux logra esto a través de un clúster de administración que inicia los clústeres de cargas de trabajo.

El controlador ApplicationSet en ArgoCD es particularmente poderoso para escenarios de múltiples clústeres. Puede generar recursos de aplicaciones de forma dinámica en función de listas de clústeres, directorios de Git o eventos de solicitud de extracción.

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

Conclusión

GitOps con ArgoCD o Flux CD proporciona una base sólida para la entrega continua de Kubernetes. Al tratar a Git como la fuente de la verdad, automatizar la conciliación y aprovechar estrategias de entrega progresiva, los equipos pueden implementar con confianza y recuperarse de las fallas rápidamente. Comience con una configuración simple de un solo clúster, establezca su estructura de repositorio Git y adopte gradualmente patrones avanzados como implementaciones canary, administración de múltiples clústeres y políticas de reversión automatizadas a medida que su plataforma madure.

La inversión en infraestructura GitOps rinde dividendos a través de una confiabilidad mejorada, una respuesta a incidentes más rápida, pistas de auditoría completas y una experiencia de desarrollador que hace que las implementaciones sean tan simples como fusionar una solicitud de extracción.