Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Contrail varios pod de interfaz

 

Normalmente, cada conjunto Pod del clúster Kubernetes tiene una sola interfaz de red (excepto la interfaz de bucle de retorno). En realidad, hay escenarios en los que se requieren varias interfaces. Por ejemplo, una VNF (función de red virtualizada) normalmente necesita una interfaz de administración para completar las funciones de red, a la izquierda, derecha y opcionalmente. Una caja Pod puede necesitar una interfaz de datos para llevar el tráfico de datos y una interfaz de administración para la detección de la disponibilidad. Los proveedores de servicios también tienden a mantener las redes de administración y de inquilino con independencia de la aislamiento y la administración. Varias interfaces proporcionan una manera de que los contenedores se conecten simultáneamente a varios dispositivos en varias redes.

Contrail como CNI

En la tecnología contenedora, un par Veth (virtual Ethernet) funciona de manera muy similar a un cable virtual que se puede usar para crear túneles entre espacios de nombres de red. Un extremo de él está enchufado en el contenedor y el otro extremo se encuentra en el espacio de nombres de puente de host o de Docker.

Un complemento de Contrail CNI es responsable de insertar la interfaz de red (es un extremo del par Veth) en el espacio de nombres de la red contenedora, y también realizará todos los cambios necesarios en el host, como conectar el otro extremo de la Veth a un puente, asignar IP, configurar rutas, etc.

Existen muchas implementaciones del complemento de CNI que están disponibles públicamente en la actualidad. Contrail es uno de ellos y es nuestro favorito. Para obtener una comprobación de lista completa https://github.com/containernetworking/CNI.

Figure 1: El contenedor y el par Veth
El contenedor y el par Veth

Otro complemento CNI, mult-CNI, le permite conectar varias interfaces de red a pods. La compatibilidad con varias redes de mult-CNI se realiza mediante la llamada múltiple a otros complementos de CNI. Dado que cada complemento creará su propia red, varios complementos permiten que el conjunto de redes cuente con varias. Una de las principales ventajas que ofrece Contrail, en comparación con mutus-CNI y todas las demás implementaciones actuales en la industria, es que Contrail proporciona la capacidad de conectar varias interfaces de red a un conjunto Pod Kubernetes por sí mismo, sin tener que llamar a ningún otro complemento. Esto ofrece compatibilidad con un conjunto pod de alojamiento múltiple.

Definición de datos adjuntos de red CRD

Contrail CNI sigue la definición de adjuntos de red Kubernetes CRD (definición de recursos personalizada) para proporcionar un método estándar para especificar las configuraciones para las interfaces de red adicionales. No hay ningún cambio en las API de Kubernetes upstream estándar, lo que hace que la implementación sea más incompatibilidades.

En Contrail, contrail-Kube-Manager crea la definición de adjunto de red (KM). Cuando se inicia, KM valida si se encuentra un network-attachment-definitions.k8s.cni.cncf.io de red CRD en el servidor de API Kubernetes y crea uno si no es’así.

A continuación se muestra un archivo de YAML de objeto CRD:

En el programa de instalación de Contrail Kubernetes, se ha creado el CRD y se puede comprobar:

Usando este nuevo tipo de definición de red-adjunto creada a partir del CRD anterior, ahora tenemos la capacidad de crear una red virtual en Contrail entornos Kubernetes.

Para crear una red virtual a partir de Kubernetes, utilice una plantilla YAML como la siguiente:

Al igual que otros muchos objetos Kubernetes estándar, se especifica el nombre de la red virtual, el espacio de nombres en metadatos y las anotaciones que se utilizan para transportar información adicional sobre una red. En Contrail, las anotaciones siguientes se usan en el CRD NetworkAttachmentDefinition para habilitar ciertos atributos para la red virtual:

  • opencontrail.org/cidr: Este CIDR define la subred de una red virtual.

  • opencontrail.org/ip_fabric_forwarding: Este marcador es activar/desactivar la característica de enrutamiento de la estructura IP.

  • opencontrail.org/ip_fabric_snat: Este es un indicador para activar/desactivar la característica IP fabric SNAT.

En Contrail, la característica de reenvío de la estructura de IP permite el reenvío basado en estructuras IP sin túnel para la red virtual. Cuando dos ip_fabric_forwrding habilitado las redes virtuales se comunican entre sí, el tráfico de superposición se reenviará directamente mediante el subyacente.

Con la característica Contrail IP-fabric-SNAT, los pods que se encuentran en la capa superpuestas pueden llegar a Internet sin un enrutador IPs flotante o lógico. La característica IP-fabric-SNAT utiliza Compute node IP para crear un TDR de código fuente con el fin de alcanzar los servicios necesarios.

Tenga en cuenta que en este libro no se abordan las características de reenvío de la estructura IP y de la estructura SNAT de IP.

O bien, puede definir una nueva red virtual haciendo referencia a una red virtual existente:

En este libro, usamos la primera plantilla para definir nuestras redes virtuales en todos los ejemplos.

