CI/CD con GitLab Runners y Kubernetes

El Paradigma de Kubernetes Executors#

En ecosistemas de ingeniería maduros, mantener instancias estáticas para la ejecución de pipelines genera cuellos de botella e ineficiencias en el consumo de recursos. La integración de GitLab Runners con Kubernetes (K8s) mediante el Kubernetes Executor resuelve este problema aprovisionando pods efímeros bajo demanda para cada trabajo de CI/CD, garantizando aislamiento total, escalabilidad elástica y un uso óptimo del clúster.

Despliegue del Runner mediante Helm

El método estándar y recomendado para instalar GitLab Runner en un clúster Kubernetes es a través de su chart oficial de Helm. Esto permite gestionar la configuración como código y facilitar actualizaciones (GitOps).

Primero, debemos configurar el archivo values.yaml para personalizar el comportamiento del Runner. Es crucial definir el RBAC (Role-Based Access Control) adecuado para que el Runner pueda spawnear nuevos pods.

# gitlab-runner-values.yaml
gitlabUrl: https://gitlab.com/
runnerRegistrationToken: "TOKEN_SECRETO_GENERADO_EN_GITLAB"
concurrent: 50
checkInterval: 3
logLevel: info

rbac:
  create: true
  clusterWideAccess: false

runners:
  config: |
    [[runners]]
      name = "k8s-runner-forgenex"
      executor = "kubernetes"
      [runners.kubernetes]
        namespace = "gitlab-runners"
        image = "alpine:latest"
        cpu_limit = "2"
        memory_limit = "4Gi"
        service_cpu_limit = "1"
        service_memory_limit = "2Gi"
        helper_cpu_limit = "500m"
        helper_memory_limit = "1Gi"
        poll_timeout = 600
        [[runners.kubernetes.volumes.pvc]]
          name = "maven-cache-pvc"
          mount_path = "/root/.m2"

Nota Importante: Observa el uso de volumes.pvc en la configuración. Montar un Persistent Volume Claim para la caché (como las dependencias de Maven o NPM) en los pods efímeros reduce drásticamente el tiempo de compilación entre ejecuciones de pipelines.

Para instalar el chart, ejecutamos:

helm repo add gitlab https://charts.gitlab.io
helm repo update

helm install --namespace gitlab-runners --create-namespace \
  forgenex-runner gitlab/gitlab-runner -f gitlab-runner-values.yaml

Estructuración del Pipeline (.gitlab-ci.yml)#

Con el Runner operando en K8s, cada job definido en el .gitlab-ci.yml se ejecutará en un contenedor aislado. Para exprimir al máximo esta arquitectura, emplearemos el patrón Docker-in-Docker (DinD) para compilar y pushear imágenes de contenedores desde dentro de Kubernetes, o herramientas daemonless como Kaniko.

A continuación, una estrategia de despliegue usando Kaniko, que evita los riesgos de seguridad asociados a montar el socket de Docker (/var/run/docker.sock) en Kubernetes:

stages:
  - test
  - build
  - deploy

variables:
  DOCKER_REGISTRY: "registry.gitlab.com"
  IMAGE_TAG: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"

sonarqube-check:
  stage: test
  image: maven:3.8.4-openjdk-17
  script:
    - mvn verify sonar:sonar -Dsonar.projectKey=forgenex-core
  tags:
    - k8s-runner-forgenex

build-container:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  script:
    - mkdir -p /kaniko/.docker
    - echo "{\"auths\":{\"$DOCKER_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $IMAGE_TAG
  tags:
    - k8s-runner-forgenex

deploy-to-k8s:
  stage: deploy
  image: bitnami/kubectl:latest
  script:
    - kubectl set image deployment/forgenex-api api=$IMAGE_TAG --namespace production
    - kubectl rollout status deployment/forgenex-api --namespace production
  environment:
    name: production
  tags:
    - k8s-runner-forgenex

Seguridad y Aislamiento

Nota Importante: Nunca otorgues permisos de cluster-admin al ServiceAccount del GitLab Runner a menos que sea estrictamente necesario. Restringe el acceso (clusterWideAccess: false) a namespaces específicos para prevenir escalada de privilegios si el entorno de CI se ve comprometido.

La sinergia entre GitLab CI y Kubernetes proporciona una infraestructura de construcción altamente resiliente. Al efimerizar los entornos de build, eliminamos el "snowflaking" de servidores CI tradicionales, asegurando que cada compilación parta de un estado limpio y determinista.