Flujo de tráfico de Contrail de entrada

Las solicitudes de los clientes, como un tipo de tráfico superpuesto, pueden proceder de dos orígenes diferentes, dependiendo de quién inicia la solicitud:

• Una solicitud interna: solicitudes procedentes de otro Pod dentro del clúster.

• Una solicitud externa: las solicitudes proceden de un host de Internet fuera del clúster.

La única diferencia entre ambos es cómo el tráfico alcanza el HAProxy activo. A una entrada se le asignarán dos direcciones IP: una dirección IP virtual interna del clúster y una dirección IP virtual externa.

1. Para las solicitudes internas, se llega directamente a’la dirección VIP interna de la entrada.
2. En el caso de solicitudes externas, por primera vez’alcanza la dirección – VIP externa de entrada la dirección IP flotante, que es la que se’expone a external, y que s cuando’TDR comienza a reproducirse como se explicó en la sección FIP. Después de TDR procesamiento, el tráfico se reenvía a la dirección VIP interna de entrada.
3. A partir de este momento, ambos tipos de solicitudes se procesan exactamente de la misma manera.
4. Las solicitudes se enviarán a través de proxy a la dirección IP de servicio correspondiente.
5. Según la disponibilidad de los pods backend, se lo enviará al nodo donde se encuentra uno de los pods de back-end y finalmente llega a los pods de destino.
6. En caso de que los pods de back-end se ejecutan en un nodo de computación distinto al que ejecuta Active HAProxy, se crea un MPLS a través de un túnel UDP entre los dos nodos computacionales.

La Figure 1 y la Figure 2 ilustran el flujo de solicitudes de servicio de extremo a extremo cuando se tiene acceso a desde un conjunto Pod en el clúster y durante el acceso desde un host de Internet.

Contrail admite los tres tipos de entrada:

• Ingress basadas en HTTP de servicio único

• entrada de fanout sencilla

• alojamiento virtual basado en nombres

ingresos a continuación,’analizaremos cada tipo de entrada

Figure 1: Flujo de tráfico de entrada: Acceso desde interno

Figure 2: Flujo de tráfico de entrada: Acceso desde externo

Configuración de la entrada

Este manual’s Lab usa el mismo testbed que se utiliza para la prueba de servicio, como se muestra en la Figure 3.

Figure 3: Testbed de entrada

Ingreso de servicio único

La entrada de servicio único es la forma más básica de entrada. No define ninguna regla y su uso principal es exponer el servicio al mundo exterior. Proxy de todas las solicitudes entrantes de servicio al mismo servicio de un único back-end:

Para mostrar el tipo de servicio único de entrada, los objetos que necesitamos crear son:

• un objeto Ingress que define el servicio back-end

• un objeto de servicio back-end

• al menos un conjunto POD para el servicio

Definición de la entrada

En el laboratorio de pruebas de Ingress Single Service, queremos solicitar que cualquier dirección URL se dirija a Service-web clusterip con servicePort 8888. Este es el archivo de definición de YAML correspondiente:

Esto no parece tan bonito. Básicamente, no hay nada más que una referencia a un único servicio WebServer-1 como back-end. Todas las solicitudes HTTP se distribuirán a este servicio y, a partir de ahí, la solicitud llegará a un pod back-end. Bastante simple. Echemos’un vistazo al servicio back-end.

Definición del servicio back-end

Puede utilizar el mismo servicio exacto que se introdujo en el ejemplo de servicio:

Definición de pod de back-end

Al igual que en el ejemplo de servicio, puede usar exactamente la misma implementación WebServer para iniciar los pods de back-end:

Todo en un archivo YAML

Como es habitual, puede crear un archivo YAML individual para cada uno de los objetos, pero tenga en cuenta que estos objetos siempre deben crearse y retirarse juntos en la’entrada, es mejor combinar las definiciones de todos estos objetos en un solo archivo YAML. La sintaxis YAML lo admite utilizando delimitadores de documento (una línea de---entre cada definición de objeto):

• Puede crear/actualizar todos los objetos del archivo YAML en un solo uso, utilizando un comando kubectl Apply.

• De forma similar, si algo va mal y necesita limpiar, puede eliminar todos los objetos creados con el archivo YAML en un kubectl comando DELETE.

• Siempre que sea necesario, puede eliminar cada objeto individual de forma independiente, proporcionando el nombre del objeto.

