Cuando se trata de una infraestructura de TI moderna, no se puede subestimar el papel de Kubernetes, la plataforma de orquestación de contenedores de código abierto que automatiza la implementación, la gestión y el escalado de aplicaciones y servicios de software en contenedores.
Según un informe de la loud Native Computing Foundation (CNCF) (enlace externo a ibm.com), Kubernetes es el segundo proyecto de código abierto más grande del mundo después de Linux y la principal herramienta de orquestación de contenedores para el 71 % de las empresas de Fortune 100. Para entender cómo Kubernetes llegó a dominar los mercados de cloud computing y microservicios, tenemos que examinar su historia.
La historia de Kubernetes, cuyo nombre proviene del griego antiguo para "piloto o "timonel" (la persona al mando que dirige el barco) a menudo se remonta a 2013 cuando tres ingenieros de Google (Craig McLuckie, Joe Beda y Brendan Burns) presentaron una idea para crear un sistema de gestión de contenedores de código abierto. Estos pioneros tecnológicos buscaban formas de llevar la experiencia en infraestructura interna de Google al ámbito del cloud computing a gran escala y también permitirle competir con Amazon Web Services (AWS), el líder inigualable entre los proveedores de nube en ese momento.
Pero para comprender realmente la historia de Kubernetes, también conocido como "Kube" o "K8s", un "numerónimo " (enlace externo a ibm.com), tenemos que analizar los contenedores en el contexto de la infraestructura de TI tradicional frente a la virtual infraestructura de TI.
En el pasado, las organizaciones ejecutaban sus aplicaciones únicamente en servidores físicos (también conocidos como servidores bare metal). Sin embargo, no había forma de mantener los límites de recursos del sistema para esas aplicaciones. Por ejemplo, cada vez que un servidor físico ejecutaba varias aplicaciones, una aplicación podía consumir toda la potencia de procesamiento, la memoria, el espacio de almacenamiento u otros recursos de ese servidor. Para evitar que esto suceda, las empresas ejecutarían cada aplicación en un servidor físico diferente. Pero ejecutar aplicaciones en varios servidores crea recursos infrautilizados y problemas con la incapacidad de escalar. Además, tener un gran número de máquinas físicas ocupa espacio y es una tarea costosa.
Luego vino la virtualización, el proceso que conforma la base del cloud computing. Si bien la tecnología de virtualización se remonta a finales de la década de 1960, no se adoptó ampliamente hasta principios de la década de 2000.
La virtualización se basa en un software conocido como hipervisor. Un hipervisor es una forma ligera de software que permite que varias máquinas virtuales (VM) se ejecuten en la unidad central de procesamiento (CPU) de un único servidor físico. Cada máquina virtual tiene un sistema operativo invitado (SO), una copia virtual del hardware que el sistema operativo requiere para ejecutarse y una aplicación y sus bibliotecas y dependencias asociadas.
Si bien las máquinas virtuales crean un uso más eficiente de los recursos de hardware para ejecutar las aplicaciones que los servidores físicos, siguen consumiendo una gran cantidad de recursos del sistema. Esto es especialmente cierto cuando se ejecutan numerosas máquinas virtuales en el mismo servidor físico, cada una con su propio sistema operativo invitado.
Entra en juego la tecnología de contenedores. Un hito histórico en el desarrollo de contenedores se produjo en 1979 con el desarrollo de chroot (enlace externo a ibm.com), parte del sistema operativo Unix versión 7. Chroot introdujo el concepto de aislamiento de procesos al restringir el acceso a los archivos de una aplicación a un directorio específico (la raíz) y sus hijos (o subprocesos).
Los contenedores actuales se definen como unidades de software en las que el código de la aplicación se empaqueta con todas sus bibliotecas y dependencias. Esto permite que las aplicaciones se ejecuten rápidamente en cualquier entorno, ya sea dentro o fuera de las instalaciones, desde un escritorio, un centro de datos privado o una nube pública.
En lugar de virtualizar el hardware subyacente como las máquinas virtuales, los contenedores virtualizan el sistema operativo (normalmente como Linux o Windows). La falta de un sistema operativo huésped es lo que hace que los contenedores sean ligeros, rápidos y portátiles que las máquinas virtuales.
A principios de la década de 2000, Google necesitaba una forma de obtener el mejor rendimiento de su servidor virtual para respaldar su creciente infraestructura y ofrecer su plataforma de nube pública. Esto llevó a la creación de Borg, el primer sistema unificado de gestión de contenedores. Desarrollado entre 2003 y 2004, el sistema Borg lleva el nombre de un grupo de extraterrestres de Star Trek, los Borg, organismos cibernéticos que funcionan compartiendo una mente colmena (conciencia colectiva) llamada "El Colectivo".
El nombre Borg encajaba bien en el proyecto de Google. El sistema de gestión de clústeres a gran escala de Borg actúa esencialmente como un cerebro central para ejecutar cargas de trabajo en contenedores en sus centros de datos. Diseñado para funcionar junto con el motor de búsqueda de Google, Borg se utilizó para crear los servicios de Internet de Google, incluidos Gmail, Google Docs, Google Search, Google Maps y YouTube.
Borg permitió a Google ejecutar cientos de miles de trabajos, desde muchas aplicaciones diferentes, en muchas máquinas. Esto permitió a Google lograr una alta utilización de recursos, tolerancia a fallos y escalabilidad para sus cargas de trabajo a gran escala. Borg todavía se utiliza en Google hoy en día como el principal sistema interno de gestión de contenedores de la empresa.
En 2013, Google presentó Omega, su sistema de gestión de contenedores de segunda generación. Omega llevó el ecosistema Borg más allá, proporcionando una solución de programación flexible y escalable para clústeres informáticos a gran escala. También fue en 2013 cuando Docker, un actor clave en la historia de Kubernetes, entró en escena.
Desarrollado por dotCloud, una empresa de tecnología de plataforma como servicio (PaaS), Docker se lanzó en 2013 como una herramienta de software de código abierto que permitía a los desarrolladores de software en línea crear, implementar y gestionar aplicaciones en contenedores.
La tecnología de contenedores Docker utiliza el kernel de Linux (el componente base del sistema operativo) y características del kernel para separar los procesos para que puedan ejecutarse independientemente. Para aclarar cualquier confusión, el homónimo de Docker también se refiere a Docker, Inc. (anteriormente dotCloud, enlace externo a ibm.com), que desarrolla herramientas de productividad construidas en torno a su plataforma de contenedorización de código abierto, así como al ecosistema y la comunidad de código abierto de Docker (enlace externo a ibm.com).
Al popularizar un tiempo de ejecución de contenedores ligeros y proporcionar una forma sencilla de empaquetar, distribuir e implementar aplicaciones en una máquina, Docker proporcionó las semillas o la inspiración para los fundadores de Kubernetes. Cuando Docker entró en escena, los googlers Craig McLuckie, Joe Beda y Brendan Burns estaban entusiasmados con la capacidad de Docker para crear contenedores individuales y ejecutarlos en máquinas individuales.
Aunque Docker había cambiado las reglas del juego para la infraestructura nativa de la nube, tenía limitaciones porque estaba diseñado para ejecutarse en un solo nodo, lo que hacía imposible la automatización. Por ejemplo, dado que las aplicaciones se crearon para miles de contenedores separados, gestionarlas en varios entornos se convirtió en una tarea difícil en la que cada desarrollo individual tenía que empaquetarse manualmente. El equipo de Google vio la necesidad (y la oportunidad) de un orquestador de contenedores que pudiera implementar y gestionar varios contenedores en varias máquinas. Así nació el sistema de gestión de contenedores de tercera generación de Google, Kubernetes.
Muchos de los desarrolladores de Kubernetes habían trabajado para desarrollar Borg y querían construir un orquestador de contenedores que incorporara todo lo que habían aprendido a través del diseño y desarrollo de los sistemas Borg y Omega para producir una herramienta de código abierto menos compleja con una interfaz (UI) fácil de usar. Como una oda a los Borg, lo llamaron Proyecto Siete de Nueve en honor a un personaje de Star Trek: Voyager que es un antiguo dron Borg. Aunque el nombre original del proyecto no se mantuvo, fue recordado por los siete puntos en el logotipo de Kubernetes (enlace externo a ibm.com).
La arquitectura de Kubernetes se basa en clústeres en ejecución que permiten que los contenedores se ejecuten en varias máquinas y entornos. Cada clúster suele constar de dos clases de nodos:
El plano de control actúa básicamente como el orquestador del clúster Kubernetes e incluye varios componentes: el servidor API (gestiona todas las interacciones con Kubernetes), el gestor de control (gestiona todos los procesos de control), el gestor del controlador de la nube (la interfaz con la API del proveedor de la nube), etc. Los nodos de trabajo ejecutan contenedores utilizando entornos de ejecución de contenedores como Docker. Los pods, las unidades implementables más pequeñas de un clúster, contienen uno o más contenedores de aplicaciones y comparten recursos, como almacenamiento e información de red.
En 2014, Kubernetes hizo su debut como una versión de código abierto de Borg, con Microsoft, RedHat, IBM y Docker firmando como miembros tempranos de la comunidad Kubernetes. La herramienta de software incluye funciones básicas para la orquestación de contenedores, entre las que se incluyen las siguientes:
En 2015, en la Convención de Código Abierto de O'Reilly (OSCON) (enlace externo a ibm.com), los fundadores de Kubernetes presentaron una versión ampliada y refinada de Kubernetes: Kubernetes 1.0. Poco después, los desarrolladores del equipo de Red Hat OpenShift se unieron al equipo de Google, aportando su experiencia empresarial y de ingeniería al proyecto.
Coincidiendo con el lanzamiento de Kubernetes 1.0 en 2015, Google donó Kubernetes a la Cloud Native Computing Foundation (CNCF) (enlace externo a ibm.com), parte de la Linux Foundation sin ánimo de lucro. La CNCF fue creada conjuntamente por numerosos miembros de las principales empresas informáticas del mundo, incluidas Docker, Google, Microsoft, IBM y Red Hat. La misión (enlace externo a ibm.com) de la CNCF es "hacer que la computación nativa de la nube sea omnipresente".
En 2016, Kubernetes se convirtió en el primer proyecto alojado del CNCF y, en 2018, Kubernetes fue el primer proyecto del CNCF en graduarse. El número de empresas que contribuyen activamente aumentó rápidamente hasta superar los 700 miembros, y Kubernetes se convirtió rápidamente en uno de los proyectos de código abierto de más rápido crecimiento de la historia. En 2017, superó a competidores como Docker Swarm y Apache Mesos para convertirse en el estándar del sector para la orquestación de contenedores.
Antes de la nube, las aplicaciones de software estaban vinculadas a los servidores de hardware en los que se ejecutaban. Pero en 2018, cuando Kubernetes y los contenedores se convirtieron en el estándar de gestión para las organizaciones de venta en la nube, el concepto de aplicaciones nativas de la nube comenzó a afianzarse. Esto abrió la puerta de entrada para la investigación y el desarrollo de software basado en la nube.
Kubernetes ayuda a desarrollar programas basados en microservicios nativos de la nube y permite la contenerización de las aplicaciones existentes, lo que permite un desarrollo más rápido de las aplicaciones. Kubernetes también proporciona la automatización y la capacidad de observación necesarias para gestionar eficazmente varias aplicaciones al mismo tiempo. La infraestructura declarativa e impulsada por las APIde Kubernetes permite a los equipos de desarrollo nativos de la nube operar de forma independiente y aumentar su productividad.
La historia de Kubernetes y su papel como plataforma portátil, extensible y de código abierto para gestionar cargas de trabajo en contenedores y microservicios, continúa desarrollándose.
Desde que Kubernetes se unió a la CNCF en 2016, el número de colaboradores ha aumentado a 8012, un aumento del 996 % (enlace externo a ibm.com). La conferencia mundial insignia de la CNCF, KubeCon + CloudNativeCon (enlace externo a ibm.com), atrae a miles de asistentes y ofrece un foro anual para la información y los conocimientos de desarrolladores y usuarios sobre Kubernetes y otras tendencias de DevOps .
En los frentes de transformación de la nube y modernización de aplicaciones , la adopción de Kubernetes no muestra signos de desaceleración. Según un informe de Gartner, The CTO's Guide to Containers and Kubernetes (enlace externo a ibm.com), más del 90 % de las organizaciones del mundo ejecutarán aplicaciones en contenedores en producción para 2027.
En 2014, IBM fue una de las primeras grandes empresas en unir fuerzas con la comunidad de código abierto de Kubernetes y llevar la orquestación de contenedores a la empresa. En la actualidad, IBM está ayudando a las empresas a navegar por sus continuos viajes a la nube con la implementación de la orquestación de contenedores de Kubernetes y otras soluciones de gestión basadas en la nube.
Tanto si su objetivo es el desarrollo de aplicaciones nativas de la nube, la implementación de aplicaciones a gran escala o la gestión de microservicios, podemos ayudarle a aprovechar Kubernetes y sus numerosos casos de uso.
Red Hat OpenShift on IBM Cloud ofrece a los desarrolladores OpenShift una forma rápida y segura de contenerizar e implementar cargas de trabajo empresariales en clústeres Kubernetes.
IBM Cloud Code Engine, una plataforma sin servidor totalmente gestionada, le permite ejecutar código de contenedor, aplicación o trabajo por lotes en un tiempo de ejecución de contenedor totalmente gestionado.