Resumen: Ambient Mesh aparece en una forma que está más en línea con los requisitos de implementación a gran escala y supera los defectos inherentes de la mayoría de los modelos de sidecar, de modo que los usuarios ya no necesitan percibir los componentes relacionados con la red y realmente hundir la red. en infraestructura.
Este artículo lo comparte Huawei Cloud Community " Huawei Cloud Cloud Native Team: Istio Data Plane New Model Ambient Mesh Technology Analysis ", autor: El futuro de los contenedores en la nube.
Si se dice qué patrón de diseño es el más clásico en el mundo nativo de la nube construido sobre la base de Kubernetes, el patrón Sidecar es sin duda el competidor más poderoso entre ellos. Cuando es necesario dotar a una aplicación de funciones auxiliares que no tienen nada que ver con su propia lógica, el sidecar que inyecta las funciones correspondientes en el Pod de la aplicación es obviamente la forma más nativa de Kubernetes, e Istio es el representante de este modo.
La visión del proyecto Istio es resolver los problemas de conexión, seguridad y observabilidad entre servicios en el escenario de microservicios de la forma más transparente posible. El principal método de implementación es implementar un Proxy junto a la aplicación y, en el escenario de Kubernetes, inyectar Sidecar en el Pod de la aplicación para interceptar el tráfico de la aplicación al Sidecar. Sidecar procesa el tráfico de la aplicación en función de la configuración del usuario obtenida del plano de control de Istio e implementa la gestión del servicio de una manera que es casi no invasiva para el código de la aplicación.
Aunque Istio no se limita a admitir únicamente la plataforma Kubernetes, el concepto de diseño de Istio tiene una afinidad natural con el modelo sidecar de Kubernetes. Basado en el modelo Sidecar, Istio puede realizar un rápido desarrollo, implementación y verificación en la plataforma Kubernetes. Al mismo tiempo, en el nivel funcional, Isito elimina la función de gobernanza del servicio del código de la aplicación y la transfiere a Sidecar como una infraestructura, abstrayendo la capa de red de la aplicación nativa de la nube real, lo que reduce en gran medida la carga mental de los desarrolladores de aplicaciones. es exactamente lo que le faltaba al ecosistema de Kubernetes. Basado en el complemento perfecto de Istio para el ecosistema de Kubernetes, con la popularización a gran escala de Kubernetes, Istio también logró apoderarse rápidamente de las mentes y los mercados de los usuarios.
Aunque implementar el plano de datos de Istio en el modo Sidecar parece ser una opción natural que la gente no puede rechazar, se debe enfatizar que la implementación de las funciones completas de Istio no está fuertemente ligada al modo Sidecar, y tenemos varias otras opciones. Elección. Además, a medida que el uso de Istio continúa profundizándose y la escala de implementación continúa ampliándose, se puede encontrar que existen muchos desafíos en la implementación de datos de Istio en modo Sidecar:
1. Intrusión: Istio básicamente logra una intrusión cero en el código de la aplicación, pero debido a que la inyección de Sidecar necesita cambiar las especificaciones del Pod y redirigir el tráfico de la aplicación, el Pod debe reiniciarse cuando la aplicación accede a la cuadrícula, y el contenedor de la aplicación y el contenedor Sidecar Los conflictos causados por la secuencia de inicio incierta de , también pueden provocar que la aplicación se interrumpa;
2. Vinculación del ciclo de vida: Sidecar es esencialmente una infraestructura, y su ciclo de vida a menudo es inconsistente con el de la aplicación. Por lo tanto, al actualizar Sidecar, también es necesario reiniciar el Pod de la aplicación, lo que también puede causar la interrupción de la aplicación. Para aplicaciones de trabajo , la existencia de Sidecar hará que el Pod no se limpie a tiempo;
3. Baja utilización de recursos: Sidecar es exclusivo de un solo pod de aplicación y el tráfico de la aplicación tiene picos y valles. En general, el uso de memoria de Sidecar está fuertemente relacionado con el tamaño del clúster (cantidad de servicios, cantidad de pods), por lo que los recursos deben reservarse en casos extremos, lo que lleva a una baja utilización de recursos del clúster en su conjunto. Al mismo tiempo, dado que es necesario inyectar Sidecar en cada Pod, a medida que la escala del clúster continúa expandiéndose, la cantidad total de recursos ocupados por Sidecar también aumentará linealmente.
Para abordar las deficiencias del modelo de implementación de Sidecar, Google y Solo.io lanzaron conjuntamente un nuevo modelo de implementación sin Sidecar: Ambient Mesh.
Introducción a la arquitectura
La arquitectura Ambient Mesh que se muestra en la figura anterior, desde el punto de vista del diseño, tiene principalmente las siguientes dos características:
1. Sin Sidecar: para evitar los defectos del modelo de Sidecar mencionado anteriormente, Ambient Mesh ya no inyecta Sidecar en ningún Pod y hunde aún más la implementación de la función de malla en los propios componentes de Istio.
2. Capas de procesamiento L4/L7: Ambient Mesh presenta dos componentes, ztunnel y waypoint, para reemplazar el Sidecar original para implementar funciones relacionadas. el procesamiento del tráfico L4, mientras que el tráfico L7 se entrega a los waypoints para su procesamiento según sea necesario.
En comparación con Istio en el modo Sidecar original, el plano de control de Ambient Mesh básicamente no ha cambiado. La composición de componentes del plano de datos y las funciones de cada componente son las siguientes:
1. istio-cni: Componente necesario, desplegado en forma de DaemonSet. De hecho, istio-cni no es un componente nuevo de Ambient Mesh. Ya existía en el modo sidecar original. En ese momento, se usaba principalmente para reemplazar a istio-init, el Contenedor de inicio, para configurar reglas de intercepción de tráfico y para evitar problemas de seguridad causados por istio-init. Ambient Mesh lo expande y lo implementa como componente obligatorio, es responsable de configurar las reglas de reenvío de tráfico, secuestrando el tráfico de aplicaciones de los Pods que se han unido a Ambient Mesh en este nodo y reenviándolo al ztunnel de este nodo;
2. ztunnel: Componente requerido, implementado en forma de DaemonSet. ztunnel actúa como proxy del tráfico de Pods en el nodo donde se encuentra, y es el principal responsable del procesamiento del tráfico L4, la telemetría L4 y la gestión de mTLS (autenticación bidireccional) entre servicios. Originalmente, ztunnel se implementó en base a Envoy, pero teniendo en cuenta las restricciones intencionales en las funciones de ztunnel y los requisitos de seguridad y ocupación de recursos, la comunidad ha utilizado rust para construir este componente desde cero;
3. waypoint: configurado bajo demanda, desplegado en forma de Despliegue. waypoint es responsable de manejar HTTP, inyección de fallas y otras funciones L7. Implemente en la granularidad de carga o espacio de nombres. En Kubernetes, una cuenta de servicio o un espacio de nombres corresponde a una implementación de waypoint, que se utiliza para procesar el tráfico de capa 7 enviado a la carga correspondiente. Al mismo tiempo, la cantidad de instancias de waypoint puede ser escalado dinámicamente de acuerdo con el tráfico.
A continuación, se utiliza el proceso de procesamiento real del plano de datos de Ambient Mesh para mostrar las funciones específicas que desempeñan los componentes anteriores:
1. De manera similar al modo Sidecar, Ambient Mesh también puede agregar servicios a la cuadrícula en la granularidad de la cuadrícula, el espacio de nombres y el Pod; la diferencia es que no es necesario reiniciar el Pod recién agregado ni inyectar Sidecar ;
2. istio-cni monitorea la adición y eliminación de Pods en el nodo y la entrada y salida de la red, y ajusta dinámicamente las reglas de reenvío.El tráfico enviado por los Pods en la red se reenviará de forma transparente al ztunnel del nodo , omitiendo directamente el procesamiento de kube-proxy ;
3. ztunnel también necesita monitorear la adición y eliminación de Pods en el nodo local y la entrada y salida de la red, y obtener y administrar los certificados de los Pods ubicados en el nodo local y tomados por la red desde el plano de control ;
4. El ztunnel en el extremo de origen procesa el tráfico interceptado, encuentra el certificado correspondiente al Pod de acuerdo con la IP de origen del tráfico y establece mTLS con el extremo par;
5. Si el servicio de destino al que se va a acceder no está configurado con un waypoint o una política de procesamiento relacionada con L7, el ztunnel de origen establecerá directamente una conexión con el ztunnel de destino (como se indica con la línea amarilla en la figura anterior) y el par ztunnel terminará mTLS e implementará la política de seguridad L4 Reenviará el tráfico al pod de destino;
6. Si el servicio de destino está configurado con un punto de referencia (utilizando un objeto de puerta de enlace especialmente configurado) y una estrategia de procesamiento L7, el ztunnel de origen establecerá mTLS con el punto de referencia correspondiente. Después de que el punto de referencia finalice mTLS, realizará el procesamiento lógico L7 y luego comunicarse con el Pod de destino. El ztunnel del nodo donde se encuentra establece mTLS y, finalmente, el ztunnel del extremo de destino también finaliza mTLS y envía el tráfico al Pod de destino.
Análisis de valor
Aunque desde la perspectiva de la implementación subyacente, existe una gran diferencia entre Ambient Mesh y el modo Sidecar original, desde la perspectiva del usuario, los efectos de uso e implementación de la API central de Istio (VirtualService, DestinationRules, etc.) son consistente, lo que puede garantizar básicamente la misma experiencia de usuario. Ambient Mesh es el segundo modo de plano de datos admitido por la comunidad de Istio además del modo Sidecar, por lo que la tecnología de cuadrícula en sí puede aportar valor a los usuarios. Ambient Mesh no es diferente del modo Sidecar anterior. Por lo tanto, aquí solo se analiza el valor de Ambient Mesh en relación con el modo Sidecar nativo, y el valor de la cuadrícula en sí no se repetirá.
Ambient Mesh se ajusta principalmente a la arquitectura del plano de datos de Istio para superar las deficiencias del modelo Sidecar existente, por lo que su valor debe basarse en sus características arquitectónicas. Como se mencionó anteriormente, las características arquitectónicas de Ambient Mesh incluyen principalmente "sin sidecar" y "capas de procesamiento L4/L7". El análisis de valor se basa en estos dos puntos:
1. Las ventajas de Sidecar-less en realidad pueden verse como lo contrario de los defectos del modelo Sidecar:
- Transparencia: la función de cuadrícula se reduce a la infraestructura, que no solo tiene cero intrusiones en el código de la aplicación, sino que también desacopla completamente el ciclo de vida de la aplicación, de modo que es verdaderamente transparente para la aplicación y permite que la aplicación y la cuadrícula evolucionar independientemente;
- Optimice la ocupación de recursos: la CPU, la memoria y otros recursos ocupados por el plano de datos ya no aumentan linealmente con la cantidad de instancias. A medida que disminuye la cantidad de instancias en el plano de datos, la cantidad de conexiones al plano de control también disminuye en consecuencia, lo que en gran medida reduce los recursos y el procesamiento del plano de control.presion.
2. En cuanto a por qué se deben superponer L4/L7, en primer lugar, es necesario distinguir la diferencia entre los dos. En comparación con L4, el procesamiento de L7 es más complicado y requiere más recursos, como CPU/memoria, y también hay una gran diferencia en la ocupación de recursos entre diferentes tipos de operaciones; al mismo tiempo, cuanto más compleja es la operación, mayor la superficie de ataque expuesta. Además, Envoy actualmente no admite un fuerte aislamiento del tráfico de diferentes inquilinos, y el problema del "vecino ruidoso" es inevitable. Por lo tanto, las ventajas de la arquitectura de procesamiento en capas Ambient Mesh son las siguientes:
- Alta utilización de recursos: ztunnel solo es responsable del procesamiento L4, el procesamiento L4 es relativamente simple y la ocupación de recursos es relativamente fija, por lo que es más fácil planificar recursos para ztunnel, sin una reserva excesiva de recursos, y los usuarios pueden usar más recursos de nodo; waypoint también puede Expansión y contracción dinámicas de acuerdo con la carga L7, aprovechando al máximo los fragmentos de recursos en el clúster;
- Aislamiento de inquilinos: el procesamiento L7 con procesamiento complejo y altos riesgos de seguridad es manejado por los waypoints de cada inquilino (Cuenta de servicio), lo que no solo evita la preferencia de recursos entre los inquilinos, sino que también limita el radio de explosión de los problemas de seguridad;
- Aterrizaje suave: Permita que los usuarios accedan gradualmente a la red Cuando solo se necesita la capacidad de procesamiento L4 de la red, no es necesario considerar la ocupación de recursos de L7 y el posible impacto negativo que puede causar (por ejemplo: debido a incorrecta configuración, la aplicación ingresa al procesamiento L7 y cumple completamente con el protocolo L7, lo que resulta en la interrupción del servicio), y luego habilita las funciones relevantes a pedido en el momento apropiado.
Por supuesto, Ambient Mesh, como una nueva arquitectura de plano de datos de Istio, todavía existe como una característica experimental en la comunidad, y aún quedan muchos problemas por resolver, como:
1. Rendimiento: especialmente para el procesamiento L7, Ambient Mesh necesita pasar por dos ztunnels y un waypoint, y un salto adicional es visible a simple vista, por lo que el procesamiento L7 completo necesita pasar por tres saltos adicionales. Aunque la comunidad afirma que esto tiene poco impacto en el rendimiento, aún se necesitan más observaciones y comparaciones después de que se estabilicen sus características;
2. Adaptación de la red de contenedores: aunque Ambient Mesh y la aplicación están básicamente completamente desacoplados, también aumenta el acoplamiento entre la red y la infraestructura subyacente.El modo Sidecar solo necesita implementar la intercepción de tráfico en las redes del Pod, pero Ambient La malla intercepta el tráfico en la red host, obviamente, se debe prestar más atención a la adaptación a la red de contenedores subyacente;
3. Configuración compleja: la configuración compleja de Envoy ha sido ampliamente criticada, pero Ambient Mesh necesita implementar un ztunnel como proxy para todos los Pods en el nodo. La complejidad de la configuración ha aumentado en un orden de magnitud. Al mismo tiempo, la configuración compleja significa un aumento en el flujo de procesamiento También afectará la depuración del plano de datos y el rendimiento general;
4. Otros: ¿Alta disponibilidad de ztunnel? De hecho, waypoint cambia el procesamiento original de L7 de dos extremos a un solo extremo. ¿Cómo afecta esto a la corrección de los indicadores de seguimiento de L7? …
perspectiva del futuro
Desde el punto de vista del lanzamiento, desde su lanzamiento en septiembre de 2022, Ambient Mesh ha estado en una rama independiente como característica experimental. Por lo tanto, el próximo plan para Ambient Mesh es fusionarse con la rama principal (que se implementó en febrero de 2023) y lanzarlo como una función Alpha, y finalmente llegar a Stable a fines de 2023, dejándolo disponible para producción.
Desde la perspectiva de la API, lo ideal es compartir el mismo conjunto de API bajo las dos arquitecturas. Por supuesto, esto no es realista, porque algunas de las API de Istio existentes están diseñadas sobre la premisa de la implementación del modo sidecar. El más típico es el sidecar CRD, que se utiliza para personalizar la configuración entregada a diferentes sidecars, reduciendo así la ocupación innecesaria de recursos de los sidecars. Estas API de Sidecar-Only obviamente no tienen sentido bajo Ambient Mesh. Al mismo tiempo, Ambient Mesh presenta dos componentes únicos, ztunnel y waypoint, por lo que Ambient Mesh también necesita crear una nueva API para administrar estos componentes únicos e implementar algunas funciones de Ambient Mesh Only. Al final, Ambient Mesh implementará las API principales de Istio existentes (VirtualService, DestinationRules, etc.) y creará algunas API únicas. Es importante unificar los tres tipos de API (modo Sidecar único, Ambient Mesh único y ambos) e interacción.
Entonces, ¿Ambient Mesh ha cubierto completamente los escenarios de uso del modo Sidecar, de modo que el modo Sidecar se ha retirado por completo del escenario de la historia? La respuesta es naturalmente No. Similar a las disputas entre varios modelos exclusivos y compartidos en la industria, el modelo Sidecar es esencialmente el uso exclusivo de Proxy por parte de la aplicación Pod. Un Proxy dedicado a menudo puede garantizar una mejor disponibilidad de recursos, evitar el impacto de otras aplicaciones tanto como sea posible y garantizar el funcionamiento normal de las aplicaciones de alta prioridad. Es previsible que en la implementación mixta final de los dos modos, la aplicación seleccione el modo proxy a pedido que es una forma más ideal. Por lo tanto, la creación de un modo de implementación híbrido para garantizar una buena compatibilidad y una experiencia unificada entre los dos modos en este modo también será el centro del trabajo de seguimiento.
Resumir
El modo sidecar es como una verificación de prototipo para Istio. Demuestra rápidamente el valor de la tecnología grid de la manera más nativa de Kubernetes y aprovecha la conciencia del usuario y el mercado. Sin embargo, a medida que la implementación de Istio ingresa gradualmente al área de aguas profundas y comienza a implementarse a gran escala en el entorno de producción, el modelo Sidecar parece ser incapaz de hacer lo que quiere. En este momento, Ambient Mesh aparece en una forma que está más en línea con los requisitos de implementación a gran escala, superando los defectos inherentes de la mayoría de los modelos de sidecar, de modo que los usuarios ya no necesitan percibir los componentes relacionados con la red y realmente hundir el red en infraestructura.
Pero está claro que Ambient Mesh no es el final de la evolución de la arquitectura de superficie de datos de cuadrícula. En la actualidad, no existe una solución de superficie de datos de cuadrícula que pueda ser perfecta en términos de intrusividad, rendimiento y uso de recursos. Ambient Mesh básicamente logra cero intrusiones en la aplicación, pero los problemas de rendimiento causados por el procesamiento de tres saltos de L7 y la ocupación de recursos de los procesos residentes como ztunnel no se pueden ignorar; las bibliotecas RPC como gRPC implementan xDS a través de integrado, conectado directamente al plano de control de Istio, mezclar la red en el SDK puede lograr un buen rendimiento y un buen rendimiento de ocupación de recursos, pero es inevitable pagar el precio inherente de un fuerte acoplamiento con la aplicación y la alta complejidad del soporte multilingüe; basado en eBPF, el conjunto completo de funciones de la superficie de datos de la cuadrícula puede ser directamente hundir la pila de protocolos TCP/IP en el núcleo parece ser una solución final ideal, pero teniendo en cuenta la complejidad de la seguridad del núcleo y la interacción con el núcleo, el entorno de ejecución de eBPF es en realidad muy limitado Por ejemplo, los programas eBPF deben pasar por Para la verificación del verificador, la ruta de ejecución debe ser completamente conocida y no se pueden ejecutar bucles arbitrarios. Por lo tanto, para el procesamiento L7 complejo como HTTP/2 y gRPC, será difícil desarrollarlo y mantenerlo basado en eBPF.
Teniendo en cuenta los requisitos extremos de la infraestructura en cuanto a rendimiento y consumo de recursos y la evolución de las tecnologías relacionadas en el pasado, por ejemplo, para la red básica, la mayoría de las aplicaciones pueden compartir la pila de protocolos del núcleo y algunas aplicaciones especiales utilizan DPDK, RDMA y otras tecnologías dedicadas. acelerar. De manera similar, para la superficie de datos de cuadrícula, puede ser más factible combinar múltiples tecnologías para optimizar las soluciones para los escenarios correspondientes. Se puede prever que este tipo de solución básicamente toma el agente de nivel de nodo como Ambient Mesh como el cuerpo principal.Con el desarrollo de la tecnología grid y eBPF, tantas funciones del plano de datos grid como sea posible serán degradadas a eBPF (Fast Path) para la realización; menos Proxy (Slow Path) implementa algunas funciones avanzadas en modo de usuario; para aplicaciones que tienen altos requisitos de rendimiento y aislamiento, se implementan Sidecars dedicados para ellas. De esta forma, puede cumplir con los requisitos de varias dimensiones, como la intrusividad, el rendimiento y la ocupación de recursos en la mayoría de los escenarios.
En resumen, al final, un conjunto de soluciones de plano de datos dominará el mundo, o un despliegue mixto de varias soluciones, dependiendo de los directores de cada empresa, todavía es necesario seguir explorando y evolucionando tecnologías relacionadas, y luego use pruebas de práctica y, finalmente, deje que el tiempo nos diga la respuesta.
referencias
[1] Explicación de Istio Ambient Mesh: https://lp.solo.io/istio-ambient-mesh-explained
[2] Qué esperar de la malla ambiental en 2023: https://www.solo.io/blog/ambient-mesh-2023
[3] Presentamos Ambient Mesh: https://istio.io/latest/blog/2022/introducing-ambient-mesh
[4] Comience con Istio Ambient Mesh: https://istio.io/latest/blog/2022/get-started-ambient
Haga clic para seguir y conocer las nuevas tecnologías de Huawei Cloud por primera vez~