Terraform, Helm, GitOps... ¿para entrenar modelos? Sí.
Hoy: Cómo gestionar todo eso como código.
El problema:
Tienes tu stack de Platform Engineering:
Y ahora llega ML al juego.
Primera reacción: "Solo es otra aplicación, ¿no?"
Spoiler: No.
Lo que descubrí:
ML no es una aplicación más. Es un ecosistema completo que necesita:
Infraestructura tradicional:
Compute (K8s clusters, VMs)
Storage (S3, persistent volumes)
Networking (load balancers, ingress)
PERO TAMBIÉN infraestructura específica de ML:
Feature stores
Model registries
Experiment tracking
Data versioning
Training pipelines
Serving infrastructure
Y todo debe ser código. Reproducible. Versionado. Con GitOps.
Los 4 niveles de IaC para MLOps:
Terraform es el ganador indiscutible, pero existen AWS CDK, Pulumi que son dignos competidores.
Nivel 1: Infraestructura base (Fundational)
resource "aws_eks_cluster" "ml_cluster" {
name = "ml-${var.environment}"
role_arn = aws_iam_role.ml_cluster.arn
vpc_config {
subnet_ids = var.private_subnets
}
}
resource "aws_eks_node_group" "gpu_nodes" {
cluster_name = aws_eks_cluster.ml_cluster.name
node_group_name = "gpu-nodes"
instance_types = ["p3.2xlarge"]
scaling_config {
desired_size = 2
max_size = 10
min_size = 0
}
}
resource "aws_s3_bucket" "ml_data" {
bucket = "ml-data-${var.environment}"
versioning {
enabled = true
}
}
Esto es familiar. Es Terraform normal.
yaml
mlflow:
enabled: true
backend_store: postgresql
artifact_store: s3://ml-artifacts-prod
kubeflow:
enabled: true
pipelines:
persistence:
storageClass: gp3
size: 100Gi
seldon:
enabled: true
replicas: 3
resources:
limits:
nvidia.com/gpu: 1
Esto es donde Platform Engineering y ML se encuentran.
Nivel 3: Training pipelines como código
yaml
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
name: training-pipeline
spec:
entrypoint: train-model
arguments:
parameters:
- name: dataset-version
value: "v2.3.1"
- name: environment
value: "staging"
templates:
- name: train-model
steps:
- - name: ingest-data
template: ingest
- - name: validate-data
template: validate
- - name: train
template: training
- - name: evaluate
template: evaluation
- - name: register
template: model-registration
- name: ingest
container:
image: ml-pipeline/ingest:{{workflow.parameters.dataset-version}}
command: [python, ingest.py]
env:
- name: DATASET_VERSION
value: "{{workflow.parameters.dataset-version}}"
- name: S3_BUCKET
value: "ml-data-{{workflow.parameters.environment}}"
Aquí es donde todo se conecta: infra + pipelines + GitOps.
Nivel 4: GitOps para ML
Y como saben, en este lugar somos GitOps Frendly
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: ml-platform
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/company/ml-platform
targetRevision: main
path: k8s/
helm:
values: |
environment: staging
mlflow:
enabled: true
version: "2.9.0"
training_pipelines:
schedule: "0 2 * * 0"
resources:
gpu: true
memory: 32Gi
destination:
server: https://kubernetes.default.svc
namespace: ml-staging
syncPolicy:
automated:
prune: true
selfHeal: true
Commit → Push → ArgoCD sync → Pipeline deployed.
Igual que tus otras aplicaciones. Pero para ML.
La integración completa:
┌─────────────────────────────────────────────────┐
│ Git Repository │
│ │
│ terraform/ → Infra base │
│ helm/ → ML platform │
│ pipelines/ → Training workflows │
│ models/ → Model definitions │
└─────────────┬───────────────────────────────────┘
│
│ git push
│
┌────────▼────────┐
│ CI Pipeline │
│ │
│ - Validate │
│ - Test │
│ - Build images │
└────────┬────────┘
│
│ if tests pass
│
┌────────▼────────┐
│ ArgoCD │
│ │
│ - Sync infra │
│ - Deploy ML │
│ - Trigger │
└────────┬────────┘
│
│
┌────────▼─────────────────────────────┐
│ Kubernetes │
│ │
│ - ML Platform running │
│ - Pipelines scheduled │
│ - Models serving │
└──────────────────────────────────────┘
Ejemplo real: Deploy de un nuevo modelo
Antes (manual):
bash
ssh ml-cluster-prod
kubectl apply -f model-deployment.yaml
kubectl get pods -w
kubectl rollback deployment/model-server
Ahora (GitOps):
bash
cat > k8s/model-deployment.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: model-server
spec:
template:
spec:
containers:
- name: model
image: models/fraud-detection:v2.3.1
EOF
git add k8s/model-deployment.yaml
git commit -m "Deploy model v2.3.1 to staging"
git push
Los componentes clave:
Terraform para infraestructura:
hcl
module "ml_platform" {
source = "./modules/ml-platform"
environment = var.environment
gpu_nodes = 4
cpu_nodes = 10
data_bucket = "ml-data-${var.environment}"
model_bucket = "ml-models-${var.environment}"
vpc_id = module.vpc.vpc_id
mlflow_backend = module.rds.endpoint
feature_store = "enabled"
model_registry = "enabled"
}
Helm para componentes de ML:
yaml
dependencies:
- name: mlflow
version: "0.7.0"
repository: https://charts.mlflow.org
- name: kubeflow-pipelines
version: "2.0.0"
repository: https://kubeflow.github.io/pipelines
- name: seldon-core
version: "1.15.0"
repository: https://storage.googleapis.com/seldon-charts
ArgoCD para sincronización:
yaml
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
retry:
limit: 5
backoff:
duration: 5s
factor: 2
maxDuration: 3m
CI/CD para pipelines:
name: ML Pipeline CI
on:
push:
paths:
- 'pipelines/**'
- 'models/**'
jobs:
validate:
runs-on: ubuntu-latest
steps:
- name: Validate pipeline syntax
run: |
argo lint pipelines/training-pipeline.yaml
- name: Test with sample data
run: |
pytest tests/pipeline_test.py
- name: Build container images
run: |
docker build -t ml-pipeline/ingest:${{ github.sha }}
Los desafíos específicos de IaC para ML:
DESAFÍO 1: State management para modelos
Software tradicional:
- Deploy nueva versión
- Old version se borra
ML:
- Deploy modelo v2
- Modelo v1 sigue sirviendo (A/B testing)
- Modelo v0 en rollback standby
- ¿Cómo manejas state?
Solución:
hcl
resource "kubernetes_deployment" "model" {
for_each = var.model_versions
metadata {
name = "model-${each.key}"
}
spec {
replicas = each.value.traffic_percentage > 0 ? 2 : 0
}
}
DESAFÍO 2: Recursos dinámicos
Training pipeline necesita:
- 8 GPUs por 4 horas
- Después, scale a 0
Serving necesita:
- 2 GPUs 24/7
- Auto-scale basado en requests
Solución:
yaml
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
name: gpu-training
spec:
requirements:
- key: node.kubernetes.io/instance-type
operator: In
values: ["p3.2xlarge", "p3.8xlarge"]
ttlSecondsAfterEmpty: 300
limits:
resources:
nvidia.com/gpu: 32
DESAFÍO 3: Data versioning en IaC
Código: Git
Containers: Registry
Infraestructura: Terraform state
¿Datasets de gigantes?
Solución:
yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: dvc-config
data:
.dvc/config: |
[core]
remote = s3
['remote "s3"']
url = s3://ml-data-prod/dvc-cache
- name: fetch-data
container:
image: dvc:latest
command: [dvc, pull, data/training.dvc]
env:
- name: DVC_REMOTE
value: s3
Stack completo recomendado:
Infrastructure Layer:
├── Terraform → Cloud resources (K8s, S3, RDS)
├── Helm → ML platform components
└── ArgoCD → GitOps sync
ML Platform Layer:
├── MLflow → Experiment tracking
├── DVC → Data versioning
├── Kubeflow/Airflow → Pipeline orchestration
└── Seldon/KServe → Model serving
Pipeline Layer:
├── Argo Workflows → Training execution
├── GitHub Actions → CI/CD
└── Prometheus → Monitoring
Data Layer:
├── S3/GCS → Data lake
├── PostgreSQL → Metadata
└── Feature Store → Feature management
Mi workflow real:
1. Definir infra (Terraform):
bash
cd terraform/environments/staging
terraform plan
terraform apply
2. Deploy ML platform (Helm + ArgoCD):
bash
git add helm/ml-platform/
git commit -m "Deploy MLflow + Kubeflow to staging"
git push
3. Definir pipeline (YAML):
bash
git add pipelines/training-v2.yaml
git commit -m "Update training pipeline"
git push
4. Trigger entrenamiento:
bash
argo submit pipelines/training-v2.yaml \
--parameter dataset-version=v2.3.1
5. Deploy modelo (GitOps):
git add k8s/model-server.yaml
git commit -m "Deploy model v2.3.1"
git push
Todo como código. Todo en Git. Todo reproducible.
Los errores que he visto:
ERROR 1: "Infra manual, pipelines automatizados"
Resultado: Pipelines automatizados corriendo en infra manual
Alguien borra el cluster por error
Pipelines fallan, nadie sabe cómo reconstruir
ERROR 2: "Terraform para todo, incluso modelos"
Resultado: Model registry en Terraform state
Deploy nuevo modelo = terraform apply (lento)
Rollback = terraform plan/apply (muy lento)
No es el tool correcto para esto
ERROR 3: "GitOps sin CI"
Resultado: Push directo a main sin validación
Pipeline syntax error deployado a prod
Cluster crashea
ERROR 4: "IaC solo en prod"
Resultado: Dev y staging son snowflakes
"Funciona en mi máquina" nivel infraestructura
Debugging imposible
Mi recomendación pragmática:
Fase 1 - Infra as Code:
- Terraform para cluster base
- Manual deploy de ML platform
- Scripts para pipelines
Fase 2 - Platform as Code:
- Helm para ML components
- CI/CD para validación
- Semi-automated deploys
Fase 3 - Everything as Code:
- Full GitOps con ArgoCD
- Pipelines como YAML en Git
- Automated canary deploys
Empieza en Fase 1. Evoluciona cuando necesites escalar.