Implementar los ingresos del único servicio

Antes de aplicar el archivo YAML para obtener todos los objetos creados,’echemos un vistazo rápido a nuestros dos nodos. Desea ver si hay algún proceso HAProxy en ejecución sin la entrada, por lo que posteriormente, después de implementar la entrada, puede comparar lo siguiente:

Por lo tanto, la respuesta es no, no hay ningún proceso HAProxy en ninguno de los nodos. HAProxy solo se creará después de crear la entrada y el monitor de servicio contrail verá el objeto de equilibrador de carga correspondiente. A’continuación, comprobamos esto de nuevo después de crear una entrada:

Ahora se han creado la entrada, un servicio y un objeto de implementación.

Objeto de entrada

Deje’que los s examinen el objeto de entrada:

Como era de esperar, el servicio back-end se aplica correctamente a la entrada. En este ingreso de un solo servicio no hay reglas explícitas definidas para asignar una dirección URL específica a un servicio – diferente todas las solicitudes HTTP se distribuirán al mismo servicio back-end.

• 10.47.255. x es un podIP interno del clúster asignado desde la subred’predeterminada Pod s y

• 101.101.101. x es el FIP público asociado con una dirección IP interna. La pregunta es: ¿Por qué la entrada requiere un podIP y un FIP?

Deje’que la respuesta se mantenga en este momento y continúe con la comprobación del objeto Service y Pod creado a partir del archivo YAML todo en uno. A’partir de este instante devolvemos a esta pregunta.

Objetos de servicio

Dejar’cheque en

servicio

Se crea el servicio y se le asigna un clusterIP. Ya’hemos visto esto antes y parece como nada especial. Ahora, veamos’el back-end y los pods de cliente:

En este caso, todo parece correcto. Se está ejecutando un conjunto POD para el servicio. Ya ha aprendido cómo funcionan el selector y las etiquetas en las asociaciones Service-Pod. Nada nuevo aquí. Por lo’tanto, analicemos el HAProxy e intentemos detectar las dos direcciones IP asignadas al objeto Ingress.

HAProxy los procesos

Anteriormente, antes de que se creara la entrada, buscamos el proceso HAProxy en los nodos pero no pudimos ver nada. Deje’que vuelva a comprobarlo y vea si ocurre alguna magia:

En el cent222 del nodo:

En el cent333 del nodo:

Y justo después de crear la entrada, puede ver un proceso HAProxy creado en cada uno de nuestros dos nodos. Anteriormente afirmamos que Contrail la entrada de ingresos también se implementa a través del equilibrador de carga (solo como servicio). Dado que el tipo’loadbalancer_provider de Ingress es ‘opencontrail, contrail-SVC-monitor invoca al controlador de equilibrador de carga HAProxy. El controlador HAProxy genera la configuración de HAProxy necesaria para las reglas de entrada y desencadenadores HAProxy que se inicien los procesos (en modo activo-en espera) con la configuración generada en Kubernetes nodos.

Objetos de equilibrador de carga de entrada

Unas’pocas veces hemos mencionado el equilibrador de carga de entrada, pero todavía’Haven lo he visto. En la sección Service,’examinamos el objeto del equilibrador de carga del servicio en la interfaz de usuario, y inspeccionamos algunos detalles sobre la estructura de datos del objeto. Ahora, después de crear el objeto de entrada, deje’que s Compruebe la lista de objetos de equilibradores de carga y vea lo que trae la entrada en este caso comenzando por la UI en configure equilibradores de carga >.

Figure 4: USUARIO Configuración de equilibradores de carga

• Equilibrador de carga NS-usuario-1 entrada-SS para entrada ingreso-SS

• Equilibrador de carga NS-User-1 WebService-clusterip para Service WebServer-clusterip

Hemos’realizado el objeto de equilibrador de carga del servicio anteriormente, y si expande el servicio, verá muchos detalles pero nada le sorprendería.

Figure 5: Objeto de equilibrador de carga de servicio (haga clic en el triángulo situado a la izquierda del equilibrador de carga)

Como puede ver, el equilibrador de carga del servicio tiene un clusterIP y un objeto Listener que escucha en el puerto 8888. Una cosa que es resaltar es el loadbalancer_provider. Este tipo es nativo, por lo que la acción contrail-SVC-monitor es el proceso ECMP de capa 4 (Capa de aplicación), que se explora ampliamente en la sección Service. A’continuación, expanda el equilibrador de carga de entrada y eche un vistazo a los detalles.

