¿Qué es la tecnología de virtualización?
1961 - IBM 709 implementa un sistema de tiempo compartido.
La primera tecnología de virtualización en la historia de la informática se implementó en 1961. Por primera vez, la computadora IBM 709 dividió el uso de la CPU en varios intervalos de tiempo extremadamente cortos (1/100 segundos), y cada intervalo de tiempo se utilizó para realizar diferentes tareas. Al sondear estos intervalos de tiempo, una CPU se puede virtualizar o disfrazar como varias CPU, y cada CPU virtual parece estar ejecutándose simultáneamente. Este es un prototipo de máquina virtual.
La función de un contenedor es en realidad similar a la de una máquina virtual. Ya sea un contenedor o una máquina virtual, en realidad están virtualizados en diferentes niveles de la computadora, es decir, usan la lógica para representar recursos, eliminando así las limitaciones físicas y mejorando la utilización de los recursos físicos. La tecnología de virtualización es un concepto abstracto y rico que tiene diferentes significados en diferentes campos o niveles.
Aquí primero hablamos de la estructura jerárquica de la computadora. Para la mayoría de los desarrolladores de software, los sistemas informáticos se pueden dividir en las siguientes jerarquías:
Capa de aplicación
Capa de biblioteca
Capa de sistema operativo
Capa de hardware
Todas las capas son de abajo hacia arriba y cada capa proporciona una interfaz ascendente. Al mismo tiempo, cada capa solo necesita conocer la interfaz de la siguiente capa para llamar a las funciones de la capa inferior para implementar la operación de la capa superior (no necesita conocer el mecanismo operativo específico de la capa inferior).
Sin embargo, debido a que el hardware producido por los primeros fabricantes de computadoras seguía sus propios estándares y especificaciones, la compatibilidad del sistema operativo entre diferentes hardware de computadora era muy pobre, de manera similar, la compatibilidad de diferentes software bajo diferentes sistemas operativos también era pobre; Muy pobre. Por lo tanto, algunos desarrolladores crean artificialmente capas de abstracción entre capas:
Capa de aplicación
Capa de biblioteca
Capa de abstracción de API
Capa de sistema operativo
Capa de abstracción de hardware
Capa de hardware
En lo que a nosotros respecta, la llamada virtualización consiste en crear artificialmente una nueva capa entre las capas superior e inferior. La capa de abstracción permite que el software de la capa superior se ejecute directamente en el nuevo entorno virtual. En pocas palabras, la virtualización consiste en "engañar" a la capa superior accediendo a los módulos funcionales originales de la capa inferior para crear interfaces, logrando así el propósito del desarrollo multiplataforma.
Basándonos en las ideas anteriores, podemos volver a comprender varias tecnologías de virtualización conocidas:
Máquina virtual: una tecnología de virtualización que existe entre la capa de hardware y la capa del sistema operativo.
La máquina virtual "forja" una interfaz de abstracción de hardware e injerta un sistema operativo y las capas superiores a la capa del sistema operativo en el hardware para lograr casi las mismas funciones que una máquina física real. Por ejemplo, si usamos una máquina virtual Android en una computadora con Windows, podemos usar esta computadora para abrir aplicaciones en el sistema Android.
Contenedor: tecnología de virtualización que existe entre la capa del sistema operativo y la capa de la biblioteca de funciones.
Los contenedores "forjan" la interfaz del sistema operativo y colocan funciones encima de la capa de biblioteca de funciones del sistema operativo. Tomemos como ejemplo Docker. Es un contenedor aislado basado en las funciones Namespace y Cgroup del sistema operativo Linux, que puede simular las funciones del sistema operativo. En pocas palabras, si la máquina virtual encapsula y aísla todo el sistema operativo para implementar aplicaciones multiplataforma, entonces el contenedor encapsula y aísla cada aplicación por separado para implementar aplicaciones multiplataforma. Como resultado, los contenedores son mucho más pequeños que las máquinas virtuales y, en teoría, consumen menos recursos.
JVM: Tecnología de virtualización que existe entre la capa de biblioteca de funciones y la aplicación.
La máquina virtual Java también tiene funciones multiplataforma. Las llamadas funciones multiplataforma son en realidad el resultado de la virtualización. Sabemos que el lenguaje Java llama a la biblioteca de funciones del sistema operativo. La JVM establece una capa de abstracción entre la capa de aplicación y la capa de biblioteca de funciones, se adapta a diferentes bibliotecas de funciones del sistema operativo a través de diferentes versiones y proporciona una operación unificada para programas y. entorno de desarrolladores, lo que permite a los desarrolladores llamar a bibliotecas de funciones de diferentes sistemas operativos.
Después de tener una comprensión general de la tecnología de virtualización, podemos comprender la historia del nacimiento de los contenedores. Aunque el concepto de contenedores sólo se hizo popular en todo el mundo después de la aparición de Docker, innumerables pioneros ya estaban explorando esta tecnología de virtualización de futuro antes de Docker.
El predecesor del contenedor "prisión"
1979: Bell Labs inventó chroot
Una de las principales características de los contenedores es el aislamiento de procesos. Ya en 1979, Bell Labs descubrió durante el desarrollo de Unix V7 que cuando se compilaba e instalaba un software de sistema, las variables de todo el entorno de prueba cambiaban. Si desea compilarlo, instalarlo y probarlo la próxima vez, deberá reconstruir y configurar el entorno de prueba. Ya sabes, en esa época, un chip de memoria de 64K costaba 419 dólares. El costo de "destruir y reconstruir rápidamente la infraestructura" era realmente demasiado alto.
Los desarrolladores comenzaron a pensar si podrían aislar un entorno independiente para la reconstrucción y prueba de software dentro del entorno del sistema operativo existente. Como resultado, nació una función de llamada al sistema llamada chroot (cambiar raíz).
Chroot puede redirigir el directorio raíz de un proceso y sus procesos secundarios a una nueva ubicación en el sistema de archivos, lo que significa que puede separar los permisos de acceso a archivos de cada proceso para que el proceso no pueda tocar archivos externos. , por lo que este nuevo entorno aislado también se denomina Chroot Jail. Luego, siempre que copie los archivos del sistema requeridos en Chroot Jail, el software se puede reconfigurar y probar. Este progreso abrió la puerta al aislamiento de procesos y proporcionó funciones simples de aislamiento del sistema para Unix. En particular, la idea de la cárcel sentó las bases para el desarrollo de la tecnología de contenedores. Pero en este momento, la función de aislamiento de chroot se limita al sistema de archivos y el proceso y el espacio de red no se manejan en consecuencia.
En el siglo XXI, la tecnología de máquinas virtuales (VM) se ha vuelto relativamente madura y las personas pueden lograr el desarrollo de sistemas operativos cruzados a través de la tecnología VM. Sin embargo, debido a que la VM necesita encapsular y aislar todo el sistema operativo, consume muchos recursos y es demasiado engorroso en un entorno de producción. Como resultado, la gente comenzó a buscar una tecnología de virtualización más portátil y nacieron muchas tecnologías de aislamiento de procesos basadas en extensiones chroot.
Un día como hoy del año 2000, FreeBSD lanzó FreeBSD Jail.
21 Unos años después del nacimiento de chroot, FreeBSD 4.0 lanzó FreeBSD Jail, un sistema de intercambio de entornos de minihost, que amplió el mecanismo existente de ch root. En FreeBSD Jail, el programa tiene su propio sistema de archivos, proceso independiente y espacio de red. Los procesos en la cárcel no pueden acceder ni ver archivos, procesos y recursos de red fuera de la cárcel.
2006 54 38 0-El nacimiento de Linux Vserver
En 2001, el kernel de Linux agregó Linux VServer (servidor virtual) para proporcionar funciones de virtualización para sistemas Linux. Linux VServer también utiliza un mecanismo de cárcel, que puede dividir el sistema de archivos, la dirección de red y la memoria en un sistema informático, permitiendo que se ejecuten múltiples unidades virtuales al mismo tiempo.
Un día como hoy de 2004, Sun lanzó el contenedor Solaris.
Esta tecnología también fue desarrollada por chroot. En febrero de 2004, SUN lanzó la versión beta 10 del sistema Solaris similar a Unix, que agregó contenedores de funciones de virtualización del sistema operativo e introdujo mejoras en la versión oficial posterior de Solaris 10.
Los contenedores Solaris admiten sistemas x86 y SPARC, y SUN ha creado una función de zona para trabajar con contenedores. El primero es un servidor virtual completamente aislado en un único sistema operativo. El aislamiento del proceso se logra mediante el control de recursos del sistema y la separación de límites proporcionada por zonas.
En 2005 nació OpenVZ.
Al igual que Solaris Containers, proporciona virtualización, aislamiento, administración de recursos y puntos de control de estado mediante la aplicación de parches al kernel de Linux. Cada contenedor OpenVZ tiene un conjunto independiente de sistemas de archivos, usuarios y grupos de usuarios, árboles de procesos, redes, dispositivos y objetos IPC.
La mayoría de las tecnologías de aislamiento de procesos en este período se basaron en el modo Jail, que básicamente realizó la operación de aislamiento de recursos relacionados con procesos. Sin embargo, debido a la falta de escenarios de uso correspondientes en producción y desarrollo en este momento, esta tecnología se ha limitado a un mundo pequeño y limitado.
En este momento, una nueva tecnología llamada "nube" está surgiendo silenciosamente...
El nacimiento de la "nube"
Desde 2003 hasta 2006, Google publicó tres artículos de diseño de productos, desde el modelo informático hasta el modelo de almacenamiento, creando una arquitectura informática distribuida y sentando las bases para la tecnología informática de big data. Sobre esta base, Google propuso subversivamente el plan "Google 101" y creó oficialmente el concepto de "nube". Durante un tiempo, nuevas palabras como "computación en la nube" y "almacenamiento en la nube" causaron sensación en todo el mundo. Posteriormente, gigantes de la industria como Amazon e IBM también anunciaron sus propios planes de "nube", anunciando la llegada de la era de la tecnología de la "nube".
También fue a partir de este período cuando la tecnología de aislamiento de procesos entró en una etapa más avanzada. Según el marco de computación en la nube propuesto por Google, un proceso aislado no es solo una prisión aislada del mundo exterior, sino también estática. Deben ser como contenedores portátiles, que además de estar aislados del mundo exterior, también puedan controlarse e implementarse para lograr una alta disponibilidad y escalabilidad multiplataforma en escenarios de aplicaciones distribuidas.
Un día como hoy de 2006, Google lanzó el contenedor de procesos, que luego pasó a llamarse Cgroups.
Process Container es el prototipo de tecnología de "contenedor" a los ojos de los ingenieros de Google. Se utiliza para limitar, contabilizar y aislar recursos (CPU, memoria, E/S de disco, red, etc.). en un proceso grupal. En realidad, esto es consistente con el objetivo de la tecnología de aislamiento de procesos mencionada anteriormente. A medida que la tecnología maduró, Process Container se lanzó oficialmente en 2006. Entró en la columna vertebral del kernel de Linux al año siguiente y pasó a llamarse oficialmente Cgroups. Esto marcó el comienzo de la reexaminación y el reconocimiento del concepto de "contenedor" en el mundo. Campamento de Linux.
Un día como hoy de 2008 nació la herramienta contenedora de Linux LXC.
En 2008, al combinar las capacidades de administración de recursos de Cgroups con las capacidades de aislamiento de vistas de los espacios de nombres de Linux, apareció una tecnología de contenedor completa LXC (Linux Container) en el kernel de Linux, que se usa ampliamente en la actualidad. de la tecnología de contenedores. Sabemos que un proceso puede llamar a todos los recursos de su máquina física, lo que desplazará los recursos disponibles de otros procesos. Para limitar esta situación, los desarrolladores del kernel de Linux han proporcionado una característica donde los procesos que se ejecutan en Cgroups son similares a los procesos que se ejecutan en espacios de nombres, pero los Cgroups pueden limitar los recursos disponibles para el proceso. Aunque las capacidades proporcionadas a los usuarios por LXC son muy similares a las primeras tecnologías sandbox de Linux antes mencionadas, como Jails y OpenVZ, a medida que varias distribuciones de Linux ocupan rápidamente el mercado de servidores comerciales, muchos pioneros de la computación en la nube, incluido Google, han podido utilizar plenamente esto. La primera tecnología de contenedores ha permitido a LXC ganar mucho más espacio de desarrollo que sus predecesores en el campo de la computación en la nube.
Ese mismo año, Google lanzó GAE (Google App Engine), la primera plataforma de alojamiento de aplicaciones basada en LXC, y proporcionó la plataforma de desarrollo como servicio por primera vez.
GAE es un servicio de plataforma distribuida. Google proporciona a los usuarios un entorno de desarrollo, una plataforma de servidor, recursos de hardware y otros servicios a través de tecnología de virtualización. Los usuarios pueden personalizar y desarrollar sus propias aplicaciones basadas en esta plataforma y distribuirlas a través de los servidores y recursos de Internet de Google, lo que reduce en gran medida los requisitos de su propio hardware.
Cabe mencionar que en GAE, Google utiliza Borg (el predecesor de Kubernetes), una herramienta que puede programar y programar LXC. Borg es un sistema de gestión de clústeres a gran escala utilizado internamente por Google, que puede albergar cientos de miles de tareas, miles de aplicaciones diferentes y gestionar decenas de miles de máquinas al mismo tiempo. Borg logra una alta utilización de recursos mediante la gestión de permisos, el intercambio de recursos y el aislamiento del rendimiento. Puede admitir aplicaciones de alta disponibilidad, reducir la probabilidad de fallas mediante estrategias de programación y proporcionar lenguaje de descripción de tareas, monitoreo de tareas en tiempo real y herramientas de análisis. Si los contenedores aislados son contenedores, se puede decir que Borg es el primer sistema portuario y LXC Borg es el primer marco de disposición de contenedores. En este punto, el contenedor ya no es una simple función de aislamiento de procesos, sino un modo de empaquetado de programas flexible y liviano.
2011——Cloud OEM lanzó Woden.
Cloud Foundry es una plataforma en la nube lanzada en 2009 por VMware, un conocido proveedor de servicios en la nube. Este es también el primer proyecto de la industria que define formalmente el modelo PaaS (Plataforma como Servicio). Conceptos como "los proyectos PaaS permiten a los desarrolladores centrarse en la lógica empresarial en lugar de la infraestructura a través de la gestión, disposición y programación directa de aplicaciones" y "los proyectos PaaS encapsulan y lanzan aplicaciones a través de tecnología de contenedores" provienen todos de Cloud Foundry. Warden es el contenedor de gestión de recursos central de Cloud Foundry. Inicialmente, fue empaquetado por LXC y luego reconstruido en una arquitectura que se ejecuta directamente en Cgroups y espacios de nombres de Linux.
Con el desarrollo continuo del mercado de servicios "en la nube", han surgido varios proyectos PaaS uno tras otro, y la tecnología de contenedores también ha marcado el comienzo de una era de crecimiento explosivo. Una gran cantidad de proyectos empresariales relacionados con la tecnología de contenedores. han surgido uno tras otro. Por supuesto, mucha gente conoce la historia posterior. Nació una nueva empresa llamada Docker, lo que convirtió a Docker en casi sinónimo de "contenedores".
Nació Docker
2013-Nació Docker
Docker era originalmente un proyecto interno de una empresa de servicios PaaS llamada dotCloud, y luego la empresa pasó a llamarse Docker. . Docker era similar a Warden al principio, usaba LXC y luego comenzó a reemplazar LXC con su propio libcontainer. A diferencia de otros proyectos de contenedores puros, Docker presenta un ecosistema para administrar contenedores, que incluye un modelo de imagen de contenedor eficiente y en capas, registros de contenedores globales y locales, API REST clara, línea de comando, etc.
Docker en sí es en realidad un paquete que pertenece a LXC, que proporciona una interfaz de contenedor fácil de usar. Su característica más importante es la introducción de imágenes de contenedores. Docker empaqueta una aplicación y el entorno necesario para ejecutar la aplicación en un único archivo a través de una imagen de contenedor. La ejecución de este archivo generará un contenedor virtual.
Más importante aún, el proyecto Docker también adopta la idea de Git: introduce el concepto de "capa" en la producción de imágenes de contenedores. Basados en diferentes "capas", los contenedores pueden agregar información diferente, de modo que puedan versionarse, copiarse, compartirse y modificarse como el código normal. Al crear imágenes de Docker, los desarrolladores pueden distribuir software directamente a través de repositorios de alojamiento de imágenes como DockerHub.
En otras palabras, el nacimiento de Docker no solo resolvió el problema de la contenedorización del desarrollo de software, sino que también resolvió el problema de la distribución de software, proporcionando una solución completa para el proceso del ciclo de vida del software en la era de la "nube". .
Pronto, Docker se hizo famoso en la industria y fue seleccionado por muchas empresas como el estándar para la construcción de infraestructura de computación en la nube.
La tecnología de contenedores también se ha convertido en la tecnología de vanguardia de la industria, y la construcción ecológica alrededor de contenedores se ha llevado a cabo en pleno apogeo.
La batalla entre los contenedores y los ríos y lagos
El auge de una nueva tecnología también ha traído nuevos mercados, y una batalla en el océano azul por los contenedores es inevitable.
El lanzamiento del sistema operativo central
Después de la explosión de Docker, CoreOS nació a finales del mismo año. CoreOS es un sistema operativo liviano basado en el kernel de Linux. Está especialmente diseñado para la construcción de infraestructura de clústeres de computadoras en la era de la computación en la nube. Tiene las características de automatización, fácil implementación, seguridad, confiabilidad y escalabilidad. En aquel momento tenía una etiqueta muy destacada: un sistema operativo diseñado para contenedores.
Con la ayuda de Docker, CoreOS rápidamente se hizo popular en el campo de la computación en la nube. Durante un tiempo, Docker CoreOS se convirtió en el socio de oro para la implementación de dispositivos de contenido en la industria. Al mismo tiempo, CoreOS también ha hecho grandes contribuciones a la promoción y construcción de la comunidad de Docker.
Sin embargo, los crecientes trabajadores portuarios parecen tener mayores "ambiciones". Docker no se contentó con ser simplemente "una simple unidad básica". Desarrolló una serie de componentes de contenedores relacionados, adquirió algunas empresas de tecnología de contenedores y comenzó a construir su propia plataforma ecológica de contenedores. Obviamente, esto forma una relación competitiva directa con CoreOS.
2014: CoreOS lanza el cohete del motor de contenedores de código abierto.
A finales de 2014, CoreOS lanzó su propio cohete con motor de contenedor (rkt para abreviar) en un intento de competir con Docker. Al igual que Docker, rkt puede ayudar a los desarrolladores a empaquetar aplicaciones y paquetes de dependencia en contenedores portátiles, simplificando las tareas de implementación, como la creación de entornos. La diferencia entre rkt y Docker es que rkt no tiene las "funciones amigables" que Docker ofrece a los usuarios empresariales, como herramientas de aceleración de servicios en la nube, sistemas de clúster, etc. A su vez, lo que rkt quiere hacer es un estándar industrial más puro.
2014: Google lanza Kubernetes, el motor de orquestación de contenedores de código abierto.
Para adaptarse a los problemas de implementación y gestión de contenedores de clústeres a gran escala en escenarios de nube híbrida, Google lanzó el sistema de gestión de clústeres de contenedores Kubernetes (K8S para abreviar) en junio de 2004. K8S proviene de Borg que mencionamos anteriormente y tiene la función de administrar y organizar contenedores en el entorno de producción de escenarios de nube híbrida. Kubernetes introduce la función Pod sobre la base de contenedores, lo que permite que diferentes contenedores se comuniquen entre sí y realicen la agrupación e implementación de contenedores.
Gracias a la fuerte acumulación de Google en la construcción de infraestructura de clústeres a gran escala, K8S, que nació de Borg, se ha convertido rápidamente en una aplicación estándar de la industria y puede considerarse una herramienta esencial para la organización de contenedores. Como miembro importante del ecosistema de contenedores, Google se ha puesto del lado de CoreOS en la disputa de contenedores entre Docker y rkt, y considera el soporte de K8S para rkt como un hito importante.
2015: Docker lanzó la herramienta de administración de clústeres de contenedores Docker Swarm.
En respuesta, Docker también comenzó a agregar la herramienta de administración de clústeres de contenedores Docker swarm a la versión Docker 1.12 lanzada en 2015.
Posteriormente, en abril de 2015, Google invirtió 120.000 dólares estadounidenses en CoreOS y cooperó con Core OS para lanzar la primera versión de distribución empresarial, Kubernetes-estructural. Desde entonces, el mundo de los contenedores se ha dividido en dos bandos: la facción de Google y la facción de Docker.
La competencia entre las dos facciones se ha intensificado y gradualmente se ha expandido hasta la batalla por la formulación de estándares industriales.
2065438 Junio de 2005: Docker tomó la iniciativa en el establecimiento de OCI.
Docker y la Fundación Linux establecieron la organización OCI (Open Container Initiative) para "formular y mantener especificaciones formales para formatos de imágenes de contenedores y tiempos de ejecución de contenedores" y desarrollar un estándar abierto en torno a formatos y tiempos de ejecución de contenedores estándar de la industria. .
2065 438 Julio de 2005: Google tomó la iniciativa en el establecimiento de CNCF.
En julio del mismo año, Google, que se centra en la "nube", también estableció conjuntamente la CNCF (Cloud Native Computing Foundation) con la Fundación Linux y convirtió a Kubernetes en el primer proyecto de código abierto incluido en el sistema de gestión CNCF en "Construcción de computación nativa de la nube: una arquitectura centrada en la infraestructura que programa dinámicamente microservicios, contenedores y aplicaciones y facilita su uso generalizado".
Estas dos bases de código abierto construidas en torno a proyectos de código abierto relacionados con contenedores han desempeñado un papel importante en la promoción del desarrollo futuro de la nube. Se complementan entre sí, desarrollan una serie de estándares industriales de facto y se convierten en la organización de código abierto más activa en la actualidad.
La ecología de Kubernetes unifica ríos y lagos
Aunque Docker ha estado presionando a rkt para que se convierta en un merecido hermano contenedor durante muchos años, como una gran ecología de tecnología de contenedores, la ecología de Docker ha estado en El contenedor posterior, Kubernetes, perdió ante Google en la batalla por el ranking.
A medida que más y más desarrolladores utilizan Docker para implementar contenedores, la importancia de las plataformas de orquestación se ha vuelto cada vez más prominente. Después de que Docker se hizo popular, surgieron uno tras otro una gran cantidad de proyectos de código abierto y plataformas patentadas para resolver el problema de la disposición de los contenedores. Mesos, Docker Swarm y Kubernetes proporcionan diferentes abstracciones para gestionar contenedores. Durante este período, para los desarrolladores de software, elegir una plataforma de orquestación de contenedores es como una apuesta, porque una vez que la plataforma elegida falla en la competencia futura, significa que el desarrollo posterior perderá mercado en el futuro. Al igual que en la batalla entre los sistemas de telefonía móvil Android, iOS y WP, sólo los ganadores pueden obtener mayores perspectivas de mercado y los perdedores pueden incluso desaparecer. La batalla por las plataformas de diseño de contenedores ha comenzado.
Nació 2016-CRI-O
En 2016, el proyecto Kubernetes lanzó CRI (Container Runtime Interface), creando kubelet (un nodo de clúster utilizado para crear pods e iniciar contenedores Agente) es capaz de utilizar diferentes entornos de ejecución de contenedores compatibles con OCI sin tener que recompilar Kubernetes. Basado en CRI, nació un proyecto de código abierto llamado CRI-O para proporcionar un entorno de ejecución liviano para Kubernetes.
CRI-O permite a los desarrolladores ejecutar contenedores directamente desde Kubernetes, lo que significa que Kubernetes puede gestionar cargas de trabajo en contenedores sin depender de motores de contenedores tradicionales como Docker. De esta manera, en la plataforma Kubernetes, siempre que el contenedor cumpla con el estándar OCI (no necesariamente Docker), se puede ejecutar CRI-O, lo que permite que el contenedor vuelva a su función más básica: puede empaquetar y ejecutar programas nativos en la nube. .
Al mismo tiempo, la aparición de CRI-O ha hecho que las personas que utilizan la tecnología de contenedores para la gestión, operación y mantenimiento de software descubran que la pila de tecnología de Kubernetes (como el sistema de programación, CRI y CRI-O ) es más eficiente que el motor de contenedores estándar que viene con Docker. Más adecuado para gestionar entornos de producción complejos. Se puede decir que CRI-O coloca al orquestador de contenedores en una posición importante en la pila de tecnología de contenedores, reduciendo así la importancia del motor de contenedores.
Con K8S tomando la iniciativa con éxito, Docker cometió un error al promocionar su propia plataforma de disposición de contenedores Docker Swarm. A finales de 2016, hubo rumores en la industria de que Docker podría cambiar el estándar Docker para adaptarse mejor a Swarm. Esto hace que muchos desarrolladores prefieran Kubernetes, que es más compatible con el mercado, a la hora de elegir una plataforma.
Entonces, después de entrar en 2017, más fabricantes están dispuestos a apostar por K8S e invertir en la construcción de un ecosistema relacionado con K8S. La batalla por el despliegue de contenedores termina con una victoria del campo de Google. Al mismo tiempo, CNCF con K8S como núcleo también ha comenzado a desarrollarse rápidamente y se ha convertido en la base de proyectos de código abierto más popular. En los últimos dos años, empresas de tecnología chinas, incluidas Alibaba Cloud, Tencent y Baidu, se unieron a CNCF y adoptaron plenamente la tecnología de contenedores y la nube nativa.
Etiqueta
Desde la exploración de funciones de aislamiento de procesos en laboratorios hace décadas hasta la construcción de infraestructura nativa de la nube en entornos de producción, se puede decir que la tecnología de contenedores ha crecido desde una pequeña El desarrollo de contenedores para convertirlo en un puerto moderno a gran escala representa los esfuerzos de generaciones de desarrolladores. Es previsible que la tecnología de contenedores sea una infraestructura importante para el desarrollo, la operación y el mantenimiento de software de aquí al futuro durante mucho tiempo.