Nota perev. : Ya hemos escrito más de una publicación (ver enlaces al final del artículo) sobre tiempos de ejecución de contenedores (tiempos de ejecución de contenedores); por regla general, se analizan en el contexto de Kubernetes. Sin embargo, a menudo estos materiales despertaron las preguntas de los lectores, lo que indica una falta de comprensión de dónde vino el próximo proyecto, cómo está conectado con otros y qué está sucediendo en todo este contenedor "zoológico".
Un artículo reciente de Phil Estes, Director Técnico de IBM Watson & Cloud Platform para Contenedores y Arquitectura de Linux, proporciona una excelente retrospectiva sobre cómo navegar y obtener una comprensión más amplia de quién ha perdido (o nunca atrapado) el hilo de los eventos. Siendo uno de los mantenedores de los proyectos Moby y de contenedores, miembro de los comités técnicos de Open Container Initiative (OCI) y Moby, y también con el estatus de Capitán Docker, el autor escribe sobre el pasado, presente y futuro del nuevo mundo maravilloso de tiempos de ejecución de contenedores. Y para los más vagos, el material comienza con un TL compacto; DR sobre el tema ... Resultados clave
- Con el tiempo, la elección entre tiempos de ejecución de contenedores ha crecido, proporcionando más opciones que el popular motor Docker.
- La Open Container Initiative (OCI) ha estandarizado con éxito el concepto de contenedor y la imagen del contenedor para garantizar la interoperabilidad ("interoperabilidad" - aprox. Transl.) Entre entornos de tiempo de ejecución.
- Kubernetes ha agregado la Interfaz de tiempo de ejecución de contenedor (CRI), que permite que los contenedores se conecten a entornos de tiempo de ejecución con la capa de orquestación subyacente en K8.
- Las innovaciones en esta área permiten que los contenedores aprovechen la virtualización ligera y otras técnicas de aislamiento únicas para los crecientes requisitos de seguridad.
- Con OCI y CRI, la interoperabilidad y la elección se han convertido en una realidad en el ecosistema de contenedores de tiempo de ejecución y entornos de orquestación.
La tecnología de contenedores ha existido durante bastante tiempo en el mundo de los sistemas operativos Linux: las primeras ideas sobre espacios de nombres separados para sistemas y procesos de archivos aparecieron hace más de una década. Y en el pasado relativamente reciente, apareció el LXC y se convirtió en la forma estándar para que los usuarios de Linux interactúen con la poderosa tecnología de aislamiento oculta en el kernel de Linux.
Sin embargo, incluso a pesar de los intentos
de LXC de ocultar la complejidad de combinar varios "elementos internos" tecnológicos de lo que generalmente llamamos un contenedor hoy en día, los contenedores siguieron siendo una especie de magia y se fortalecieron solo en el mundo de aquellos que tenían un conocimiento especial y no obtuvieron una amplia distribución entre las masas.
Todo cambió en 2014 con
Docker , cuando apareció un nuevo contenedor amigable para los desarrolladores para la misma tecnología de kernel de Linux que LXC tenía en servicio; después de todo, las primeras versiones de Docker "detrás de escena" usaron LXC, y los contenedores se convirtieron - un fenómeno de masas real, ya que los desarrolladores estaban imbuidos de la simplicidad y las posibilidades de reutilizar imágenes de contenedores Docker y comandos simples para trabajar con ellos.
Por supuesto, Docker no fue el único que quería ganar una participación en el mercado de contenedores cuando la exageración que los acompañó no pensó en disminuir después del primer interés explosivo en 2014. Con los años, han surgido una variedad de ideas alternativas para entornos de contenedores ejecutables de
CoreOS (rkt) ,
Intel Clear Containers ,
hyper.sh (virtualización basada en contenedores livianos) y
Singularity and
shifter en el mundo de la investigación de computación de alto rendimiento (HPC).
El mercado continuó creciendo y madurando, y con la
Open Container Initiative (OCI) surgió el esfuerzo de estandarizar las ideas iniciales promovidas por Docker. Hoy en día, muchos entornos de contenedores ejecutables ya son compatibles con OCI o, en el camino hacia esto, ofrecen a los fabricantes las mismas condiciones para promover sus características y capacidades que se centran en una aplicación en particular.
Popularidad de Kubernetes
La siguiente etapa en la evolución de los contenedores fue combinar contenedores informáticos distribuidos a la microservicios con contenedores, y todo esto en el nuevo mundo de iteraciones rápidas de desarrollo e implementación (podemos decir que DevOps), que estaba ganando impulso activamente junto con la popularidad de Docker.
Aunque
Apache Mesos y otras plataformas de orquestación de software existían antes de que
Kubernetes dominara, los
K8 despegaron rápidamente de un pequeño proyecto de código abierto de Google al proyecto principal de
Cloud Native Computing Foundation (CNCF) .
Nota perev. : ¿Sabes que CNCF apareció en 2015 con motivo del lanzamiento de Kubernetes 1.0? Al mismo tiempo, el proyecto fue transferido por Google a una nueva organización independiente que se convirtió en parte de The Linux Foundation.
Evento de lanzamiento de K8s 1.0 patrocinado, entre otros, Mesosphere, CoreOS, Mirantis, OpenStack, Bitnami
De las noticias sobre el lanzamiento de Kubernetes 1.0 en ZDNetIncluso después de que Docker lanzó la plataforma de orquestación rival,
Swarm , integrada en Docker y que presenta la simplicidad de Docker y un enfoque en la configuración predeterminada de clúster seguro, esto ya no fue suficiente para detener el creciente interés en Kubernetes.
Sin embargo, muchos interesados fuera de las comunidades nativas en la nube de rápido crecimiento estaban confundidos. Un observador promedio no podía entender lo que estaba sucediendo: ¿Kubernetes pelea con Docker o su cooperación? Debido a que Kubernetes era solo una plataforma de orquestación, se requería un entorno de contenedor ejecutable que lanzara directamente los contenedores orquestados en Kubernetes. Desde el principio, Kubernetes utilizó el motor Docker y, a pesar de la tensión competitiva entre Swarm y Kubernetes, Docker seguía siendo el tiempo de ejecución predeterminado y era necesario para que el clúster de Kubernetes funcionara.
Con una pequeña cantidad de tiempos de ejecución de contenedores distintos de Docker, parecía claro que emparejar el tiempo de ejecución con Kubernetes requeriría una interfaz especialmente escrita, shim, para cada tiempo de ejecución. La falta de una interfaz clara para implementar tiempos de ejecución de contenedor hizo que fuera muy difícil agregar soporte para nuevos tiempos de ejecución en Kubernetes.
Interfaz de tiempo de ejecución de contenedor (CRI)
Para resolver la creciente complejidad de implementar tiempos de ejecución en Kubernetes, la comunidad definió una interfaz - funciones específicas que el tiempo de ejecución del contenedor debería implementar dentro de Kubernetes - nombrándola
Interfaz de tiempo de ejecución del contenedor (CRI) ( apareció en Kubernetes 1.5 - aprox. Transl.) . Este evento no solo ayudó al problema del creciente número de fragmentos de la base de código de Kubernetes que afecta el uso de tiempos de ejecución de contenedores, sino que también ayudó a comprender qué funciones deberían ser compatibles con tiempos de ejecución potenciales si quieren cumplir con CRI.
Como puede suponer, CRI espera cosas muy simples del tiempo de ejecución. Dicho entorno debería ser capaz de iniciar y detener pods, manejar todas las operaciones con contenedores en el contexto de pods (start, stop, pause, kill, delete) y también admitir la gestión de imágenes de contenedores utilizando el registro. También hay funciones auxiliares para recopilar registros, métricas, etc.
Cuando aparecen nuevas características en Kubernetes, si dependen de la capa del tiempo de ejecución del contenedor, dichos cambios se realizan en la API CRI versionada. Esto a su vez crea una nueva dependencia funcional en Kubernetes y requiere el lanzamiento de nuevas versiones de tiempos de ejecución que admitan nuevas características (un ejemplo reciente son los espacios de nombres de usuario).
Paisaje actual de CRI
A partir de 2018, hay varias opciones para usar como tiempos de ejecución de contenedores en Kubernetes. Como se muestra en la siguiente ilustración, una de las opciones reales sigue siendo Docker con su
dockershim que implementa la API CRI. Y, de hecho, en la mayoría de las instalaciones de Kubernetes en la actualidad, es él, Docker, quien sigue siendo el tiempo de ejecución predeterminado.
Una de las consecuencias interesantes de la tensión entre la estrategia de orquestación de Docker con Swarm y la comunidad de Kubernetes fue un proyecto conjunto, que tomó la base del tiempo de ejecución de Docker y reunió de él un nuevo proyecto de código abierto desarrollado conjuntamente -
contenedor . Con el tiempo, el contenedor fue transferido a CNCF, la misma organización que administra y posee el proyecto Kubernetes.
( Nota traducida : describimos la apariencia del contenedor con más detalle en un artículo separado ).
Desde el anuncio de containerd en el blog de DockerContainerd, al ser una implementación de tiempo de ejecución simple, básica e
independiente de la empresa
(no obstinada) para Docker y Kubernetes (a través de CRI), comenzó a ganar popularidad como un posible reemplazo para Docker en muchas instalaciones de Kubernetes. Hasta la fecha, tanto IBM Cloud como Google Cloud tienen clústeres basados en contenedores en acceso temprano / modo beta. Microsoft Azure también prometió cambiar a contenedor en el futuro, y Amazon todavía está considerando varias opciones para tiempos de ejecución para sus soluciones de contenedor (ECS y EKS), mientras continúa utilizando Docker.
Red Hat ha entrado en el espacio de
tiempo de ejecución del contenedor creando una implementación CRI simple llamada
cri-o basada en la implementación de referencia OCI,
runc . Docker y containerd también están basados en runc, pero los creadores de cri-o afirman que sus tiempos de ejecución son "lo suficiente" para Kubernetes y que no necesitan más: simplemente agregaron las funciones más necesarias para implementar Kubernetes CRI sobre el binario runc base.
( Nota traducida : escribimos más sobre el proyecto CRI-O en este artículo , y aquí sobre su desarrollo posterior en forma de podman).Proyectos de virtualización livianos: Intel Clear Containers e hyper.sh - aparecieron en la naturaleza de OpenStack Foundation,
contenedores Kata , y ofrecen su visión de contenedores virtualizados para aislamiento adicional usando una implementación de CRI llamada
frakti . Tanto cri-o como containerd también funcionan con contenedores Kata, por lo que su tiempo de ejecución compatible con OCI se puede seleccionar como una opción conectable.
Prediciendo el futuro
Decir que sabes que el futuro generalmente no es muy sabio, pero al menos podemos arreglar algunas tendencias emergentes a medida que el ecosistema de contenedores pasa del entusiasmo y la exageración a una etapa más madura de nuestra existencia.
Hubo temores tempranos de que el ecosistema del contenedor formaría un entorno fragmentado, cuyos diferentes participantes presentarían ideas diferentes e incompatibles sobre lo que es un contenedor. Gracias al trabajo de OCI y las acciones responsables de los principales proveedores y participantes, vimos un entorno saludable en la industria entre las ofertas de software que preferían la compatibilidad con OCI.
Incluso en entornos más nuevos donde el estándar de uso de Docker encontró menos resistencia debido a las restricciones existentes, por ejemplo, en HPC, todos los intentos de crear entornos de contenedores de contenedores no basados en Docker también llamaron la atención sobre la OCI. Se están debatiendo si OCI puede ser una solución viable para las necesidades específicas de las comunidades de científicos e investigadores.
Además de la estandarización de los tiempos de ejecución de los contenedores de complementos en Kubernetes con CRI, podemos imaginar un mundo en el que los desarrolladores y administradores puedan elegir las herramientas y las pilas de software adecuadas para sus tareas, esperando y observando la interoperabilidad en todo el ecosistema de contenedores.
Considere un ejemplo específico para comprender mejor este mundo:
- Un desarrollador con un MacBook usa Docker para Mac para desarrollar su aplicación e incluso usa el soporte Kubernetes incorporado (Docker funciona como CRI runtime aquí) para intentar implementar la nueva aplicación en los pods K8.
- La aplicación pasa a través de CI / CD en el software del proveedor, que utiliza runc y un código especial (escrito por el proveedor) para empaquetar la imagen OCI y cargarla en el registro corporativo de contenedores para la prueba.
- La instalación local del clúster de Kubernetes, trabajando con containerd como un tiempo de ejecución CRI, ejecuta un conjunto de pruebas para la aplicación.
- Esta compañía, por alguna razón, eligió contenedores Kata para ciertas cargas de trabajo en producción, por lo que cuando implementa la aplicación, comienza en pods con containerd configurado para usar contenedores Kata como tiempo de ejecución en lugar de runc.
Todo el escenario descrito funciona maravillosamente debido a la compatibilidad con la especificación OCI para entornos e imágenes en tiempo de ejecución, y al hecho de que CRI proporciona la flexibilidad para elegir el tiempo de ejecución.
Esta posible flexibilidad y elección hace que el ecosistema de contenedores sea realmente notable y también es una condición muy importante para la madurez de la industria, que ha crecido tan rápidamente desde 2014. En el umbral de 2019 y los años siguientes, veo un futuro brillante con innovaciones continuas y flexibilidad para aquellos que usan y crean plataformas basadas en contenedores.
Se puede encontrar más información sobre este tema en una reciente charla de Phil Estes en QCon NY: “
CRI Runtimes Deep Dive: Who's Running My Kubernetes Pod!? "
PD del traductor
Lea también en nuestro blog: