Recientemente, he estado trabajando en contenido PaaS y acabo de entrar en contacto con Kubernetes, que implica cobertura de red, es decir, comunicación entre contenedores cross-host. Así que han surgido una serie de componentes de código abierto, como franela, calicó, tejido, etc. Aquí están principalmente Calico y Fannel.
Principio de franela
Flannel, un proyecto desarrollado por CoreOS, es probablemente el plugin de CNI más directo y popular. Es uno de los ejemplos más maduros de arquitectura de red en sistemas de orquestación de contenedores y está diseñado para permitir una mejor red entre contenedores e interhosts. Con el auge del concepto CNI, el plugin Flannel CNI es una introducción temprana.
Flannel es relativamente fácil de instalar y configurar en comparación con otras opciones. Está empaquetado como un único binario FlannelD, y muchas herramientas comunes de despliegue de clústeres Kubernetes y muchas distribuciones Kubernetes pueden instalar Flannel por defecto. Flannel puede utilizar el clúster etcd existente del clúster Kubernetes para almacenar su información de estado usando la API, por lo que no requiere un almacén de datos dedicado.
Flannel configura una red superpuesta IPv4 de Capa 3. Crea una gran red interna que abarca cada nodo del clúster. En esta red superpuesta, cada nodo tiene una subred que se utiliza para asignar direcciones IP internamente. Al configurar un pod, la interfaz del puente Docker en cada nodo asigna una dirección a cada nuevo contenedor. Los pods en el mismo host pueden comunicarse usando puentes Docker, mientras que los pods en diferentes hosts usan flanneld para encapsular su tráfico en paquetes UDP y así poder ser enrutados al destino adecuado.
Flannel dispone de varios tipos diferentes de backends que pueden utilizarse para encapsulación y enrutamiento. El enfoque por defecto y recomendado es usar VXLAN porque VXLAN rinde mejor y requiere menos intervención manual.
Arquitectura de calicó
La calicó incluye los siguientes componentes importantes: Felix, etcd, cliente BGP y reflector de ruta BGP. A continuación se presentan las explicaciones de cada uno de estos componentes.
Felix: Principalmente responsable de la configuración de enrutamiento, la configuración de las reglas ACLS y la entrega, que existe en cada nodo.
etcd: El almacén clave-valor distribuido, principalmente responsable de la consistencia de los metadatos de la red, asegurando la precisión del estado de la red Calico, puede compartirse con Kubernetes;
BGPClient (BIRD) es principalmente responsable de distribuir la información de enrutamiento escrita por Felix al kernel de la red actual de Calico para garantizar la eficacia de la comunicación entre cargas de trabajo.
El Reflector BGPRoute (BIRD) se utiliza en despliegues a gran escala, abandonando el modo mallado de interconexión de todos los nodos y utilizando uno o más Reflectores BGPRoute para completar el enrutamiento y distribución centralizados.
El principio de la calicó
Como se muestra en el siguiente diagrama, el proceso se representa desde el contenedor de origen pasando por el host de origen, pasando por el enrutamiento del centro de datos, y finalmente al host de destino y finalmente asignado al contenedor de destino.
Contraste
A partir del principio anterior, se puede ver que Flannel realiza operaciones de desempaquetado de paquetes basándose en el reenvío de enrutamiento, lo que desperdicia recursos de computación de la CPU. El gráfico siguiente compara el rendimiento de varios componentes de red de código abierto encontrados en línea. Se puede observar que, en términos de ancho de banda y latencia de red, el rendimiento de Calico y del host es similar.
|
Publicado en 9/11/2020 11:23:01
|
|
|
|
