Carbon-aware scheduling por defecto: primer balance

Actualizado: 2026-05-03

Hace dos años, el carbon-aware scheduling era experimental y activado manualmente por equipos motivados por sostenibilidad o presión regulatoria. Con varias distribuciones de Kubernetes y plataformas gestionadas incorporándolo como opción por defecto o muy visible, toca evaluar si la promesa se cumple en la práctica. La hipótesis de base, que decidir dónde y cuándo ejecutar cargas según la intensidad de carbono de la red eléctrica reduce emisiones sin penalizar rendimiento significativamente, ha tenido tiempo suficiente para probarse y generar datos reales.

Puntos clave

• El beneficio es proporcional a qué fracción de tu carga es elástica en tiempo o geografía; si menos del 20% lo es, el ahorro total del cluster será modesto.
• Los mejores resultados (15-30% de reducción de intensidad de carbono) se logran con cargas diferibles: batch nocturno, entrenamiento de modelos, compilación y testing de CI, generación de informes, renderizado de vídeo.
• Las métricas de Kepler tienen un error conocido de hasta 20% en cargas mixtas; interpretar sus cifras como indicaciones, no como verdades exactas.
• Mover cargas a regiones lejanas con mejor mix puede aumentar emisiones netas si el tráfico de datos entre centros crece notablemente.
• Los fundamentos importan más: arquitectura eficiente, rightsizing, apagado de infraestructura ociosa y selección de hardware eficiente producen ahorros típicamente mayores que carbon-aware solo.

Qué es carbon-aware scheduling

La idea fundamental es simple. La intensidad de carbono de la electricidad (gramos de CO2 por kilovatio hora) varía significativamente a lo largo del día y entre regiones, según qué fuentes estén generando en cada momento. Las redes con mucha eólica o solar tienen períodos de alta limpieza cuando hace viento o sol, y períodos de alta suciedad cuando dominan gas y carbón. Mover cargas elásticas a regiones o horas más limpias reduce emisiones sin cambiar la cantidad de trabajo hecho.

El patrón técnico consolidado combina varios componentes:

• Un medidor de consumo energético por carga — Kepler para Kubernetes es la referencia abierta.
• Una fuente de datos de intensidad de carbono en tiempo real — Electricity Maps, WattTime, APIs de proveedores.
• Un planificador que integra esta información — kube-scheduler con extensiones carbon-aware, o Karpenter con políticas específicas.
• Métricas de seguimiento que permiten verificar impacto real.

Google Cloud, Azure y AWS han integrado carbon-aware en sus servicios gestionados durante 2024 y 2025. El ecosistema abierto, con Kepler graduado en CNCF a finales de 2024 y Green Software Foundation aportando estándares (Software Carbon Intensity, SCI), permite implementar el patrón también sobre infraestructura propia.

Dónde ha funcionado mejor

Los casos donde el carbon-aware scheduling ha aportado reducciones reales de emisiones tienen un patrón común: cargas de trabajo que toleran flexibilidad temporal o geográfica sin degradar experiencia del usuario. Tipos que funcionan:

• Procesamiento batch nocturno.
• Entrenamiento de modelos de aprendizaje.
• Compilación y testing de código en CI.
• Generación de informes y analítica.
• Renderizado de vídeo.

Estas cargas se pueden retrasar unas horas o mover entre regiones sin que nadie se dé cuenta. En estos escenarios, empresas que han adoptado carbon-aware con seriedad reportan reducciones reales de emisiones entre 15 y 30 por ciento según el caso.

Un ejemplo concreto: un entrenamiento diario de modelos de personalización en una empresa de e-commerce, con un trabajo de varias horas sin SLA de horario. Moviendo su ejecución automáticamente a la ventana más limpia del día (normalmente entre tarde y noche cuando la solar todavía genera y la demanda baja) se reduce la intensidad de carbono del trabajo alrededor del veinte por ciento respecto a ejecutarlo por la mañana.

Otro caso interesante son trabajos de CI distribuidos entre regiones geográficas. Para un equipo con miles de builds al mes, si Estocolmo está con hidroeléctrica al máximo y Dublín con eólica fuerte, el job va allí en vez de a una región con mix de carbón. Las reducciones acumuladas a lo largo del año son medibles y el coste operativo adicional es prácticamente nulo.

Dónde el ahorro es marginal o inexistente

El otro lado de la historia son los casos donde carbon-aware scheduling aporta muy poco o nada. Aplicaciones en línea con usuarios activos no se pueden mover geográficamente sin añadir latencia, y no se pueden retrasar sin degradar experiencia. APIs de producción, servicios web orientados a tráfico real, bases de datos transaccionales: todo esto ejecuta cuando hace falta, donde el usuario está, y carbon-aware scheduling no tiene palancas que mover sin afectar servicio.

