Autor |
Fuente de Zhang Lei | Cuenta oficial nativa de Alibaba Cloud
2020 está destinado a ser extraordinario. Comienza en la neblina y termina con asombro, haciendo que el futuro sea aún más confuso. Entonces, ¿qué pasa con los contenedores nativos y la nube 2020? ¿Recuerdas cómo empezó? ¿A dónde irá?
Kubernetes: la abstracción estándar para la infraestructura empresarial
En 2020, nadie cuestionará la racionalidad de que un equipo de plataforma adopte Kubernetes como su infraestructura. De hecho, el proyecto Kubernetes 2020 ha estado muy cerca de completar su misión más importante, que es traer una capa de abstracción de plataforma a la infraestructura de computación en la nube que permite al equipo de la plataforma construir "todo" en base a esto .
Hemos podido ver que la comunidad nativa de la nube de hoy ha comenzado a reconocer ampliamente el posicionamiento y el valor del proyecto Kubernetes como "La plataforma para la plataforma", y cada vez más equipos de plataformas están construyendo varias plataformas de nivel superior basadas en Kubernetes, como PaaS. / Serverless / AI Platform / Database PaaS y así sucesivamente. La API declarativa orientada al estado final y el controlador "trabajador" detrás de ella proporcionan una solución que puede lograr un equilibrio entre la complejidad y la usabilidad para el desafiante problema técnico de la "abstracción de la capa de infraestructura de construcción". Sobre esta base, el proyecto Kubernetes tiene una ecología integrada enorme, lo que hace que esta "abstracción estándar de la infraestructura empresarial" se convierta gradualmente en un hecho reconocido en la industria.
Y lo que es más importante, el verdadero éxito de Kubernetes es que realmente apuesta por la construcción de métodos abstractos en lugar de las abstracciones en sí mismas. En la mayoría de los casos, las empresas construyen plataformas de nivel superior basadas en Kubernetes, e introducirán otras abstracciones como suplementos, e incluso reemplazarán u ocultarán algunas de las abstracciones integradas de Kubernetes : CloneSet de código abierto de Alibaba , la práctica GameStatefulSet de Tencent y otros tipos extendidos. Las cargas de trabajo y demás son los mejores ejemplos de esta tendencia.
Con la mejora gradual de las capacidades del ecosistema de Kubernetes desde la base hasta la capa de aplicación, en 2020, más grandes empresas de terminales de Internet comenzarán a unirse al escalón nativo de la nube. Vimos que Apple, el punto de referencia ecológico original de Mesos, se convirtió en el protagonista absoluto de KubeCon 2020 en América del Norte, y el gigante financiero MasterCard compartió su caso de aterrizaje interno de la construcción de una plataforma de entrega de aplicaciones cross-cloud y cross-runtime basada en proyectos OAM, Kubernetes y Crossplane. Y es particularmente digno de mención es que, en el pasado, estas tecnologías subyacentes dan una impresión "conservadora" a las grandes empresas que no están en la nube; en 2020, han recurrido a muchas tecnologías emergentes como Virtual Cluster y la aplicación estándar de técnicas de modelado que aterrizan en Y pensando. El profundo impacto de la ola nativa de la nube en toda la industria de la tecnología es evidente.
Además, no es difícil observar que la enorme popularidad de Kubernetes y la ecología de capa superior basada en él se están volviendo cada vez más convergentes con la ruta de desarrollo de Android . Android puede abstraer e integrar diferentes dispositivos de hardware, como teléfonos móviles, televisores e incluso automóviles de una manera unificada para el siguiente, y exponer una interfaz de desarrollo unificada para que los programadores puedan utilizar esta abstracción unificada. Acceda o disfrute de estas capacidades de infraestructura. Este posicionamiento es muy similar al de Kubernetes, la única diferencia aquí es que el programador del servicio de Android es el desarrollador de la APP, mientras que el "programador" del servicio de Kubernetes es el creador de la plataforma. En este contexto, noticias como "Kubernetes abandona Docker" serán fáciles de entender: Android en sí no necesita centrarse en qué marca de batería de teléfono móvil es.
Este camino también puede ser un "juego" en el que Google es mejor: promover un "sistema operativo" de forma gratuita, y la forma de obtener un valor comercial real es "cosechar" el valor ecológico de la capa superior del sistema operativo, no el sistema operativo. sí mismo. Después de todo, los usuarios no gastarán dinero para comprar Android. Por lo tanto, Google Cloud actualmente es todo incluido , es a través de Anthos , como la base de nube híbrida de Kubernetes, los servicios de Google Cloud se entregan a cualquier centro de datos del mundo.
La "arquitectura de tres niveles" de la computación en la nube se rompe
Durante mucho tiempo, la comprensión de la industria de la computación en la nube se ha centrado en el modelo clásico de arquitectura de tres niveles de "SaaS + PaaS + IaaS". Sin embargo, en 2020, con la tremenda popularidad de la tecnología nativa de la nube, descubrimos que este modelo parece estar enfrentando desafíos.
La tecnología nativa de la nube actual se originó a partir de la revolución tecnológica innovadora de Docker y los contenedores, y se benefició de la popularización duradera de la PaaS clásica (como Cloud Foundry). Finalmente, bajo la doble atención de los desarrolladores y creadores de plataformas, Kubernetes Ecología como el portaaviones finalmente aterrizó.
En 2020, con la madurez gradual de las tecnologías nativas de la nube, la forma de las plataformas de administración de aplicaciones orientadas al usuario cambiará gradualmente desde la forma clásica de PaaS (es decir, la PaaS empresarial) con Cloud Foundry / Heroku como el cuerpo principal del servicio de aplicaciones ligero. Por ejemplo, Shipa y Kalm se están acercando. Sin embargo, el App Service ligero es esencialmente una réplica de la experiencia de Heroku en la base de Kubernetes. Si bien proporciona una excelente experiencia para el desarrollador, también hereda lo "cerrado" e "no escalable" de la PaaS clásica. Las empresas a gran escala aún no podrán hacer lo que quieren con sus propias demandas de "PaaS" basadas en la pila de tecnología nativa de la nube "DIY".
De hecho, para más y más creadores de plataformas, a medida que las tecnologías nativas de la nube se implementan cada vez más, el "poder de interpretación" de "PaaS" ya no pertenece a un determinado proveedor, y más depende de la capacidad del creador de la plataforma. Escenarios comerciales y necesidades reales de sus usuarios finales. Además, para "SaaS", el sistema de entrega y empaquetado de software en contenedores y la base de Kubernetes que ofrece la nube nativa también han cambiado en gran medida la forma de distribución, operación y mantenimiento del software en la nube. Por lo tanto, ya sea PaaS o SaaS, la ola de tecnología "nativa de la nube" lo está "aplanando" rápidamente. En este contexto, el método tradicional "horizontal" de dividir el sistema de computación en la nube se ha convertido en Es difícil ser coherente con uno mismo . Un ejemplo típico es: hoy no puede llamar a Kubernetes PaaS ni a IaaS. Es una capa de acceso de capacidad de infraestructura única y una abstracción de capa de plataforma. Como creador de plataformas, puede construir cualquier plataforma de capa superior en su mente basándose en ella, y llama a esta plataforma de capa superior PaaS / Serverless / FaaS, o incluso Es SaaS, pero el grado de abstracción adicional es diferente y la capacidad vertical de la que depende es diferente: no existe tal división como "quién está abrumado por quién".
El auge del sistema de construcción de plataformas nativas en la nube de próxima generación
El éxito de Kubernetes ha permitido en gran medida al "creador de plataformas", un papel importante que la gente ha olvidado en el centro de costes empresarial (Centro de costes). De hecho, la razón por la que Kubernetes puede reemplazar al ecosistema Docker como protagonista en la plataforma de computación en la nube actual es en gran parte porque este grupo tomó la decisión final. De lo contrario, de acuerdo con la escala del grupo de usuarios alcanzado por Docker y su aceptación en el ecosistema de desarrolladores, Kubernetes casi no tiene posibilidades de ganar. Esto a menudo es pasado por alto por todos. De hecho, en el proceso de aterrizaje de una plataforma de nivel empresarial, aunque los usuarios finales de la plataforma (como I + D empresarial y operación y mantenimiento) son "clientes y dioses", realmente pueden desempeñar un papel clave y tener la decisión final en este proceso. A menudo es el equipo de la plataforma y los jefes detrás del negocio.
Pero al mismo tiempo, la ecología de la construcción de plataformas en Kubernetes todavía está muy concentrada en la actualidad. Una observación típica es que los equipos que pueden construir una plataforma de nivel superior completa basada en Kubernetes en la actualidad están concentrados en empresas de Internet de primer y segundo nivel a gran escala, y sus prácticas suelen ser "solo para referencia" y rara vez son reproducibles. Además, la gran popularidad de la nube nativa no parece permitir a los creadores de plataformas construir fácilmente PaaS u otras plataformas de capa superior. En realidad, esto explica aún más el estancamiento de la "ecología PaaS" que hemos observado anteriormente en la era nativa de la nube: la construcción de plataformas de capa superior (incluida PaaS) basadas en Kubernetes seguirá siendo la patente de grandes empresas y equipos de alta tecnología en 2020.
La alta concentración de esta ecología de construcción de plataformas es obviamente inconsistente con el futuro "inclusivo" que Cloud Native espera construir. Por supuesto, dado que el desarrollo tecnológico no se ha mantenido al día con la visión, la comunidad nativa de la nube no se detendrá.
De hecho, la motivación fundamental para que los creadores de plataformas desarrollen aún más plataformas de capa superior basadas en Kubernetes proviene de dos demandas:
- Mayor dimensión de abstracción : por ejemplo, los conceptos que los usuarios quieren operar son "aplicación" y "lanzamiento gris" en lugar de "contenedor" y "Pod".
- Más escalabilidad : por ejemplo, la estrategia de versión gris de la aplicación que los usuarios desean se basa en la versión canary "implementación dual + Istio", en lugar de la actualización continua lineal predeterminada de Kubernetes. Estas mejoras o extensiones generalmente se implementan en forma de complementos de CRD + Controller en Kubernetes.
Por lo tanto, la construcción de una plataforma de capa superior basada en Kubernetes parece ser desordenada e irregular hoy en día, pero en esencia, no dejará las dos demandas centrales de "abstracción + administración de capacidad de complementos". Para dar otro ejemplo, los diversos paneles que crea para Kubernetes hoy en día son en realidad una implementación "abstracta": estos paneles esencialmente exponen un conjunto de campos que permiten a los usuarios completar sobre la base de los objetos API de Kubernetes. Se logra el objetivo de "simplificar la mente del usuario y mejorar la experiencia del usuario"; este es, por supuesto, el objetivo fundamental de toda "abstracción".
Sobre la base de la práctica continua y el pensamiento de las dos demandas de "abstracción + gestión de capacidad de plug-in", la comunidad nativa de la nube ha nacido en 2020 un proyecto de código abierto como KubeVela que se centra en permitir que los equipos de plataformas creen plataformas de nivel superior. El posicionamiento de este proyecto es único en todo el ecosistema nativo de la nube: no es una determinada capacidad vertical, sino más bien un conjunto de "herramientas" basadas en Kubernetes para construir una plataforma de nivel superior, como:
- El mecanismo de abstracción basado en plantillas y el proceso automatizado de uso de documentos y el esquema OpenAPI basado en esta capacidad de generación (para ayudar al equipo de la plataforma a construir rápidamente Dashboard o Appfile).
- El mecanismo de registro, administración y descubrimiento de la capacidad del complemento basado en el modelo OAM se utiliza para modular y automatizar la administración de las capacidades del complemento, e incluso advertir de antemano sobre los conflictos entre las capacidades del complemento.
Casualmente, poco después de que Alibaba Cloud abriera el proyecto KubeVela, el líder en computación en la nube AWS también anunció el nacimiento oficial de los productos comerciales AWS Proton en Re: Invent 2020. La idea es muy similar al proyecto KubeVela, excepto que se reemplaza la base de la plataforma. La plataforma en la nube de AWS se utiliza para definir plantillas abstractas utilizando la propia formación en la nube de AWS (actualmente, KubeVela es compatible con el lenguaje de plantilla CUELang de código abierto de Google).
Es previsible que después de que los proyectos nativos de la nube y Kubernetes hayan unificado y estandarizado en gran medida la abstracción de la capa de infraestructura, cómo ayudar aún más al equipo de la plataforma a construir la plataforma de la capa superior de manera rápida, fácil y reproducible sobre esto, se está convirtiendo en el comienzo de la industria para pensar activamente en ello. Un camino crítico. Una vez más, es difícil para usted encontrar una posición adecuada para estos productos en la tradicional "arquitectura de tres niveles" de la computación en la nube. Ya sea KubeVela o AWS Proton, no son PaaS ni IaaS, ni son competidores de Kubernetes: son El brote del aumento gradual de una nueva generación de sistemas de construcción de plataformas en el contexto de la nube nativa.
Explore la próxima parada en la nube nativa
Se puede decir que el nativo de la nube en 2020 es el hilo principal de más rápido crecimiento en todo el ecosistema de computación en la nube, y es con este tipo de impulso de desarrollo que el nativo de la nube ya está pensando en su próximo desarrollo en el nuevo año. espacio. De hecho, hemos podido ver a varios fabricantes y equipos trabajando y explorando activamente en diferentes campos.
1. Desarrollo y pruebas locales
Permitir que los desarrolladores lleven a cabo pruebas y desarrollos locales para Kubernetes comienza a convertirse en un tema de preocupación En este campo, el proyecto Tilt de Nueva York es uno de los líderes. Alibaba Cloud y Tencent Cloud también tienen diferentes soluciones dimensionales sobre este tema, como KT Connet y Nocalhost .
2. La revolución tecnológica del "middleware" nativo de la nube
El modelo del coche lateral está hundiendo las capacidades del campo de middleware en Kubernetes, una nueva generación de infraestructura de aplicaciones con un impulso más rápida. Además de los que ya están en plena marcha subversión del campo de la gobernabilidad del tráfico de Istio, Microsoft tiene para no quedarse atrás y de código abierto abierto Servicio de malla como un código abierto Respuesta. Al mismo tiempo, Dapr , el proyecto hermano de OAM en Microsoft, alinea directamente la distancia entre Kubernetes y el middleware en el lado del "descubrimiento y enlace de servicios". Dubbo, un proyecto establecido, también anunció un plan técnico para la próxima generación de middleware nativo en la nube . Por supuesto, la motivación del usuario detrás de todo esto es muy clara: el middleware en la era nativa de la nube debería ser independiente del lenguaje y de la plataforma.
3. "Edge" y la versión de Kubernetes
La tendencia de "Androidización" de Kubernetes es indispensable para la "ambición" de implementar Kubernetes en cualquier centro de datos del mundo, que por supuesto también incluye dispositivos "periféricos". Además del producto insignia de Huawei, KubeEdge, el proyecto OpenYurt de Alibaba Cloud también ingresó a la incubación de la caja de arena de CNCF en 2020, y Tencent Cloud propuso SuperEdge para seguir. Al mismo tiempo, AWS abrió fuertemente el lanzamiento de Kubernetes EKS-D detrás de su servicio EKS en 2020, lo que, por supuesto, implica una fuerte respuesta al diseño Anthos de Google Cloud y Arc de Microsoft Cloud. Es previsible que la obsesión de los proveedores de nube por "implementar Kubernetes en cualquier rincón" hará que Kubernetes "Android" sea más rápido de lo imaginado, e inevitablemente será una "tormenta sospechosa" por parte de los ISV y los integradores de servicios. .
4. Gestión de aplicaciones nativas en la nube y GitOps
La administración y entrega de aplicaciones nativas en la nube ya se ha convertido en un enfoque de valor importante en Kubernetes, el "nuevo Android". En este campo, ha surgido la combinación OAM + OpenKruise de Alibaba Cloud y Microsoft. Al mismo tiempo, KubeVela también ha surgido en la comunidad como un marco de código abierto que permite aún más a los creadores de plataformas. Hashicorp, líder en el campo de las herramientas de desarrollo, no perderá la oportunidad. Lanzó una herramienta de interfaz de desarrollador multiplataforma como Waypoint. Con la rápida evolución de la tecnología de capa de aplicación en Kubernetes, el concepto de entregar aplicaciones basadas en Git como un centro de administración de configuración de aplicaciones (es decir, GitOps) está reemplazando rápidamente el enlace de CD en CI / CD tradicional y se está convirtiendo en una distribución de aplicaciones en Kubernetes. La mejor decision. A fines de 2020, el equipo de campo de entrega de aplicaciones de CNCF anunció oficialmente la formación del Grupo de Trabajo de GitOps, que probablemente empujará gradualmente a GitOps al estándar de facto para CD nativos de la nube. Hoy, cuando la "Androidización" de Kubernetes es imparable, estamos llenos de expectativas de más interrupciones e innovaciones en este campo en el nuevo año.
2020: nativo de la nube sin "definición exacta"
¿Qué es exactamente "nativo de la nube"? ¿Son contenedores y Kubernetes? ¿Las máquinas virtuales son nativas de la nube? ...
Estas "torturas del alma" siempre han sido la confusión planteada por muchas empresas y equipos que se exponen por primera vez al concepto de nativos de la nube. De hecho, como un conjunto de mejores prácticas y metodología para "usar la tecnología de computación en la nube para reducir costos y aumentar la eficiencia para los usuarios", el término nativo en la nube ha estado en una constante desde su nacimiento, su crecimiento y su enorme popularidad en la actualidad. En proceso de evolución e innovación. Esta vitalidad continua "nunca definida" es la fuente de la atracción de los "nativos de la nube" para la ecología de la computación en nube.
En 2020, la exploración y experimentación activa de toda la comunidad nativa de la nube en diferentes campos está reemplazando los proyectos de implementación maduros como Kubernetes y Service Mesh, convirtiéndose gradualmente en el tema único de la ecología nativa de la nube. Esto no es difícil de entender. El desarrollo de la nube nativa hasta el día de hoy se está acercando cada vez más a su imaginario "el software nace naturalmente en la nube y crece en la nube", pero también expone demasiado el chasis de tecnología nativa de la nube existente. Para la abstracción y administración de la infraestructura, ignora la experiencia del usuario final y muchos problemas causados por la tecnología. Estos problemas deben depender del pensamiento continuo, la precipitación y la reinvención de toda la comunidad nativa de la nube para complementarlos y corregirlos, de modo que el valor de la tecnología nativa de la nube pueda "flotar" gradualmente y generar valor directo y sentido del cuerpo para los usuarios finales; y también hacer que la nube sea nativa La "democratización" gradual de la tecnología hace que la construcción de una plataforma nativa de la nube simple y fácil de usar ya no sea exclusiva de las grandes empresas para "mostrar sus músculos".
Portal de proyectos de código abierto relacionado:
Sobre el Autor
Zhang Lei, experto técnico sénior de Alibaba Cloud, copresidente de entrega de aplicaciones de CNCF SIG, embajador oficial de CNCF