Figure 6: Objeto de equilibrador de carga de entrada

• El loadbalancer_provider es opencontrail

• El equilibrador de carga de entrada tiene una referencia a un objeto de interfaz Virtual-Machine (VMI)

• Y se hace referencia al objeto VMI por medio de un objeto de IP de instancia con un 10.47.255.238 IP (fijo) y un objeto de IP flotante con 101.101.101.1 IP (flotante).

• Se trata de una dirección IP interna del clúster que se asigna desde la red Pod predeterminada como VIP de equilibrador de carga

• Es la IP de front-end en la que el equilibrador de carga de entrada escuchará para solicitudes HTTP

• Además, también es de qué 101.101.101.1 se asigna la dirección IP de variable pública con TDR.

• La dirección IP pod de entrada es la VIP dirigida a otros pods dentro de un clúster. Para alcanzar la entrada desde dentro del clúster, las solicitudes provenientes de otros pods tendrán su dirección IP de destino establecida en podIP de entrada.

• La dirección IP flotante de entrada es la VIP que se enfrenta al host de Internet fuera del mundo. Para alcanzar la entrada desde fuera del clúster, las solicitudes provenientes de hosts de Internet deben tener establecida la dirección IP de destino en FIP de entrada. Cuando el nodo recibe tráfico destinado a la dirección IP flotante de entrada desde fuera del clúster, el vRouter lo traducirá a la podIP de entrada.

La implementación del objeto de equilibrador de carga de entrada detallado hace referencia a una instancia de servicio, y la instancia de servicio incluye otras estructuras de datos o referencias a otros objetos (VM, VMIs, etc.). En general, es más complicado e implica más detalles de’los que se han tratado en este libro. Algunos’de los detalles se adaptan a una descripción general de alto nivel, por lo que los conceptos importantes como HAProxy y las dos Ingress IPS pueden entenderse al menos.

Una vez que una solicitud HTTP/HTTPS llega a la podIP de entrada, el equilibrador de carga de entrada realizará operaciones proxy HTTP/HTTPS a través del proceso HAProxy, y enviará las solicitudes hacia el servicio y finalmente al Pod back-end.

Vemos’que se está ejecutando el proceso HAProxy, para examinar más detalles de esta operación de proxy, deje’que consulte su archivo de configuración para obtener detalles sobre los parámetros en ejecución.

Archivo HAProxy. conf

• El front-end de HAProxy representa el front-end de un cliente que enfrenta las Ingress.

• El back-end HAProxy representa el back-end de una entrada, servicios orientados hacia el exterior.

• El front-end HAProxy define un enlace a la entrada podIP y MODE http. Estos botones indican lo que el front-end está escuchando.

• La sección back-end de HAProxy define el servidor, que en nuestro caso es un servicio back-end. Tiene un formato de serviceIP: servicePort, que es el objeto’de servicio exacto que creamos mediante el archivo "todo en uno" YAML.

• El default_backend en la sección front-end define qué backend es el valor predeterminado: se usará cuando un HAProxy reciba una solicitud de dirección URL que no tenga ninguna coincidencia explícita en ningún otro lugar de la sección front-end. En este caso, el default_backend se refiere únicamente al servicio de back-end 10.97.226.91:8888 esto se debe al hecho de que no hay reglas definidas en la entrada de un solo servicio, por lo que todas las solicitudes HTTP Irán al mismo default_backend servicio, independientemente de la dirección URL en la que el cliente envió.

Figure 7: Ingreso de servicio único

A lo largo de esta configuración, HAProxy implementó nuestro único servicio.

Tabla VRF de enrutadores de puerta de enlace

• El vRouter anuncia el prefijo IP flotante al controlador Contrail a través de XMPP. Al menos dos datos de la salida indican quién representa la dirección IP flotante en este cent222 de nodo de ejemplo:

  • El siguiente salto de protocolo es 10.169.25.20

  • El distintivo de la ruta es 10.169.25.20:5

• Y a través del BGP MP, Contrail Controller refleja el prefijo IP flotante al enrutador de la puerta de enlace. Fuente: 10.169.25.19 indica este hecho.

