Cuando se trata de infraestructura de TI moderna, el papel de Kubernetes—el código abierto orquestación de contenedores No se puede subestimar la plataforma que automatiza la implementación, la gestión y el escalado de aplicaciones y servicios de software en contenedores.

De acuerdo a una Informe de la Fundación de Computación Nativa en la Nube (CNCF) (el enlace se encuentra fuera de ibm.com), Kubernetes es el segundo mayor De código abierto proyecto en el mundo después de Linux y la principal herramienta de orquestación de contenedores para el 71% de las empresas Fortune 100. Para entender cómo Kubernetes llegó a dominar el la computación en nube y microservicios mercados, tenemos que examinar su historia.

La evolución de Kubernetes

La historia de Kubernetes, cuyo nombre proviene del griego antiguo que significa “piloto” o “timonel” (la persona al timón que dirige el barco) a menudo se remonta a 2013, cuando un trío de ingenieros de Google: Craig McLuckie, Joe Beda y Brendan Burns: presentó 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 de la computación en la nube a gran escala y también permitir que Google compita con Amazon Web Services (AWS), el líder inigualable entre los proveedores de la nube en ese momento.

Infraestructura de TI tradicional versus infraestructura de TI virtual

Pero para comprender verdaderamente la historia de Kubernetes, también conocido como “Kube” o “K8”, un “numerónimo”(el enlace se encuentra fuera de ibm.com): tenemos que analizar los contenedores en el contexto de la infraestructura de TI tradicional versus la infraestructura de TI virtual.

En el pasado, las organizaciones ejecutaban sus aplicaciones únicamente en servidores físicos (también conocidos como servidores de metal desnudo). 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 ejecuta varias aplicaciones, una aplicación puede 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 múltiples servidores crea recursos infrautilizados y problemas con la incapacidad de escalar. Es más, tener una gran cantidad de máquinas físicas ocupa espacio y es una tarea costosa.

VIRTUALIZACIÓN

Entonces vino virtualización—el proceso que forma la base de la computación en la nube. Si bien la tecnología de virtualización se remonta a finales de la década de 1960, no fue adoptada 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 liviana de software que permite múltiples máquinas virtuales (VM) para ejecutarse en la unidad central de procesamiento (CPU) de un único servidor físico. Cada máquina virtual tiene un sistema operativo (SO) invitado, 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 aplicaciones que los servidores físicos, aún consumen una gran cantidad de recursos del sistema. Este es especialmente el caso cuando se ejecutan numerosas máquinas virtuales en el mismo servidor físico, cada una con su propio sistema operativo invitado.

Contenedores

