7 min. de lectura<\/p>\n
EKS 1.36 eleva la cuesti\u00f3n de los costes un nivel m\u00e1s: ya no se trata solo de la eficiencia de los nodos, sino de la asignaci\u00f3n por carga de trabajo. Quien no integre esto ahora en la plataforma, acabar\u00e1 pagando facturas de nube que, en el pr\u00f3ximo trimestre, nadie podr\u00e1 explicar con claridad.<\/strong><\/p>\n Lo m\u00e1s importante en resumen<\/p>\n Relacionado:<\/span>FinOps para inferencia de IA<\/a> \/<\/span> Un operador log\u00edstico ahorra un 31 % en costes de multi-nube<\/a><\/p>\n \u00bfQu\u00e9 es EKS 1.36?<\/strong> Amazon Elastic Kubernetes Service en la l\u00ednea de versiones 1.36 es el servicio de Kubernetes gestionado en AWS que refleja la versi\u00f3n 1.36 de Kubernetes. Lo novedoso no es solo el conjunto de funciones upstream, sino la estrecha integraci\u00f3n de Karpenter, Split Cost Allocation Data y Container Insights, que hacen auditables los costes a nivel de pod directamente desde el cl\u00faster.<\/p>\n Si se consulta la consola de GSC para ver qu\u00e9 han buscado los equipos de plataforma en las \u00faltimas semanas, se encuentra \u00abeks 1.36\u00bb varias veces entre las principales consultas. No se trata de un inter\u00e9s por las notas de la versi\u00f3n. Quien escribe este t\u00e9rmino ya tiene un cl\u00faster en producci\u00f3n y quiere saber qu\u00e9 cambia en la visi\u00f3n de costes.<\/p>\n La respuesta corta: AWS ha ido incorporando Cost Allocation Tags, Split Cost Allocation Data y Container Insights con m\u00e9tricas a nivel de pod a la plataforma EKS a lo largo de varias versiones. EKS 1.36 es el momento en que estas piezas encajan. Antes eran rutas separadas con modelos de datos independientes. Ahora convergen en una \u00fanica visi\u00f3n que los equipos de plataforma deben curar ellos mismos.<\/p>\n Esto cambia las responsabilidades. Hasta ahora, el equipo de plataforma pod\u00eda decir: nosotros entregamos el cl\u00faster, FinOps aporta la visi\u00f3n. Con la 1.36, esto se invierte. Quien opera el cl\u00faster tambi\u00e9n es responsable de la asignaci\u00f3n de costes, ya que las etiquetas, las etiquetas de pod y la pipeline de informes dependen de la plataforma, no de la herramienta financiera.<\/p>\n En primer lugar: convenci\u00f3n de etiquetado. Sin etiquetas continuas en Cluster, NodePool, Namespace y Pod, no hay asignaci\u00f3n. Quien a\u00fan no tenga esto en 2026 tendr\u00e1 que reconstruir la visi\u00f3n en cada ejecuci\u00f3n de informes. Una convenci\u00f3n es suficiente, pero debe imponerse, idealmente con pol\u00edticas de OPA o Kyverno.<\/p>\n En segundo lugar: estrategia de NodePool. Karpenter est\u00e1 estable desde la versi\u00f3n 1.0 y se recomienda por defecto en EKS 1.36. Un NodePool decide si una carga de trabajo se ejecutar\u00e1 en Spot o On-Demand, qu\u00e9 familia de instancias recibir\u00e1 y si se permite Graviton. Si esta decisi\u00f3n se deja al equipo de aplicaciones, no habr\u00e1 historia de costes de plataforma. Si se toma de forma centralizada, se genera fricci\u00f3n. Ambos son aceptables, pero debe ser expl\u00edcito.<\/p>\n En tercer lugar: asignaci\u00f3n a nivel de Pod. AWS Split Cost Allocation Data distribuye los costes de EC2 proporcionalmente entre Pods. Esto solo funciona si las solicitudes de recursos est\u00e1n correctamente definidas. En la mayor\u00eda de los cl\u00fasteres no es as\u00ed. Los Pods se ejecutan con solicitudes predeterminadas, que pueden ser demasiado altas o demasiado bajas, y la asignaci\u00f3n se vuelve inutilizable. Antes de la historia de costes, viene un auditor\u00eda de solicitudes.<\/p>\n \n”<\/span><\/p>\n Una visi\u00f3n FinOps sobre EKS es tan precisa como las solicitudes de recursos en los manifiestos. Quien miente all\u00ed, se echa a perder toda la asignaci\u00f3n.<\/p>\n<\/blockquote>\n<\/figure>\n Durante los primeros a\u00f1os de Karpenter, el objetivo fue reemplazar al Cluster Autoscaler y escalar m\u00e1s r\u00e1pido. Eso ya se ha hecho. Lo que importa ahora es la disciplina de los NodePools. Un NodePool es un contrato entre la plataforma y el equipo: qu\u00e9 tipos de instancia, qu\u00e9 zona de disponibilidad, qu\u00e9 porcentaje de Spot, qu\u00e9 tolerancia a interrupciones.<\/p>\n Quien lo agrupa todo en una \u00fanica NodePool no tiene control. Quien crea una NodePool por equipo tiene demasiada complejidad. Lo realista es tener entre tres y cinco NodePools por cl\u00faster productivo: uno para cargas de trabajo est\u00e1ticas y de larga duraci\u00f3n, otro para cargas de trabajo de tipo batch con Spot, otro para inferencia de GPU, opcionalmente uno para Pods aislados por cumplimiento.<\/p>\n Con esto, la definici\u00f3n del NodePool se convierte en una decisi\u00f3n FinOps que aparece en el manifiesto del cl\u00faster. Es auditable, versionada y se encuentra en el mismo repositorio que el resto de la configuraci\u00f3n de la plataforma. Este es el punto donde la gobernanza de costes se vuelve t\u00e9cnica y ya no solo se gestiona en un dashboard.<\/p>\n Multi-Cloud suena para Finanzas como una dispersi\u00f3n de riesgos. Para la plataforma es un problema de allokaci\u00f3n. EKS factura de forma diferente a AKS, AKS factura de forma diferente a GKE y ninguna de las tres perspectivas se puede mapear sin adaptador a la otra.<\/p>\n Fuente: Documentaci\u00f3n de los proveedores, mayo 2026, propia evaluaci\u00f3n.<\/p>\n Quien opera tres nubes simult\u00e1neamente necesita una capa de traducci\u00f3n. Esta puede ser asumida por un herramienta como Kubecost o OpenCost, tambi\u00e9n puede ser una pipeline propia que convierta las tres APIs de costos en un esquema com\u00fan. Lo que no funciona: permitir a cada equipo su propia convenci\u00f3n de nube y construir al final un Excel.<\/p>\n La pregunta dif\u00edcil en cada programa FinOps no es la suma, sino la distribuci\u00f3n. Un cl\u00faster que es utilizado por cuatro equipos tiene un operador de cl\u00faster y cuatro consumidores. El operador paga por la Control Plane, Networking y servicios compartidos. Los consumidores pagan por sus pods.<\/p>\n Esto suena sencillo. En la pr\u00e1ctica, tres cosas colapsan: los pods sin etiquetas limpias no se asignan. Los servicios compartidos como Ingress Controller o Service Mesh se cuentan dos veces. Las recursos ociosos no se distribuyen. Una allokaci\u00f3n que no regule estos tres puntos no es pol\u00edtica, sino una factura.<\/p>\n El camino pragm\u00e1tico: los pods sin etiqueta de equipo terminan en un \u00abbucket de plataforma\u00bb y se revisan mensualmente. Los servicios compartidos se distribuyen proporcionalmente seg\u00fan el consumo de CPU. La capacidad ociosa se reparte entre el equipo que caus\u00f3 las Reserved Instances o Savings Plans. Esto no es perfecto, pero es explicativo.<\/p>\n Un equipo de plataforma que opera EKS 1.36 en producci\u00f3n en 2026 tiene un contrato diferente con la organizaci\u00f3n que hace dos a\u00f1os. Antes, la pregunta era: \u00bfPuedes darnos un cluster que funcione? Ahora es: \u00bfPuedes decirnos cu\u00e1nto cuesta y qui\u00e9n lo paga?<\/p>\n Esto requiere tres cosas en el cat\u00e1logo de servicios. Primero, una convenci\u00f3n de etiquetado que se considera requisito previo para el onboarding. Segundo, una selecci\u00f3n de NodePool que el equipo debe tomar activamente y que est\u00e1 claramente descrita con sus implicaciones de coste. Tercero, un informe mensual de costes que est\u00e9 sobre la mesa de Finanzas y no solo cuando el CFO lo pregunte.<\/p>\n Quien logre esto tiene una plataforma. Quien no lo logre tiene una colecci\u00f3n de clusters con una factura desconocida. EKS 1.36 hace visible t\u00e9cnicamente la diferencia. La decisi\u00f3n de adoptarla tambi\u00e9n a nivel organizacional recae en los equipos de plataforma.<\/p>\n No, pero la tarea se vuelve m\u00e1s compleja al construirlo por cuenta propia. AWS Split Cost Allocation Data m\u00e1s las etiquetas de asignaci\u00f3n de costes son suficientes para la mayor\u00eda de los escenarios de un solo cluster. Tan pronto como haya m\u00e1s de tres clusters o se involucre Multi-Cloud, vale la pena usar una herramienta como Kubecost, OpenCost o una capa similar. Los costes de las herramientas en s\u00ed suelen ser significativamente m\u00e1s bajos que las horas que un equipo invierte en sus propias pipelines.<\/p>\n<\/details>\n Karpenter utiliza autom\u00e1ticamente Reserved Instances y Savings Plans cuando est\u00e1n disponibles en la misma familia de instancias. Sin embargo, prefiere las Spot-Instances m\u00e1s econ\u00f3micas, lo que, con una pol\u00edtica de Spot agresiva, hace que los Savings Plans no se aprovechen al m\u00e1ximo. Quien compra Savings Plans durante varios a\u00f1os deber\u00eda definir NodePools con capacidad solo On-Demand que absorban estos planes y permitir Spot solo donde el workload sea tolerante a interrupciones.<\/p>\n<\/details>\n Un Pod siempre corre en un solo Namespace. Lo que se quiere decir es: Si un workload usa recursos de m\u00faltiples Namespaces como vol\u00famenes compartidos, servicios comunes o bases de datos centrales, la asignaci\u00f3n debe representar esta conexi\u00f3n cruzada. Enfoque pragm\u00e1tico: Los recursos de m\u00faltiples Namespaces se colocan en un ‘Shared-Services’-Bucket, que se distribuye a los consumidores seg\u00fan una clave claramente definida (consumo de CPU, n\u00famero de solicitudes). Quien no lo regule pierde del 10 al 20 por ciento de los costes en una asignaci\u00f3n no clara.<\/p>\n<\/details>\n El camino de actualizaci\u00f3n a 1.36 vale la pena para cualquier cluster productivo, solo por las actualizaciones de seguridad y la pol\u00edtica de ciclo de vida de AWS. Las caracter\u00edsticas de FinOps son un beneficio, no un impulsor. Para tres equipos suele bastar un \u00fanico NodePool con una tolerancia a Spot claramente definida, un esquema de etiquetas coherente y una exportaci\u00f3n mensual de costes. El paquete completo de FinOps se requiere para clusters con cinco equipos o carga combinada de c\u00f3mputo superior a 200.000 Euro al a\u00f1o.<\/p>\n<\/details>\n M\u00e1s del network MBF Media<\/p>\n Optimizaci\u00f3n de procesos sin proyecto a largo plazo<\/a>\n<\/div>\n\n
Lo que cambia en la cuesti\u00f3n de los costes con EKS 1.36<\/h2>\n
Tres palancas que los equipos de plataforma ajustan ahora<\/h2>\n
Karpenter pasa de ventaja fiscal a instrumento de control de costes<\/h2>\n
Lo que hace Multi-Cloud con la factura de EKS<\/h2>\n
\n\n
\n \nDimensi\u00f3n de allokaci\u00f3n<\/th>\n EKS 1.36<\/th>\n AKS 1.32<\/th>\n GKE 1.34<\/th>\n<\/tr>\n<\/thead>\n \n Costos por nivel de pod<\/strong><\/td>\n Asignaci\u00f3n de datos de costo nativa<\/td>\n An\u00e1lisis de costos por espacio de nombres<\/td>\n Asignaci\u00f3n de costos GKE, basada en etiquetas<\/td>\n<\/tr>\n \n Control de spots<\/strong><\/td>\n NodePool de Karpenter<\/td>\n Pools de nodos Spot<\/td>\n Provisi\u00f3n autom\u00e1tica de nodos con Spot<\/td>\n<\/tr>\n \n Herencia de etiquetas<\/strong><\/td>\n Etiquetas de Kubernetes mapeadas a etiquetas de AWS<\/td>\n Etiquetas de Azure mediante Cluster Autoscaler<\/td>\n Etiquetas nativas en el Billing de GCP<\/td>\n<\/tr>\n \n Latencia del informe<\/strong><\/td>\n 24 horas<\/td>\n 12 a 24 horas<\/td>\n Hasta 48 horas<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Allokaci\u00f3n: qui\u00e9n paga por qu\u00e9 pod<\/h2>\n
Lo que debe cambiar en el contrato de plataforma ahora<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfNecesito Kubecost para asignar limpiamente los costes de EKS?<\/strong><\/summary>\n
\u00bfC\u00f3mo se comporta Karpenter con las Reserved Instances y los Savings Plans?<\/strong><\/summary>\n
\u00bfQu\u00e9 ocurre con la asignaci\u00f3n de costes cuando un Pod corre en varios Namespaces?<\/strong><\/summary>\n
\u00bfVale la pena EKS 1.36 para un cluster peque\u00f1o con tres equipos?<\/strong><\/summary>\n
Recomendaciones de lectura de la redacci\u00f3n<\/h3>\n
\n