Por lo tanto, parece que cent222 está seleccionado como el nodo HAProxy activo y el otro nodo, cent333, es el que está en espera. Por lo tanto, debe esperar que una solicitud del cliente provenga del host de Internet para ir al nodo cent222 primero. Por supuesto, el tráfico de superposición se llevará a cabo en MPLS a través del túnel GRE,’igual que lo que se ve en el ejemplo del servicio.

El anuncio de IP flotante hacia el enrutador de puerta de enlace es exactamente igual en todos los tipos de entrada.

Otro hecho que se’omite a propósito es el valor de preferencia local diferente que usa el nodo activo y en espera al anunciar el prefijo IP flotante. Un examen completo incluye otros temas complejos, como el algoritmo de selección de nodo activo, etc., pero merece la pena comprender esto desde un nivel alto.

Ambos nodos tienen un equilibrador de carga y HAProxy en ejecución, por lo que ambos anunciarán el prefijo IP flotante 101.101.101.1 al enrutador de la puerta de enlace. Sin embargo, se anuncian con distintos valores de preferencia locales. El nodo activo se anunciará con un valor de 200 y el nodo de reserva con 100. Contrail controlador tienen rutas de los dos nodos, pero solo el ganador se anunciará al enrutador de puerta de enlace. Ésta es la razón por la que la otra ruta BGP se quita y solo se muestra una. Localpref que es 200 demuestra que procede del nodo de cálculo activo. Esto se aplica tanto a la ruta IP pública flotante de entrada como al anuncio de ruta VIP interna.

Comprobación de la entrada: Nivel

Todavía puede usar el comando rizo para activar las solicitudes HTTP en la dirección IP’privada de entrada. La devolución demuestra que nuestro ingreso funciona: las solicitudes hacia direcciones URL diferentes se procesan a través de proxy y se dirigen hacia los mismos pod de back-end, a través del servicio back-end predeterminado, Service-web-clusterip.

En la cuarta solicitud’, no asignaré una dirección URL a través de-H, por lo que enrollar el host con la dirección IP de la solicitud, 10.47.255.238 en esta prueba y, de nuevo, va al mismo conjunto pod de back-end y obtiene la misma respuesta devuelta.

Comprobación de la entrada: Externo (host de Internet)

Ahora, desde el escritorio de’host de Internet, inicie el explorador y escriba una de las tres direcciones URL. Al actualizar las páginas, puede confirmar que todas las solicitudes HTTP son devueltas por el mismo conjunto pod de back-end, tal como se muestra en la Figure 8.

Figure 8: Acceso a www.juniper.net desde el host de Internet

Entrada de fanout sencilla

Tanto el simple fanout de entrada como el enrutamiento de direcciones URL de compatibilidad de host virtual basado en nombres, la única diferencia es que el primero se basa en la ruta de acceso y el segundo se basa en el host.

• Un objeto de entrada: define las reglas, asignando dos paths a dos servicios back-end

• Dos objetos de servicios back-end

• Cada servicio requiere al menos un pod como back-end

• El mismo pod de cliente que el cliente interno del clúster utilizado en los ejemplos anteriores.

Definición de objetos de entrada

• Las solicitudes hacia ruta/dev se dirigirán a un servicio WebService-1 con servicePort 8888.

• Las solicitudes hacia ruta/QA se dirigirán a un servicio WebService-2 con servicePort 8888. Este es el archivo YAML correspondiente para implementar estos objetivos:

A diferencia de las ingresiones de servicio único, en el objeto simple fanout Ingress (y host virtual basado en nombres), puede ver las reglas definidas – aquí son las asignaciones de varios trazados a distintos servicios de servidor.

Definición del servicio back-end

Dado que definimos dos reglas para cada ruta, es necesario disponer de dos servicios, según corresponda. Puede clonar el servicio anterior en el ejemplo de la entrada de servicio único y simplemente cambiar ese’nombre y selector de Service s para generar el segundo servicio. Por ejemplo, ésta es la definición de servicio WebService-1 y WebService-2:

Definición de pod de back-end

Dado que ahora existen dos servicios backend, también necesitará al menos dos pods de back-end, cada uno con una etiqueta que coincida con un servicio. Puede clonar la implementación anterior en dos y solo cambiar el nombre y etiqueta de la segunda implementación.

Implementar inentradas de fanout sencillas

Ahora aplique el archivo All-in-One YAML para crear todos los objetos:

Ahora se crean los objetos de implementación, dos servicios y dos.

