CI dentro de Kubernetes: Tekton, Argo Workflows y cuándo no hacerlo

En cuanto un equipo de plataforma opera Kubernetes, alguien propone ejecutar ahí también la CI. El razonamiento se sostiene: el planificador ya hace empaquetado, autoescalado y aislamiento, y una compilación no es más que un pod. ¿Para qué mantener un sistema aparte que reimplementa todo eso?

Es una opción real y, para ciertas cargas, claramente la correcta. También es la opción que más a menudo se adopta por el motivo equivocado.

Qué son las dos herramientas

Tekton modela la CI como recursos de Kubernetes: un Step es un contenedor, una Task es una secuencia de pasos en un pod, un Pipeline conecta Tasks en un grafo y un PipelineRun es una ejecución. No hay DSL propio: es YAML y CRD, así que kubectl, RBAC, control de admisión y tu flujo de GitOps actual aplican directamente.

apiVersion: tekton.dev/v1
kind: Task
metadata: { name: build-image }
spec:
  params: [{ name: image }]
  workspaces: [{ name: source }]
  steps:
    - name: build
      image: gcr.io/kaniko-project/executor:latest
      args: ["--dockerfile=Dockerfile", "--context=$(workspaces.source.path)",
             "--destination=$(params.image)", "--cache=true"]

Argo Workflows es un motor de grafos dirigidos para contenedores que resulta utilizable para CI. Su punto fuerte es el despliegue en abanico: pasos que generan una lista de elementos y ejecutan un contenedor por elemento, pasándose artefactos. Si tu pipeline en realidad es un proceso por lotes —procesar 400 entradas y agregar—, Argo Workflows encaja mucho mejor que cualquier producto de CI.

Los dos te dan: cada paso en su contenedor con su imagen, peticiones de recursos a nivel de pod, autoescalado nativo, ninguna flota de runners que mantener aparte y pipelines que viven en git como manifiestos que tu controlador de GitOps ya reconcilia.

Qué pierdes

Experiencia de desarrollo. El YAML de Tekton es verboso de una forma que un .gitlab-ci.yml no lo es, y un fallo de compilación se depura leyendo logs de pods en vez de en una interfaz pensada para ello. El panel de Tekton y la interfaz de Argo son funcionales, no agradables. A la mayoría de desarrolladores no les va a gustar escribir esto, así que los pipelines acaban siendo propiedad del equipo de plataforma, que puede ser lo que quieres o puede ser un cuello de botella.

El ecosistema. No hay marketplace de integraciones listas. La notificación a Slack, la puerta de despliegue y el informe de tests los escribes tú, o los montas a partir de imágenes de contenedor. Tekton Hub ayuda un poco; no es el marketplace de Actions.

La integración con el código. Disparar con una pull request, devolver el estado al commit, tratar con seguridad las PR desde forks: todo eso viene incorporado en Actions y GitLab CI y aquí es problema tuyo. Tekton Triggers te da el receptor de webhooks; el resto es configuración tuya.

Alguien tiene que operarlo. Has cambiado un servicio de CI gestionado por un controlador en tu clúster que necesita actualizaciones, un endpoint de webhook que debe ser alcanzable y estar protegido, y almacenamiento de logs y artefactos que aprovisionas tú.

Cuándo es la decisión correcta

• Tus pipelines de esa carga ya son jobs de Kubernetes de todos modos. Entrenamiento de modelos, procesado de datos, lotes paralelos grandes: Argo Workflows es la herramienta correcta y llamarlo CI es accesorio.
• Estás construyendo una plataforma, no solo pipelines. Si ofreces un camino dorado a cincuenta equipos internos y quieres pipelines compuestos y gobernados por tu propio controlador, el modelo de CRD de Tekton es una base. Varias plataformas internas de desarrollo están construidas así.
• Requisitos de aislamiento o soberanía que descartan un plano de control SaaS y donde ya estás comprometido con operar Kubernetes.
• Entornos de compilación heterogéneos: un pipeline donde cada paso necesita una imagen y un perfil de recursos completamente distintos es justo lo que este modelo expresa bien.

Cuándo no lo es

Si tu objetivo es "compilar un contenedor, pasar tests, desplegar" para veinte microservicios, y tu código está en GitHub o GitLab, usa la CI que vino con tu forja y pon runners autoalojados sobre el clúster de Kubernetes. Obtienes el mismo empaquetado y el mismo autoescalado, con la integración con el código y la experiencia de desarrollo ya hechas. Esta es la respuesta para la mayoría de quien se hace la pregunta, y la vía del runner sobre Kubernetes es una fracción del trabajo operativo.

El patrón que más vemos en la práctica es un reparto: la CI de la forja se encarga de compilar y probar, y Argo Workflows o Tekton se encargan de los pipelines que en realidad son cómputo por lotes. Cada lado hace lo que sabe hacer y a ninguno se le fuerza una forma que no le corresponde.

Vayas por donde vayas, la postura de seguridad es la misma que la de cualquier CI sobre infraestructura compartida: pods efímeros, sin credenciales ambientales del nodo, federación OIDC para el acceso a la nube y un espacio de nombres que no comparta con nada más.