Pod de interfaz múltiple

Con varias redes virtuales creadas, puede conectar (también puede decir Plug o Insert) cualquiera de ellas en una caja Pod, con el archivo Pod’s YAML, como se indica a continuación:

O bien, otro formato válido:

Probablemente’se haya dado cuenta de que pods en un espacio de nombres no solo puede hacer referencia a las redes definidas en el espacio de nombres local, sino también a las redes creadas en otros espacios de nombres con su nombre totalmente en el ámbito. Esto es muy útil. La misma red no tiene que duplicarse nuevamente y de nuevo en todos los espacios de nombres que la necesiten. Puede definirse una vez y, a continuación, remitirse a otros lugares.

Hemos’pasado por las teorías básicas y he explorado las distintas plantillas, así que’deje un ejemplo de trabajo en el mundo real. Comencemos’creando dos redes virtuales, examinando los objetos de la red virtual y, a continuación, crean un conjunto Pod y adjuntamos las dos redes virtuales a la misma. ’Concluyemos examinando las interfaces del conjunto Pod y la conectividad con otros pods que comparten las mismas redes virtuales.

Este es el archivo YAML de las dos redes virtuales (VN-Left-1 y vn-Right-1):

Ahora cree ambas redes virtuales:

Examine las redes virtuales:

Las redes virtuales se crean de la manera esperada. Nada bastante emocionante, pero si inicia sesión en la Contrail IU, verá algo inesperado en la siguiente captura de pantalla, en la Figure 2.

Figure 2: Comando de Contrail: Redes virtuales > del menú principal
Comando de Contrail: Redes virtuales > del menú principal
Note

Asegúrese de seleccionar el proyecto correcto, en este caso es K8S-predeterminado.

Y lo que’se encuentre se encuentra en la falta de cualquier red virtual con el nombre exacto de VN-Left-1 o vn-Right-1 en la UI. En su lugar, dos redes virtuales, denominadas K8S-vn-Left-1-Pod-Network y K8S-vn-Right-1-Pod-Network.

Aquí no hay ningún problema. Lo que sucedió es siempre que se cree una red virtual desde Kubernetes, Contrail agregue automáticamente el nombre del clúster Kubernetes (de forma predeterminada K8S) como prefijo al nombre de la red virtual que se da en su YAML archivo de red y un sufijo-Pod-red al final. Esto tiene sentido porque sabemos que se puede crear una red virtual con distintos métodos y con estas palabras clave adicionales incrustadas en el nombre’, es más fácil indicar cómo se creó la red virtual (desde Kubernetes o manualmente desde la interfaz de usuario) y para qué se usará. Asimismo, los posibles conflictos de nombres de redes virtuales pueden evitarse cuando se trabaja en varios clústeres de Kubernetes.

A continuación se muestra un archivo YAML de un POD con varias redes virtuales:

En las anotaciones del conjunto Pod en metadatos, inserte dos redes virtuales: VN-izquierda-1 y vn-derecha-1. Ahora, ¿adivinar cuántas interfaces tendrá la caja Pod en el arranque? Es posible que piense dos porque eso es lo que especificamos en el archivo. Pongamos’a crear la caja Pod y compruébelo:

En anotaciones, en k8s.v1.cni.cncf.io/network-status, puede ver una lista […], que tiene tres elementos, cada uno representado por una llave {} de asignaciones de clave-valor. Cada llave incluye información sobre una interfaz: la dirección IP asignada, el equipo MAC y la red virtual a la que pertenece. Por lo tanto, terminará por tener tres interfaces creadas en la caja Pod en lugar de dos.

Observe el segundo elemento que indica la dirección IP 10.47.255.238. Se trata de la interfaz conectada a la red Pod predeterminada denominada Cluster-Global-default, que es creada por el sistema. Puede examinar la red Pod predeterminada como una red de administración porque siempre está activa y en ejecución en todos los espacios’de nombres de red Pod s. Funcionalmente,’no difiere mucho de la red virtual que creó, salvo que no puede’eliminarla.

Deje’que se conecte a la caja Pod, enumere las interfaces y verifique las direcciones IP y Mac:

Puede ver una interfaz de lo y tres interfaces conectadas por Contrail CNI, cada una con la IP asignada desde la red virtual correspondiente. Observe también que las direcciones MAC coinciden’con lo que se ve en la kubectl describir la salida del comando.

Note

El hecho de tener el dirección MAC en las anotaciones puede ser útil en determinados casos. Por ejemplo, en la sección encadenamiento de servicio, encontrará una situación en la que tendrá que usar el dirección MAC para localizar la interfaz adecuada, de manera que pueda asignar el podIP adecuado que Kubernetes asignado desde una red virtual. Siga leyendo para obtener más detalles.

Puede’ver de nuevo el conjunto pod de varias interfaces en el ejemplo donde el conjunto Pod se basará en una Juniper cSRX imagen en lugar de una imagen de acoplador general. La idea básica sigue siendo la misma.