Participar envase tecnología. Un hito histórico en el desarrollo de contenedores se produjo en 1979 con el desarrollo de chroot (el enlace se encuentra fuera de 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 modernos se definen como unidades de software donde se empaqueta el código de la aplicación 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, privado en el centro de datos o 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 del sistema operativo invitado es lo que hace que los contenedores sean livianos, además de más rápidos y portátiles que las máquinas virtuales.

Borg: el predecesor de Kubernetes

A principios de la década de 2000, Google necesitaba una manera de obtener el mejor rendimiento de su servidores virtuales 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 Star Trek extraterrestres, los Borg, organismos cibernéticos que funcionan compartiendo una mente colmena (conciencia colectiva) llamada "El Colectivo".

El nombre Borg encaja bien con el proyecto de Google. La gran escala de Borg sistema de gestión de clústeres esencialmente actúa como un cerebro central para ejecutar en contenedores cargas de trabajo 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 fallas y escalabilidad para sus cargas de trabajo a gran escala. Borg todavía se utiliza en Google hoy 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 grupos de computadoras a gran escala. También fue en 2013 cuando Docker, un jugador clave en la historia de Kubernetes, entró en escena.

Docker marca el comienzo de la contenedorización de código abierto

Desarrollado por dotCloud, un Plataforma como servicio (PaaS) empresa de tecnología, 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 administrar aplicaciones en contenedores.

La tecnología de contenedor Docker utiliza el kernel de Linux (el componente base del sistema operativo) y las características del kernel para separar procesos para que puedan ejecutarse de forma independiente. Para aclarar cualquier confusión, el homónimo de Docker también se refiere a estibador, inc. (anteriormente dotCloud, el enlace reside fuera de ibm.com), que desarrolla herramientas de productividad basadas en su plataforma de contenedorización de código abierto, así como el Ecosistema y comunidad de código abierto de Docker (el enlace se encuentra fuera de ibm.com).

Al popularizar un tiempo de ejecución de contenedor liviano 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 empleados de Google Craig McLuckie, Joe Beda y Brendan Burns estaban entusiasmados con la capacidad de Docker para construir contenedores individuales y ejecutarlos en máquinas individuales.

Si bien Docker había cambiado las reglas del juego para la infraestructura nativa de la nube, tenía limitaciones porque fue diseñado para ejecutarse en un solo nodo, lo que hacía imposible la automatización. Por ejemplo, como las aplicaciones se crearon para miles de contenedores separados, administrarlas 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 administrar múltiples contenedores en múltiples máquinas. Así nació el sistema de gestión de contenedores de tercera generación de Google, Kubernetes.

Obtenga más información sobre las diferencias y similitudes entre Kubernetes y Docker

El nacimiento de Kubernetes

Muchos de los desarrolladores de Kubernetes habían trabajado para desarrollar Borg y querían crear 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 fácil de usar. (IU). Como una oda a Borg, lo llamaron Proyecto Siete de Nueve en honor a un Star Trek: Voyager personaje que es un ex dron Borg. Si bien el nombre original del proyecto no se mantuvo, quedó conmemorado por los siete puntos en Kubernetes. logo (el enlace se encuentra fuera de ibm.com).

Dentro de un clúster de Kubernetes

La arquitectura de Kubernetes se basa en la ejecución de clústeres que permiten que los contenedores se ejecuten en múltiples máquinas y entornos. Cada clúster normalmente consta de dos clases de nodos:

• Nodos trabajadores, que ejecutan las aplicaciones en contenedores.
• Nodos del plano de control, que controlan el clúster.

El plano de control básicamente actúa como orquestador del clúster de Kubernetes e incluye varios componentes: el servidor API (administra todas las interacciones con Kubernetes), el administrador de control (maneja todos los procesos de control), el administrador del controlador de la nube (la interfaz con la API del proveedor de la nube). , Etcétera. Los nodos trabajadores ejecutan contenedores utilizando tiempos de ejecución de contenedores como Docker. Los pods, las unidades implementables más pequeñas en un clúster, contienen uno o más contenedores de aplicaciones y comparten recursos, como almacenamiento e información de redes.

Lea más sobre cómo funcionan los clústeres de Kubernetes

Kubernetes se hace público

En 2014, Kubernetes hizo su debut como una versión de código abierto de Borg, con Microsoft, RedHat, IBM y Docker como primeros miembros de la comunidad de Kubernetes. La herramienta de software incluía funciones básicas para la orquestación de contenedores, incluidas las siguientes:

• Replicación para implementar múltiples instancias de una aplicación
• Equilibrio de carga y descubrimiento de servicios
• Comprobación y reparación básicas de estado.
• Programación para agrupar muchas máquinas y distribuirles el trabajo.

En 2015, en el Convención de código abierto O'Reilly (OSCON) (el enlace se encuentra fuera de ibm.com), los fundadores de Kubernetes dieron a conocer 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 y aportaron su experiencia empresarial y de ingeniería al proyecto.

La historia de Kubernetes y la Cloud Native Computing Foundation

Coincidiendo con el lanzamiento de Kubernetes 1.0 en 2015, Google donó Kubernetes a la Fundación de computación nativa de la nube (CNCF) (el enlace se encuentra fuera de ibm.com), parte de la Fundación Linux sin fines de lucro. El CNCF fue creado conjuntamente por numerosos miembros de las principales empresas informáticas del mundo, incluidas Docker, Google, Microsoft, IBM y Red Hat. El misión (el enlace se encuentra fuera de ibm.com) del CNCF es “hacer que la computación nativa de la nube sea omnipresente”.

En 2016, Kubernetes se convirtió en el primer proyecto alojado de la CNCF y, en 2018, Kubernetes fue el primer proyecto de la CNCF en graduarse. El número de empresas que contribuyen activamente aumentó rápidamente a más de 700 miembros, y Kubernetes rápidamente se convirtió en uno de los proyectos de código abierto de más rápido crecimiento de la historia. En 2017, estaba superando a competidores como Dockerenjambre y Apache Mesos para convertirse en el estándar de la industria para la orquestación de contenedores.

Kubernetes y aplicaciones nativas de la nube

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 nativo de la nube Las solicitudes comenzaron a afianzarse. Esto abrió la puerta a 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 contenedorización de aplicaciones existentes, lo que permite un desarrollo de aplicaciones más rápido. Kubernetes también proporciona la automatización y la observabilidad necesarias para gestionar de manera eficiente múltiples aplicaciones al mismo tiempo. El declarativo, APILa infraestructura impulsada por Kubernetes permite a los equipos de desarrollo nativos de la nube operar de forma independiente y aumentar su productividad.

El impacto continuo de Kubernetes

La historia de Kubernetes y su papel como plataforma portátil, extensible y de código abierto para gestionar cargas de trabajo y microservicios en contenedores continúa desarrollándose.

Desde que Kubernetes se unió al CNCF en 2016, el número de contribuyentes ha crecido a 8,012, un aumento del 996% (el enlace se encuentra fuera de ibm.com). La conferencia mundial emblemática del CNCF, KubeCon + CloudNativeCon (el enlace se encuentra fuera de ibm.com), atrae a miles de asistentes y ofrece un foro anual para información y conocimientos de desarrolladores y usuarios sobre Kubernetes y otros DevOps tendencias.

Sobre la transformación de la nube y modernización de aplicaciones En muchos frentes, la adopción de Kubernetes no muestra signos de desaceleración. Según un informe de Gartner, La guía del CTO sobre contenedores y Kubernetes (el enlace se encuentra fuera de ibm.com), más del 90% de las organizaciones del mundo ejecutarán aplicaciones en contenedores en producción para 2027.

IBM y Kubernetes

En 2014, IBM fue una de las primeras empresas importantes en unir fuerzas con la comunidad de código abierto de Kubernetes y llevar la orquestación de contenedores a la empresa. Hoy, IBM está ayudando a las empresas a navegar sus viajes continuos 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.

Ya sea que su objetivo sea 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.

Comience con IBM Cloud® Kubernetes Service

Red Hat® OpenShift® en IBM Cloud® ofrece a los desarrolladores de OpenShift una forma rápida y segura de contener e implementar cargas de trabajo empresariales en clústeres de Kubernetes.

Explore Red Hat OpenShift en IBM Cloud

IBM Cloud® Code Engine, una plataforma sin servidor totalmente gestionada, le permite ejecutar contenedores, código de aplicación o trabajos por lotes en un tiempo de ejecución de contenedor totalmente gestionado.

Obtenga más información sobre IBM Cloud Code Engine