Examen posterior de entrada

Las reglas se han definido correctamente y, dentro de cada regla, existe una asignación desde una ruta de acceso al servicio correspondiente. Puede ver el mismo podIP interno de entrada y la IP flotante externa tal y como se ve en el ejemplo anterior del servicio Single Ingress:

Por eso, desde la perspectiva de enrutadores’de puerta de enlace, no existen diferencias entre todos los tipos de entrada. En todos los casos, una IP flotante pública se asignará a las Ingress y se anuncia al enrutador de la puerta de enlace:

Ahora, compruebe los servicios y los pods back-end. En primer lugar, los objetos de servicio:

Luego, el back-end y los conjuntos de clientes:

Se crean dos servicios, cada uno con un clusterIP asignado distinto. Para cada servicio existe un pod back-end. Más adelante, cuando verificamos la entrada del cliente,’vemos estas podIPs en las páginas web devueltas.

Contrail objeto de equilibrador de carga de entrada

En comparación con la única diferencia de la entrada de servicio, la única es otro equilibrador de carga de servicio, como se muestra en la siguiente captura de pantalla.

Figure 9: Equilibradores de carga de entrada simple fanout (UI: configuración > redes > IP flotante)

• Equilibrador de carga NS-usuario-1 ingresos-CF para ingresos de entrada-CF

• Equilibrador de carga NS-usuario-1 WebService-1 para Service WebServer-1

• Equilibrador de carga NS-usuario-1 WebService-2 para servicio WebServer-2

Hemos ganado’la siguiente exploración de los detalles de los objetos,’ya que hemos investigado los parámetros clave de los equilibradores de carga de servicio y entrada en las ingress de servicio único y realmente no hay nada nuevo aquí

HAProxy proceso y HAProxy archivo. cfg

En el ejemplo de la ingress de servicio único, mostramos dos procesos HAProxy invocados por contrail-SVC-monitor cuando ve que el loadbalancer aparezca con loadbalancer_provider y estableció en opencontrail. Al final de este ejemplo, después de eliminar la entrada de un solo servicio, ya que no quedan más ingresos en el clúster, los dos procesos de HAProxy terminarán. Ahora, con una nueva creación de la entrada, se vuelven a invocar los dos nuevos procesos de HAProxy:

Cent222 del nodo:

Cent333 del nodo:

En esta ocasión nos interesa cómo se programan las reglas simples de fanout de entrada en el archivo HAProxy. conf. Echemos’un vistazo al archivo de configuración HAProxy:

• La sección HAProxy frontend: Ahora define direcciones URL. Cada dirección URL se representa mediante un par de instrucciones LCA, una para el host y la otra para la ruta de acceso. En pocas palabras, host es el nombre del dominio y ruta de acceso es lo que sigue al host en la cadena de la dirección URL. Aquí, para obtener Ingress simples de fanout, existe el host www. Juniper. red con dos rutas diferentes: \dev y \qa.

• La sección back-end de HAProxy: Ahora hay dos. Para cada ruta hay un servicio dedicado.

• El comando…use_backend… if en la sección front-end: Esta instrucción declara las reglas – de entrada si la solicitud de dirección URL incluye una ruta de acceso especificada que coincide con lo programado en uno de los dos pares de LCA, utilice el back-end correspondiente (es decir, el servicio) para reenviar el tráfico.

Por ejemplo, ACL 020e371c-e222-400F-b71f-5909c93132de_path ruta/QA define la ruta/QA. Si la solicitud de dirección URL contiene una ruta de acceso, HAProxy use_backend 020e371c-e222-400F-b71f-5909c93132de, que puede encontrar en la sección back-end. El back-end es un UUID que se refiere a Server c13b0d0d-6e4a-4830-BB46-2377ba4caf23 10.100.156.38:8888 Weight 1, que es esencialmente un servicio. Esto se puede identificar en la vista en serviceIP: puerto: 10.100.156.38:8888.

El archivo de configuración se ilustra en la Figure 10.

Figure 10: Servicio fanout simple

• Si la dirección URL completa se compone de www.juniper.net de host y ruta de acceso/dev, la solicitud se enviará a WebService-1 (10.96.51.227:8888).

• Si la dirección URL completa se compone de www.juniper.net de host y ruta de acceso/QA, la solicitud se enviará al servicio WebService-2 (10.100.156.38:8888).

