Durante los primeros años del software libre, grandes bancos y corporaciones llegaron a crear sus propios kernels de Linux, porque aún no existían distribuciones formales.
La evolución de un estándar tecnológico global
Eran pioneros: querían usar Linux, pero debían construir todo desde cero. Hoy la historia es muy distinta: todos utilizan distribuciones comerciales, y Linux se convirtió en la base universal del mundo digital.
Según Jesse Butler, principal project manager de Amazon EKS, la misma transformación está ocurriendo con Kubernetes. Durante KubeCon + CloudNativeCon en Atlanta afirmó:
“Ya no estamos construyendo APIs de clúster personalizadas ni control planes propios. Ahora buscamos estándares que funcionen a escala empresarial.”
El mensaje es claro: Kubernetes ya no es para un nicho. Es una tecnología usada por todos —desde startups hasta gobiernos— y eso está redefiniendo cómo empresas como AWS contribuyen al ecosistema open source.
Por qué AWS construye características, no productos aislados
En una conversación con The New Stack, Butler abordó dos proyectos open source que AWS donó a la comunidad:
- Kro (Kubernetes Resource Orchestrator)
- Karpenter
Ambos llegaron a la comunidad a través de distintos SIGs (grupos de interés dentro de Kubernetes). Pero lo más importante no es la donación, sino el por qué:
AWS ya no quiere crear productos paralelos, sino características nativas del ecosistema Kubernetes. Un cambio que refleja un enfoque más colaborativo y que apunta a fortalecer al sistema completo, no solo al usuario de AWS.
Cuando el “código pegamento” se convierte en deuda técnica
El origen de Kro surge de un problema recurrente: la explosión de controladores personalizados.
Con la llegada de las Custom Resource Definitions (CRDs), las organizaciones empezaron a representar cualquier cosa como un recurso de Kubernetes: infraestructura, redes, servicios internos… Pero eso provocó que pequeños equipos tuvieran que mantener decenas de controladores cuyo único propósito era “unir” componentes.
Butler lo resumió así:
“Hace cuatro o cinco años, algunos clientes tenían 20 o 30 recursos personalizados, y un equipo pequeño debía mantener código que ni siquiera era lógica de negocio.”
Kro resuelve este problema generando automáticamente:
- el CRD,
- y un microcontrolador para gestionarlo.
Los ingenieros solo definen un esquema simple en YAML con Simple Schema, Kro infiere dependencias, construye un grafo acíclico dirigido y ejecuta la orquestación.
Es como Controller-as-a-Service, pero sin salir del universo Kubernetes.
El problema del aprovisionamiento de nodos que nadie quería resolver
De otro dolor surgió Karpenter. El autoscaler tradicional no podía adaptarse a cargas nativas de la nube, que son dinámicas e impredecibles.
“Las cargas cloud-native son picosas, cambiantes,” explicó Butler.
La respuesta fue un sistema de aprovisionamiento justo a tiempo (JIT):
- genera nodos exactamente cuando son necesarios,
- optimiza costos automáticamente,
- y responde a la demanda en tiempo real.
El verdadero éxito estuvo en su diseño de API:
- Puedes pedir “solo dame un nodo”
- o definir configuraciones ultra detalladas.
Esa flexibilidad, sumada al ahorro en costos, impulsó su adopción masiva. Finalmente, AWS lo donó al SIG Autoscaling de Kubernetes, consolidándolo como parte del ecosistema.
Una nueva filosofía dentro de AWS
Ambos proyectos reflejan un cambio profundo:
AWS busca construir herramientas para toda la comunidad, no solo para su propia nube.
Butler lo dijo con claridad:
“En Kubernetes y en el software cloud-native, todos somos el cliente. No podemos construir algo solo para AWS y llamarlo Kubernetes.”
Este enfoque evita fragmentar el ecosistema y fortalece la interoperabilidad entre proveedores.
El futuro del ecosistema Kubernetes
La conversación completa profundiza en:
- la arquitectura y definiciones de recursos de Kro,
- la evolución de Karpenter,
- el camino desde prototipo hasta API estable,
- y el motivo por el cual AWS prefiere donar proyectos a los SIGs antes que crear iniciativas separadas dentro de la CNCF.
Para quienes han visto a Kubernetes crecer desde un simple orquestador hasta convertirse en un estándar empresarial, esta transición muestra cómo maduran los grandes proyectos de código abierto.
Fuente: somoslibres
