Hoy se celebran 10 años desde el primer commit de Kubernetes en GitHub el 6 de junio de 2014. Con 250 archivos y 47,501 líneas de código en Go, Bash y Markdown, se inició un proyecto que ha crecido enormemente. Diez años después, Kubernetes es uno de los proyectos de código abierto más grandes, con más de 88,000 colaboradores de más de 8,000 empresas en 44 países.

Este hito no solo es importante para Kubernetes, sino también para el ecosistema Cloud Native que ha florecido a su alrededor. Con cerca de 200 proyectos dentro de la CNCF y contribuciones de más de 240,000 individuos, Kubernetes se ha convertido en el pilar de una comunidad de desarrolladores y usuarios que supera los 7 millones, todos ellos moldeando el ecosistema actual.

Los inicios de Kubernetes y la evolución de la tecnología de contenedores

Las ideas subyacentes a Kubernetes comenzaron mucho antes del primer commit, o incluso del primer prototipo (que surgió en 2013). A principios de la década de 2000, la Ley de Moore estaba en pleno efecto. El hardware de computación se volvía cada vez más poderoso a un ritmo increíblemente rápido. Correspondientemente, las aplicaciones se volvían cada vez más complejas. Esta combinación de la comoditización del hardware y la complejidad de las aplicaciones apuntaba a la necesidad de abstraer aún más el software del hardware, y comenzaron a surgir soluciones.

Como muchas empresas en ese momento, Google estaba escalando rápidamente, y sus ingenieros estaban interesados en la idea de crear una forma de aislamiento en el núcleo de Linux. El ingeniero de Google Rohit Seth describió el concepto en un correo electrónico en 2006:

Usamos el término contenedor para indicar una estructura contra la cual rastreamos y cobramos la utilización de recursos del sistema como memoria, tareas, etc., para una carga de trabajo.

El futuro de los contenedores de Linux

En marzo de 2013, una charla relámpago de 5 minutos llamada “El futuro de los contenedores de Linux,” presentada por Solomon Hykes en PyCon, introdujo una herramienta de código abierto llamada “Docker” para crear y usar contenedores de Linux. Docker introdujo un nivel de usabilidad a los contenedores de Linux que los hizo accesibles a más usuarios que nunca, y la popularidad de Docker, y por lo tanto de los contenedores de Linux, se disparó. Con Docker haciendo la abstracción de los contenedores de Linux accesible para todos, ejecutar aplicaciones de manera mucho más portátil y repetible fue de repente posible, pero la cuestión de la escala permanecía.

El sistema Borg de Google para gestionar la orquestación de aplicaciones a escala había adoptado contenedores de Linux a medida que se desarrollaban a mediados de la década de 2000. Desde entonces, la compañía también había comenzado a trabajar en una nueva versión del sistema llamada “Omega”. Los ingenieros de Google que estaban familiarizados con los sistemas Borg y Omega vieron la popularidad de la contenedorización impulsada por Docker. Reconocieron no solo la necesidad de un sistema de orquestación de contenedores de código abierto, sino su “inevitabilidad”, como describió Brendan Burns en esta publicación de blog. Esa realización en el otoño de 2013 inspiró a un pequeño equipo a comenzar a trabajar en un proyecto que más tarde se convertiría en Kubernetes. Ese equipo incluía a Joe Beda, Brendan Burns, Craig McLuckie, Ville Aikas, Tim Hockin, Dawn Chen, Brian Grant y Daniel Smith.

Un recorrido por la evolución de Kubernetes

La historia de Kubernetes comenzó con el commit inicial el 6 de junio de 2014 y su anuncio en DockerCon 2014. Durante el año siguiente, una comunidad de colaboradores, principalmente de Google y Red Hat, trabajó arduamente en el proyecto, culminando en el lanzamiento de la versión 1.0 el 21 de julio de 2015. Google donó Kubernetes a la recién formada Cloud Native Computing Foundation (CNCF).

Aunque Kubernetes 1.0 fue un hito, el proyecto seguía siendo complejo. En 2016, Kelsey Hightower lanzó “Kubernetes the Hard Way” para abordar estas dificultades. Desde entonces, Kubernetes ha experimentado numerosos avances, como las Definiciones de Recursos Personalizados (CRD) y el soporte completo de doble pila.

Algunos hitos notables incluyen:

• Diciembre 2016: Kubernetes 1.5 introduce soporte inicial para CRI y nodos de Windows, así como StatefulSets y PodDisruptionBudgets en Beta.
• Abril 2017: Se introduce el control de acceso basado en roles (RBAC).
• Junio 2017: Las Definiciones de Recursos Personalizados (CRDs) reemplazan los Terceros Recursos (TPRs) en Kubernetes 1.7.
• Diciembre 2017: Kubernetes 1.9 marca la disponibilidad general (GA) de la API de Workloads.
• Diciembre 2018: La Interfaz de Almacenamiento de Contenedores (CSI) alcanza GA en Kubernetes 1.13.
• Septiembre 2019: Las Definiciones de Recursos Personalizados (CRDs) alcanzan GA en Kubernetes 1.16.
• Diciembre 2020: Dockershim es deprecado en Kubernetes 1.20.
• Mayo 2022: Kubernetes 1.24 desactiva las API beta por defecto y elimina Dockershim.

La última gran migración en Kubernetes ha sido la eliminación de código “in-tree” integrado de proveedores de nube. El objetivo de este esfuerzo es permitir que los proveedores de nube desarrollen y realicen lanzamientos de manera independiente al ciclo de lanzamiento principal de Kubernetes. La separación del código de los proveedores de nube permite una clara división de responsabilidades entre el “núcleo de Kubernetes” y los proveedores de nube dentro del ecosistema.

Además, esto asegura que todos los proveedores de nube se integren con Kubernetes de una manera coherente y extensible. Desarrollar y lanzar todos los proveedores de nube en sus propios repositorios o módulos externos tendrá los siguientes beneficios:

• Los componentes principales de Kubernetes (kubelet, kube-apiserver, kube-controller-manager, etc.) ya no dependerán de las APIs específicas de los proveedores de nube (y sus dependencias). Esto resultará en binarios más pequeños y reducirá la probabilidad de vulnerabilidades de seguridad a través de dependencias externas.
• Cada proveedor de nube podrá lanzar características/correcciones de errores según su propio cronograma, en lugar de depender del ciclo de lanzamiento principal de Kubernetes.

Otro cambio importante reciente fue haber migrado el alojamiento de imágenes a registry.k8s.io, propiedad de la comunidad, para mejorar la eficiencia de costos y rendimiento.

El futuro de Kubernetes en 3 años

Una década después, Kubernetes sigue teniendo un futuro brillante. La comunidad se enfoca en mejorar la experiencia del usuario y la sostenibilidad del proyecto. Con la llegada de la IA en 2024, las necesidades de computación distribuida y programación de cargas de trabajo han cobrado más relevancia. La comunidad está atenta a estas necesidades, organizándose en nuevos grupos de trabajo para abordar las demandas emergentes.

El ecosistema de Kubernetes continuará creciendo y evolucionando. Iniciativas como la migración del código de proveedores y el cambio de registro han sido cruciales para la sostenibilidad del proyecto.

En sentinella hacemos las siguientes proyecciones a 3 años:

1. Adopción de Kubernetes

En los próximos tres años, Kubernetes se convertirá en el estándar claro para desplegar aplicaciones nativas de la nube en entornos de producción. Su flexibilidad, portabilidad y amplio ecosistema de herramientas lo harán el favorito, incluso ante la aparición de nuevos competidores. Para 2027, más del 75% de las nuevas aplicaciones nativas de la nube se desplegarán en Kubernetes desde el primer día.

2. Mejor Soporte para Multi-Nube y Nube Híbrida

La mayoría de las organizaciones operarán en entornos multi-nube o nube híbrida. Las herramientas de Kubernetes evolucionarán para ofrecer mayor portabilidad y consistencia a través de diferentes nubes. Tecnologías como la federación de clusters, service meshes, pipelines de GitOps y otras tecnologías unificadoras mejorarán significativamente. Para 2027, será posible gestionar un entorno Kubernetes unificado que abarque on-premises, híbrido y multi-nube.

3. Auge de Aplicaciones Stateful Contenerizadas

Tradicionalmente, Kubernetes ha sido utilizado para aplicaciones sin estado, pero nuevas capacidades le permitirán manejar más cargas de trabajo con estado, como bases de datos, cachés y sistemas de almacenamiento. Los frameworks de operadores, StatefulSets y una mejor gestión de volúmenes harán más fácil ejecutar aplicaciones con estado en Kubernetes. Para 2027, más del 30% de las bases de datos y aplicaciones con estado se ejecutarán en Kubernetes.

4. Inteligencia Artificial para la Gestión de Infraestructura Inteligente

Las plataformas de Kubernetes aprovecharán el aprendizaje por refuerzo y otras técnicas de IA para auto-optimizar la asignación de recursos, la programación, el autoescalado y más. La gestión de clústeres será más adaptable y resiliente basándose en cargas de trabajo dinámicas. Las herramientas potenciadas por IA podrán detectar incidentes, predecir fallos futuros y tomar medidas preventivas.

Los próximos 10 años de Kubernetes estarán guiados por el mercado, el ecosistema y sobre todo, por sus usuarios. Nos vemos en 3 años para corroborar nuestras predicciones y mientras tanto, esperamos construir el futuro de Kubernetes contigo.