• Para cualquier otra dirección URL, la solicitud se perderá porque no se definió ningún servicio back-end correspondiente.

Comprobación de la entrada: de Internal

Permitir’que s pruebe la dirección URL con distintas rutas:

El resultado devuelto muestra el trabajo de entrada: las dos solicitudes hacia los paths/QA y/dev se dirigen a través de proxy a dos distintos pods de back-end a través de dos servicios back-end: WebService-1 y WebService-2, respectivamente.

La tercera solicitud con una ruta de acceso ABC crea una dirección URL desconocida que no tiene un servicio coincidente en la configuración de entrada, por lo que’ha ganado t servir. Esto’es lo mismo para las dos últimas solicitudes. Sin una ruta de acceso o con un host distinto, las direcciones URL se vuelven desconocidas para los ingresos’, por lo que suquieren que no se sirvan.

Es posible que piense que debe agregar más reglas para incluir estos escenarios. Si esto funciona bien, pero’s no es escalable – , nunca podrá cubrir todas las rutas y direcciones URL posibles que puedan entrar en su servidor. Como mencionamos anteriormente, una solución consiste en usar el servicio default_backend para procesar todas las demás solicitudes HTTP, que se abordarán en el ejemplo siguiente.

Comprobación de la entrada: De externo (host de Internet)

Cuando prueba las ingresiones sencillas de fanout desde fuera del clúster, el comando es el mismo’que ha realizado para iniciar la solicitud HTTP desde el interior de una caja Pod, pero esta vez iniciando desde un host de Internet. Deje’que s envíe las solicitudes HTTP a la dirección IP’flotante pública de entrada, en lugar de su podIP interna. Por lo tanto, desde un equipo host de Internet:

Ingreso de hospedaje virtual

La entrada de hospedaje virtual admite el enrutamiento de tráfico HTTP a varios nombres de host con la misma dirección IP. Según la dirección URL y las reglas, un equilibrador de carga de entrada dirige el tráfico a distintos servicios de servidor, y cada servicio dirige el tráfico a sus pods back-end, como en este diagrama:

• Un objeto de entrada: las reglas que asignan dos direcciones URL a dos servicios back-end

• Dos objetos de servicios back-end

• Cada servicio requiere al menos un pod como back-end

Definición de objetos de entrada

• Una solicitud hacia www.juniper.net de dirección URL se dirigirá a un servicio WebService-1 con servicePort 8888.

• Una solicitud hacia www.cisco.com de dirección URL se dirigirá a un servicio WebService-2 con servicePort 8888.

• Una solicitud para cualquier dirección URL que no sea estas dos se dirigirá a WebService-1 con servicePort 8888. De hecho, queremos que WebService-1 sea el servicio back-end predeterminado.

Y este es el archivo de definición de YAML correspondiente:

Definición del servicio back-end y Pod.

Aquí se puede usar el mismo servicio y la misma definición de implementación que se usaron en la fanout de entrada sencilla. Y para ser más más breve, aquí’se muestra el archivo All-in-One YAML:

Ahora vamos’a aplicar el archivo YAML todo en uno para crear la entrada y los demás objetos necesarios:

Puede ver que ahora se han creado las entrada, dos servicios y dos objetos de implementación.

El examen posterior de entrada permite’al s examinar el objeto de entrada:

En comparación con las sencillas fanout Ingress, esta vez puede ver dos hosts en lugar de uno solo. Cada host representa un nombre de dominio:

Las reglas se han definido correctamente y, dentro de cada regla, hay una asignación de un host al servicio correspondiente. Tenga en cuenta que los servicios, los pods y el prefijo IP flotante se anuncian en el comportamiento de enrutador de puerta de enlace son exactamente iguales que los de Ingress simples de fanout.

Explorar los objetos de equilibrador de carga de entrada

Se generaron tres equilibradores de carga después de aplicar el archivo All-in-One YAML, uno para la entrada y dos para los servicios.

Los equilibradores de carga creados en esta prueba son prácticamente iguales a los creados en la fanout de la sencilla prueba de entrada, como se muestra en la siguiente captura de pantalla, en la Figure 11.

Figure 11: Equilibradores de carga

Bien, deje’que s busque el archivo de configuración HAProxy para buscar si está basado en el nombre

host virtual Ingress. Aquí’se examina el archivo HAProxy. conf:

