Cómo crear un Blue/Green Deploy en Kubernetes con GitHub Actions

Este tutorial explica cómo crear un Blue/Green deploy en Kubernetes con GitHub Actions — una estrategia útil para reducir tiempo de indisponibilidad, validar nuevas versiones en producción y permitir rollback rápido. Verás por qué el patrón Blue/Green es práctico y un ejemplo sencillo para implementar con manifests y un workflow CI/CD.

Pre-requisitos

• Cuenta GitHub con repositorio y GitHub Actions activado
• Cluster Kubernetes accesible (minikube, kind o AKS) y kubectl configurado
• Imagen Docker pública o registrada (p. ej.: myrepo/myapp:latest)
• Familiaridad básica con Kubernetes Deployments y Services

Paso 1: Entender el patrón Blue/Green

Blue/Green significa tener dos versiones concurrentes de la aplicación: "blue" (actual) y "green" (nueva). El tráfico se conmuta cambiando el selector del Service o modificando un ingress. Esto permite probar la versión green en producción sin eliminar la blue y volver atrás rápidamente.

Paso 2: Estructurar los manifests Kubernetes

Vamos a crear dos Deployments (app-blue y app-green) y un Service que apunta a una label común (app: myapp) pero cuyo selector decide qué versión recibe el tráfico. En el ejemplo el Service usa la label track: blue o track: green.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
      track: blue
  template:
    metadata:
      labels:
        app: myapp
        track: blue
    spec:
      containers:
      - name: app
        image: myrepo/myapp:stable
        ports:
        - containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
      track: green
  template:
    metadata:
      labels:
        app: myapp
        track: green
    spec:
      containers:
      - name: app
        image: myrepo/myapp:canary
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: myapp
    track: blue

Paso 3: Probar localmente en el cluster

Aplica los manifests y confirma que el Service apunta al deployment blue. Valida mediante kubectl y, si usas minikube, accede al servicio para ver la página de la aplicación.

# aplicar manifests
kubectl apply -f k8s/blue-green.yaml
# ver pods y service
kubectl get deployments,pods,svc -l app=myapp
# probar endpoint (ejemplo minikube)
minikube service myapp-service --url

Paso 4: Crear workflow GitHub Actions para deploy controlado

El workflow realiza el build de la imagen, hace push y actualiza el Deployment green. Después ejecuta un paso para conmutar el Service de blue a green. Separar pasos permite validar la versión antes del cutover.

name: CI CD BlueGreen
on:
  push:
    branches: [ main ]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout
      uses: actions/checkout@v4

    - name: Build and push image
      run: |
        IMAGE=myrepo/myapp:${{ github.sha }}
        docker build -t $IMAGE .
        echo "$IMAGE"
        docker push $IMAGE
      env:
        DOCKER_HUB_USERNAME: ${{ secrets.DOCKER_HUB_USERNAME }}
        DOCKER_HUB_PASSWORD: ${{ secrets.DOCKER_HUB_PASSWORD }}

    - name: Update green Deployment image
      run: |
        kubectl set image deployment/app-green app=$IMAGE --record
      env:
        KUBECONFIG: ${{ secrets.KUBECONFIG }}

    - name: Smoke tests on green
      run: |
        # Ejemplo sencillo: verificar pods listos
        kubectl rollout status deployment/app-green --timeout=60s
        kubectl get pods -l track=green
      env:
        KUBECONFIG: ${{ secrets.KUBECONFIG }}

    - name: Switch Service to green (cutover)
      if: success()
      run: |
        kubectl patch service myapp-service -p '{"spec":{"selector":{"app":"myapp","track":"green"}}}'
      env:
        KUBECONFIG: ${{ secrets.KUBECONFIG }}

Paso 5: Estrategias de rollback y limpieza

Si algo va mal después del cutover, vuelve a apuntar el Service a track: blue. Puedes automatizar el rollback si los smoke tests fallan o usar monitorización para detectar errores. Tras estar estable, puedes reducir la escala del deployment blue o eliminarlo.

# rollback manual (apuntar de vuelta a blue)
kubectl patch service myapp-service -p '{"spec":{"selector":{"app":"myapp","track":"blue"}}}'
# eliminar la versión antigua cuando esté confirmada
kubectl delete deployment app-blue

Verificar el resultado

Confirma que el Service sirve la nueva versión: realiza una petición al endpoint y valida headers, versión o contenido. Usa kubectl get svc y kubectl get pods -l track=green para verificar que el tráfico está en la green. Monitoriza logs para errores y valida métricas.

Conclusión

Implementar Blue/Green deploy en Kubernetes con GitHub Actions reduce riesgo y facilita rollback. Próximos pasos: añadir health checks, automatizar la verificación de rendimiento e integrar monitorización (Prometheus/Alertmanager). Consejo: comienza con minikube o kind para experimentar antes de aplicar en producción — ¿cuál es el próximo servicio que quieres lanzar con Blue/Green?