En un análisis de un despliegue revisado recientemente, más del ochenta por ciento del consumo energético total correspondía a cargas no diferibles. Al aplicar carbon-aware solo a la fracción restante, el ahorro total del cluster fue inferior al cinco por ciento. La lectura honesta: el beneficio es proporcional a qué fracción de tu carga es elástica, no a que actives la función.

También hay casos donde el carbon-aware puede producir resultados contraproducentes:

• Mover cargas a regiones lejanas con mejor mix puede aumentar emisiones netas si el tráfico de datos entre centros crece notablemente; la transferencia también consume energía.
• Retrasar trabajos para esperar ventanas limpias puede aumentar coste operativo si requiere mantener recursos reservados o si acumula presión en horarios específicos.

El problema de la medición honesta

Un desafío central del carbon-aware scheduling es medir con precisión cuánto CO2 realmente se ahorra. La intensidad de carbono reportada por APIs como Electricity Maps o WattTime es aproximación razonable pero no perfecta, con retraso de actualización, granularidad limitada (región completa, no subcentro) y diferencias metodológicas entre proveedores. Dos herramientas que miden el mismo caso pueden reportar cifras diferentes en un 10 o 20 por ciento.

Kepler en Kubernetes tiene limitaciones conocidas: el consumo por pod se estima desde métricas del procesador, memoria y disco aplicando modelos de consumo energético que no siempre reflejan bien hardware nuevo o específico. Las mediciones tienen error conocido de hasta 20 por ciento en cargas mixtas. Esto no invalida la herramienta, pero sí obliga a interpretar sus cifras como indicaciones, no como verdades exactas.

La Software Carbon Intensity de Green Software Foundation es un estándar útil para normalizar medición y comparación entre sistemas, pero su adopción real sigue siendo limitada. Menos del 30 por ciento de despliegues reportan SCI como métrica, y menos aún establecen objetivos basados en ella.

Un ejemplo práctico con Karpenter

Un patrón que funciona bien combina Karpenter (autoescalado de Kubernetes basado en nodos) con políticas carbon-aware. La idea es preferir regiones con menor intensidad para aprovisionamiento de nodos nuevos cuando el escenario lo permite, manteniendo restricciones de latencia para cargas sensibles:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: batch-carbon-aware
spec:
  template:
    spec:
      requirements:
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c", "m"]
        - key: topology.kubernetes.io/region
          operator: In
          values: ["eu-north-1", "eu-west-1", "eu-central-1"]
      taints:
        - key: batch
          effect: NoSchedule
  weight: 100
  providerRef:
    name: carbon-intensity-preference

La política anterior, combinada con un controlador que actualiza un peso basado en intensidad de carbono por región y hora, mueve la preferencia de Karpenter dinámicamente. Las cargas que tienen tolerancia al taint “batch” se planifican en la región con mejor mix en ese momento. En un despliegue que monitorizo, esta política aplicada a entrenamientos y procesamiento nocturno redujo la intensidad media entre 20 y 25 por ciento tras tres meses.

Cuándo compensa

Con carbon-aware scheduling dejando de ser experimental y pasando a ser capacidad estándar de plataformas maduras, la recomendación práctica es medida:

1. Identifica honestamente qué fracción de tu carga es realmente elástica en tiempo o geografía; si menos del 20% lo es, el ahorro total será modesto.
2. Calcula coste de implementación y medición contra beneficio esperado; para algunos equipos el esfuerzo supera el ahorro potencial.
3. Si decides adoptarlo, invierte en medición honesta con Kepler, Software Carbon Intensity o equivalente, y verifica las cifras con datos reales en vez de confiar en lo que promete la plataforma por marketing.
4. Considera el carbon-aware scheduling como una pieza entre varias de una estrategia de sostenibilidad técnica. La arquitectura eficiente, el rightsizing de recursos, el apagado de infraestructura ociosa, la optimización de código, la elección de lenguaje de ejecución, la selección de hardware eficiente y la renovación hacia hardware moderno producen ahorros típicamente mayores.

La sostenibilidad técnica tiene además implicaciones para proyectos de Industria 4.0 donde la eficiencia energética de planta y la soberanía del dato son dimensiones que se consolidan juntas en la arquitectura de 2026.

Conclusión

En 2026, con la tecnología disponible y la capacidad operativa madura, no hacer nada por reducir la huella de carbono de las cargas de trabajo empieza a ser difícil de justificar. Pero hacerlo con honestidad sobre límites y medición seria es la única aproximación que produce resultados duraderos y creíbles. La integridad intelectual de reportar ahorros reales y reconocer limitaciones es más valiosa a largo plazo que cualquier cifra inflada de emisiones evitadas.

No es o uno o lo otro; es combinar todos los frentes disponibles: carbon-aware scheduling para las cargas elásticas, arquitectura eficiente para todos, y métricas honestas para los dos.