• La sección HAProxy frontend define cada dirección URL, o host, y su ruta de acceso. En este caso, los dos hosts son www.juniper.net y www.cisco.com, y para ambas rutas de acceso es/.

• La sección back-end de HAProxy define los servidores, que es todo lo que se presta al servicio en nuestro caso. Tiene un formato de serviceIP: servicePort, que es lo que el servicio creó.

• El comando…use_backend… if en la sección front-end declara las reglas de entrada: Si la solicitud incluye una dirección URL y una ruta de acceso especificadas, utilice el back-end correspondiente para reenviar el tráfico.

• En el default_backend se define el servicio que actuará como predeterminado: se utilizará cuando un HAProxy reciba una solicitud de dirección URL que no tenga ninguna coincidencia explícita en las reglas definidas.

El flujo de trabajo del archivo de configuración se ilustra en la Figure 12.

Figure 12: Flujo de trabajo del’archivo de configuración HAProxy

• Si www.juniper.net y/Redacte la dirección URL completa, la solicitud se distribuirá a WebService-1 (10.99.225.17:8888).

• Si www.cisco.net y/Redacte la dirección URL completa, la solicitud se distribuirá a WebService-2 (10.105.134.79:8888).

• Otras direcciones URL van al back-end predeterminado, que es Service

webservice-1. Deje’que continúe y compruebe estos comportamientos.

Comprobación de la entrada: De Internal

Desde el interior del clúster:

El ingreso funciona. Las dos solicitudes hacia Juniper y Cisco se dirigen a través de proxy hacia dos pod de back-end diferentes, por medio de dos servicios backend, WebService-1 y WebService-2, respectivamente. La tercera solicitud hacia Google es una dirección URL desconocida, que no tiene un servicio coincidente en la configuración de entrada, por lo que se dirige al servicio back-end predeterminado, WebService-1, y llega al mismo Pod back-end.

La misma regla se aplica a la cuarta solicitud. Si no se proporciona una dirección URL que utilice-H, Rizo llenará el host con la dirección IP de la solicitud, en este caso 10.47.255.238. Dado que dicha dirección URL’no tiene un servicio back-end definido, se usará el servicio back-end predeterminado. En nuestro laboratorio, usamos los pods de back-end para cada servicio generado por la misma implementación, por lo que la podIP en una página web devuelta nos dice quién es quién. Excepto en la segunda prueba, el podIP devuelto fue 10.47.255.235, que representa WebService-2, mientras que las otras tres pruebas devolvieron el podIP para WebService-1, tal y como se esperaba.

Comprobación de la entrada: de externo (host de Internet)

Desde el escritorio de’un host de Internet, se lanzaron dos páginas cromadas lado a lado y www.Juniper.net de entrada en uno y www.Cisco.com en el otro, y se mantuvieron las páginas al actualizar. Podemos comprobar que la página de Juniper siempre será devuelta por la implementación WebServer-1 Pod 10.47.255.236, y que la página Cisco siempre sea devuelta por la implementación WebServer-2 Pod 10.47.255.235. A continuación, se lanzaría una tercera página de cromo hacia www.google.com, que fue devuelta por la misma caja Pod que atiende a la instancia Juniper, como se muestra en las capturas de pantalla de la Figure 13.

Figure 13: Host de Internet

También se puede ver el mismo resultado de doblez. En este’caso, se muestra desde el equipo host de Internet:

Flujo de tráfico de servicio frente a ingreso

Aunque tanto el servicio como las Ingress se implementan a través de equilibradores de carga (aunque con tipos de proveedores de loadbalancer_ distintos), los modos de envío de servicio y entrada son bastante diferentes. Con el reenvío de’servicios se trata de un proceso de un solo salto: el cliente envía la solicitud a la clusterIP o a la IP flotante. Con TDR, la solicitud llega al Pod back backend de destino; Aunque con el reenvío de entrada, el tráfico lleva un proceso de dos saltos para llegar a la caja pod de destino. La solicitud se dirige primero a la HAProxy activa, que a su vez inicia un procedimiento proxy del nivel HTTP/HTTPS y hace el reenvío del servicio para llegar al conjunto Pod final. El procesamiento de TDR se produce en ambos procesos de reenvío, ya que la implementación IP flotante pública de entrada y servicio depende de él.

El capítulo 7 proporciona una vista detallada de este Contrail flujo de paquetes.