Configuración del servicio Contrail
Antes de comenzar la investigación,’deje que se vea la configuración. En este libro, creamos una instalación que incluye los siguientes dispositivos, la mayoría de nuestros estudios de caso se basan en él:
un servidor de la K8S que funcione como maestro y controladores de Contrail
dos servidores de "out", cada uno de los cuales se ejecuta como un nodo K8S y Contrail vRouter
un conmutador Juniper QFX que funciona como la hoja subyacente
uno Juniper enrutador MX que se ejecuta como enrutador de puerta de enlace o spine
un servidor de la que funciona como un equipo host de Internet
La Figure 1 muestra la configuración.
Para minimizar la utilización de recursos, todos los servidores son en realidad máquinas virtuales creadas por un hipervisor de VMware que se ejecuta en un servidor físico HP. Este es también el mismo testbed para las Ingress. El apéndice de este libro contiene detalles acerca de la configuración.
Servicio Contrail ClusterIP
El capítulo 3 demuestra cómo crear y comprobar un servicio clusterIP. En esta sección se vuelve a visitar el laboratorio para consultar algunos detalles importantes sobre’implementaciones específicas de contrail s. Supongamos que’continuemos y agregue algunas pruebas más para ilustrar los detalles de implementación del equilibrador de carga del servicio contrail.
ClusterIP como IP flotante
Este es el archivo YAML usado para crear un servicio clusterIP:
#service-web-clusterip.yaml apiVersion: v1 kind: Service metadata: name: service-web-clusterip spec: ports: - port: 8888 targetPort: 80 selector: app: webserver
Y aquí’es una revisión de lo que obtuvimos del laboratorio de servicios del capítulo 3:
$ kubectl get svc -o wide NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR service-web-clusterip ClusterIP 10.105.139.153 <none> 8888/TCP 45m app=webserver $ kubectl get pod -o wide --show-labels NAME READY STATUS ... IP NODE ... LABELS client 1/1 Running ... 10.47.255.237 cent222 ... app=client webserver-846c9ccb8b-g27kg 1/1 Running ... 10.47.255.238 cent333 ... app=webserver
Puede ver que se ha creado un servicio, con un conjunto Pod ejecutándose como back-end. La etiqueta en el POD coincide con el SELECTOR en servicio. El nombre del conjunto Pod también indica que se trata de un conjunto Pod generado por la implementación. Más adelante, podemos escalar el estudio de implementación para el caso ECMP, pero’por ahora dejar que los s se adhieran a un conjunto Pod y que examinemos los detalles de implementación de clusterIP.
En Contrail, ClusterIP se implementa esencialmente en forma de IP flotante. Una vez creado un servicio, se asignará una dirección IP flotante de la subred de servicio y se asociará a todas las VMIs pod de servidor para formar el equilibrio de carga de ECMP. Ahora se puede acceder a todos los pods de back-end mediante cluserIP (junto con el IP POD). Este clusterIP (IP flotante) actúa como VIP de los pods de cliente en el interior del clúster.
¿Por qué Contrail eligen la IP flotante para implementar clusterIP? En la sección anterior, aprendió que Contrail sí TDR para la IP flotante y el servicio también necesita TDR. Por lo tanto, es natural utilizar la dirección IP flotante para lusterIP.
Para el tipo de servicio de equilibrador de carga, Contrail asignará una segunda IP flotante: la IP externa como dirección VIP y la dirección VIP externa se anuncia fuera del clúster a través del enrutador de puerta de enlace. Más adelante, obtendrá más información sobre estas cosas.
Desde la UI puede ver la dirección IP flotante asignada automáticamente como lusterIP en la Figure 2.
Y la IP flotante también está asociada con el conjunto Pod VMI y la IP Pod, en este caso el VMI representa la interfaz Pod que se muestra en la Figure 3.
La interfaz se puede expandir para mostrar más detalles, como en la siguiente captura de pantalla, que se muestra en la Figure 4.
Expanda la fip_list, donde’puede ver la información aquí:
fip_list:
{ list:
{
FloatingIpSandeshList:
{
ip_addr: 10.105.139.153
vrf_name: default-domain:k8s-ns-user-1:k8s-ns-user-1-
service-network:k8s-ns-user-1-service-network installed: Y
fixed_ip:
10.47.255.238
direction: ingress
port_map_enabled:
true port_map:
{
list:
{
SandeshPortMapping:
{
protocol: 6
port: 80
nat_port: 8888
}
}
}
}
}
}
Service/clusterIP/FIP 10.105.139.153 se asigna a podIP/fixed_ip 10.47.255.238. El port_map indica que el puerto 8888 es un nat_port, 6 es el número de protocolo, de modo que significa TCP de protocolo. En general, clusterIP: Puerto 10.105.139.153:8888 se traducirá a podIP: targetPort 10.47.255.238:80, y viceversa.
Ahora entendemos con una dirección IP flotante que representa clusterIP, TDR se producirá en servicio. TDR volverá a examinarse en la tabla de flujo.
Escala de los pods back-end
En el ejemplo’de servicio ClusterIP de capítulo 3 s, creamos un servicio y un conjunto Pod. Para comprobar la ECMP, deje’que la unidad de réplica sea la 2 para generar un segundo conjunto pod de back-end. Este es un modelo más realista: Ahora, cada uno de los pods se respaldará mutuamente para evitar fallas en un único punto.
En lugar de utilizar un archivo YAML para crear manualmente un nuevo conjunto webserver, con el espíritu de Kubernetes en mente, piense en la escala a una implementación, tal y como se hizo anteriormente en este manual. En nuestro ejemplo de servicio’, hemos utilizado un objeto de implementación a fin de generar nuestro conjunto WebServer:
$ kubectl scale deployment webserver --replicas=2 deployment.extensions/webserver scaled $ kubectl get pod -o wide --show-labels NAME READY STATUS ... IP NODE ... LABELS client 1/1 Running ... 10.47.255.237 cent222 ... app=client webserver-846c9ccb8b-7btnj 1/1 Running ... 10.47.255.236 cent222 ... app=webserver webserver- 846c9ccb8b-g27kg 1/1 Running ... 10.47.255.238 cent333 ... app=webserver $ kubectl get svc -o wide NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR service-web-clusterip ClusterIP 10.105.139.153 <none> 8888/TCP 45m app=webserver
Inmediatamente después de crear un nuevo conjunto de servidores WebServer mediante la ampliación de la implementación con las réplicas 2, se inicia un conjunto Pod nuevo. Acaba con dos pods de back-end, uno se está ejecutando en el mismo nodo cent222 que el pod de cliente, o en un nodo local para Client Pod; el otro se ejecuta en el otro nodo cent333, el nodo remoto desde la perspectiva Pod’s de cliente. Y los objetos de extremo se actualizan para reflejar el conjunto actual de pods de back-end detrás del servicio.
$ kubectl get ep -o wide NAME ENDPOINTS AGE service-web-lb 10.47.255.236:80,10.47.255.238: 80 20m
Sin la opción-o Wide de-o, solo se mostrará correctamente el primer punto de conexión.
Deje’que se vuelva a comprobar la IP flotante.
En la Figure 5 , puede ver la misma dirección IP flotante, pero ahora está asociada a dos podIPs, cada uno de los cuales representa un conjunto Pod independiente.
Tabla de enrutamiento de ECMP
Primero deje’que se examine el ECMP. ’Echemos un vistazo a la tabla de enrutamiento de la instancia’de enrutamiento de controlador s en la captura de pantalla que se muestra en la Figure 6.
La instancia de enrutamiento (RI) tiene un nombre completo con el formato siguiente:
< DOMAIN >: < PROJECT >: < VN >: < RI >
En la mayoría de los casos, RI hereda el mismo nombre de su red virtual, por lo que en este caso la tabla de enrutamiento de IPv4 completa tiene este nombre:
default-domain:k8s-ns-user-1:k8s-ns-user-1-pod-network:k8s-ns-user-1-pod-network.inet.0
La. inet. 0 indica que el tipo de tabla de enrutamiento es unidifusión de IPv4. Existen muchas otras tablas que, por el momento, no nos interesan.
Dos movimientos de ruta con idénticos prefijos de la clusterIP aparecen en la tabla de enrutamiento, con dos saltos diferentes, cada uno de los cuales señala a un nodo diferente. Esto nos da una sugerencia sobre el proceso de propagación de la ruta: ambos nodos (Compute) han anunciado el mismo clusterIP hacia el controlador maestro (Contrail), para indicar que los pods backend en ejecución están presentes en él. Esta propagación de ruta se realiza a través del XMPP. A continuación, el controlador maestro (Contrail) refleja las rutas a todos los demás nodos de cálculo.
Perspectiva del nodo de cálculo
A continuación, a partir del nodo pod de cliente cent222’, echemos una mirada’a la tabla VRF s, para comprender cómo se reenvían los paquetes hacia los pods back-end en la captura de pantalla en la Figure 7.
La parte más importante de la captura de pantalla de la Figure 7 es el prefijo de la entrada de enrutamiento: 10.105.139.153/32 (1 ruta), ya que es nuestra dirección clusterIP. Debajo del prefijo se encuentra la afirmación de la cuenta ECMP composite sub NH: 2. esto indica que el prefijo puede alcanzar varios saltos siguientes.
Ahora, expanda la instrucción ECMP haciendo clic en el icono de triángulo pequeño que hay a la izquierda y se le ofrecerán muchos más detalles sobre este prefijo, como se muestra en la siguiente captura de pantalla en la Figure 8.
La mayor parte de la importación de todos los detalles de este resultado es la de nuestro enfoque nh_index: 87, que es el ID del próximo salto (NHID) para el prefijo clusterIP. Desde el Docker Agent vRouter, puede resolver aún más el NHID compuesto con el subnhs, que son los próximos lúpulos situados debajo del siguiente salto compuesto.
’No olvides ejecutar los comandos vRouter desde el contenedor vRouter Docker. Llevarla a cabo directamente desde el host puede que no funcione:
[2019-07-04 12:42:06]root@cent222:~ $ docker exec -it vrouter_vrouter-agent_1 nh --get 87 Id:87 Type:Composite Fmly: AF_INET Rid:0 Ref_cnt:2 Vrf:2 Flags:Valid, Policy, Ecmp, Etree Root, Valid Hash Key Parameters: Proto,SrcIP,SrcPort,DstIp,DstPort Sub NH(label): 51(43) 37(28) #<--- Id:51 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:18 Vrf:0 Flags:Valid, MPLSoUDP, Etree Root, #<--- Oif:0 Len:14 Data:00 50 56 9e e6 66 00 50 56 9e 62 25 08 00 Sip:10.169.25.20 Dip:10.169.25.21 Id:37 Type:Encap Fmly:AF_INET Rid:0 Ref_cnt:5 Vrf:2 Flags:Valid, Etree Root, EncapFmly:0806 Oif:8 Len:14 #<--- Encap Data: 02 30 51 c0 fc 9e 00 00 5e 00 01 00 08 00
Información importante para resaltar este resultado:
NHID 87 es un ECMP compuesto de un próximo salto.
El siguiente salto de ECMP contiene dos saltos siguientes: el siguiente salto 43 y el próximo salto 28, cada uno representa un path separado hacia los pods de back-end.
El siguiente salto 51 representa un túnel MPLSoUDP hacia backend Pod en el nodo remoto, el túnel se establece desde el nodo actual cent222, con la dirección IP de origen 10.169.25.20 de IP de la estructura local, al otro nodo cent333 cuya estructura IP sea 10.169.25.21. Si recuerda dónde se encuentran nuestros dos pods backend, ésta es la ruta de reenvío entre los dos nodos.
El próximo salto 37 representa una ruta local, hacia VIF 0/8 (interfaces salientes: 8), que es la’interfaz Pod s back-end local.
Para resolver la interfaz vRouter VIF, utilice el comando VIF--Get 8:
$ vif --get 8 Vrouter Interface Table ...... vif0/8 OS: tapeth0-304431 Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.47.255.236 #<--- Vrf:2 Mcast Vrf:2 Flags:PL3DEr QOS:-1 Ref:6 RX packets:455 bytes:19110 errors:0 TX packets:710 bytes:29820 errors:0 Drops:455
La salida muestra el correspondiente nombre, dirección’IP, etc. de la interfaz local del Pod.
Flujo de trabajo de servicio ClusterIP
El flujo de’trabajo ECMP de equilibrador de carga clusterIP Service s se ilustra en la Figure 9.
Esto es lo que sucedió en el plano de envío:
Un cliente Pod ubicado en cent222 de nodo necesita tener acceso a un servicio de servicio-Web-clusterip. Envía un paquete hacia el servicio’s clusterIP 10.105.139.153 y el puerto 8888.
El cliente Pod envía el paquete al cent222 del nodo vRouter basándose en la ruta predeterminada.
El vRouter en el nodo cent222 obtiene el paquete, comprueba su tabla VRF correspondiente, obtiene un identificador de salto siguiente 87 compuesto, que resuelve dos saltos subsiguientes 51 y 37, que representan un pod back-end remoto y local, respectivamente. Esto indica ECMP.
El vRouter en el nodo cent222 comienza a reenviar el paquete a uno de los pods basándose en su algoritmo ECMP. Supongamos que se ha seleccionado Remote back-end Pod, el paquete se enviará a través del túnel MPLSoUDP al Pod remoto en el nodo cent333, después de establecer el flujo en la tabla de flujo. Todos los paquetes posteriores que pertenezcan al mismo flujo seguirán esta ruta. Lo mismo se aplica a la ruta de acceso local hacia el pod de back-end local.
Servicio de puertos múltiples
Ahora debe comprender cómo funcionan las capas de servicio 4 ECMP y los objetos de LB en el laboratorio. La Figure 10 muestra las lb y los objetos relevantes, por lo que puede ver que un lb puede tener dos o más oyentes de lb. Cada oyente tiene un grupo de back-end individual que tiene uno o varios miembros.
En Kubernetes, esta asignación 1: N entre equilibradores de carga y oyentes indica un servicio de varios puertos, un servicio con varios puertos. Veamos’el archivo YAML del mismo: SVC/Service-web-clusterip-MP. yaml:
apiVersion: v1 kind: Service metadata: name: service-web-clusterip-mp spec: ports: - name: port1 port: 8888 targetPort: 80 - name: port2 #<--- port: 9999 targetPort: 90 selector: app: webserver
Lo que se ha agregado es otro elemento de la lista de puertos: un nuevo puerto de servicio 9999 que se asigna al’puerto de destino s-Container 90. Ahora, con dos asignaciones de puertos, debe asignar a cada puerto un nombre, por ejemplo, PORT1 y port2, respectivamente.
Sin un nombre de puerto, los’ múltiples puertos YAML’archivo ganaron t funcionan.
Ahora aplique el archivo YAML. Se crea un nuevo servicio de servicio-Web-clusterip-MP con dos puertos:
$ kubectl apply -f svc/service-web-clusterip-mp.yaml service/service-web-clusterip-mp created $ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service-web-clusterip ClusterIP 10.105.139.153 <none> 8888/TCP 3h8m service-web-clusterip-mp ClusterIP 10.101.102.27 <none> 8888/TCP,9999/TCP 4s $ kubectl get ep NAME ENDPOINTS AGE service-web-clusterip 10.47.255.238:80 4h18m service-web-clusterip-mp 10.47.255.238:80,10.47.255.238:90 69m
Para simplificar el caso práctico, el número’de réplicas de la implementación de back-end se ha reducido a uno.
¿Se ve todo bien,’¿es t? El nuevo servicio cuenta con dos puertos de servicio expuestos, 8888, el antiguo que se’probó en ejemplos anteriores y el nuevo puerto 9999, deben ser igualmente buenos. Pero resulta que no es éste el caso. Es’decir, investigar.
El puerto de servicio 8888 funciona:
$ kubectl exec -it client -- curl 10.101.102.27:8888 | w3m -T text/html | cat Hello This page is served by a Contrail pod IP address = 10.47.255.238 Hostname = webserver-846c9ccb8b-g27kg
El puerto de servicio 9999’no funciona:
$ kubectl exec -it client -- curl 10.101.102.27:9999 | w3m -T text/html | cat command terminated with exit code 7 curl: (7) Failed to connect to 10.101.102.27 port 9999: Connection refused
Se rechazará la solicitud hacia el puerto 9999. La razón es que el targetPort no se está ejecutando en el contenedor Pod, por lo tanto, no hay ninguna manera de obtener una respuesta del mismo:
$ kubectl exec -it webserver-846c9ccb8b-g27kg -- netstat -lnap Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1/python Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node PID/Program name Path
El readinessProbe introducido en el capítulo 3 es la herramienta oficial de Kubernetes para detectar esta situación, por si el conjunto Pod no está listo, se reiniciará y podrá capturar los eventos.
Para resolver esto’, inicie un nuevo servidor en el conjunto POD para escuchar en un nuevo puerto 90. Una de las maneras más sencillas de iniciar un servidor HTTP es utilizar el módulo SimpleHTTPServer que acompaña al paquete python. En esta prueba solo necesitamos establecer el puerto de escucha en 90 (el valor predeterminado es 8080):
$ kubectl exec -it webserver-846c9ccb8b-g27kg -- python -m SimpleHTTPServer 90 Serving HTTP on 0.0.0.0 port 90 ...
El targetPort está activado. Ahora puede volver a iniciar la solicitud hasta el puerto de servicio 9999 desde el conjunto Pod cirros. Esta vez lo consigue y obtiene la página web devuelta de’Python s SimpleHTTPServer:
$ kubectl exec -it client -- curl 10.101.102.27:9999 | w3m -T text/html | cat Directory listing for / ━━━━━━━━━━━━━━━━━━━━━ • app.py • Dockerfile • file.txt • requirements.txt • static/ ━━━━━━━━━━━━━━━━━━━━━
A continuación, para cada solicitud entrante, el SimpleHTTPServer registra una línea de salida con una dirección IP que muestra de dónde procede la solicitud. En este caso, la solicitud proviene de la caja de clientes con la dirección IP:
10.47.255.237: 10.47.255.237 - - [04/Jul/2019 23:49:44] "GET / HTTP/1.1" 200 –
Tabla de flujo de Contrail
Hasta ahora, hemos’probado el servicio clusterIP y hemos’visto solicitudes de clientes que se envían hacia la dirección IP del servicio. En Contrail, vrouter es el módulo que hace todo el reenvío de paquetes. Cuando el vrouter obtiene un paquete de la caja de cliente, busca la tabla VRF correspondiente en el módulo vRouter de Client Pod, obtiene el siguiente salto y resuelve la interfaz de salida correcta y la encapsulación correcta. Hasta ahora, el cliente y los pods back-end se encuentran en dos nodos diferentes, y el vrouter de origen decide que los paquetes necesarios se envían en el túnel MPLSoUDP hacia el nodo en el que se ejecuta el conjunto pod de backend. ¿Qué es lo que más le interesa?
¿Cómo se traducen las direcciones IP del servicio y del pod de back-end en otras?
¿Hay alguna forma de capturar y ver las dos IP en un flujo, antes y después de las traducciones, con fines comparativos?
El método más directo que pensaba es capturar los paquetes, descodificar y ver los resultados. Sin embargo, esto puede no ser tan fácil como lo que espera. En primer lugar, debe capturar el paquete en lugares diferentes:
En la interfaz Pod, esto es después de que se traduzca la dirección y’que s sea fácil.
En la interfaz de estructura, esto es antes de que el paquete se traduzca y llegue a la interfaz Pod. En este caso, los paquetes tienen encapsulación MPLSoUDP ya que los paquetes del plano de datos se canalizan entre los nodos.
A continuación, es necesario copiar el archivo de pcap y cargarlo con Wireshark en el descodificador. Es probable que también necesite configurar Wireshark para reconocer la encapsulación MPLSoUDP.
Una manera más fácil de hacerlo es comprobar la tabla de flujo vRouter, que registra los detalles de puerto e IP sobre un flujo de tráfico. Deje’que lo pruebe preparando un archivo de gran tamaño, archivo. txt, en la caja de datos del servidor webback-end e intente descargarlo desde la caja pod de cliente.
Puede que se pregunte: para activar un flujo por qué’no basta con usar la misma prueba de rizo para extraer la página web? Eso’es lo que hicimos en una prueba temprana. En teoría, esto es correcto. El único problema es que el flujo TCP sigue la sesión TCP. En nuestra prueba anterior, con doblez, la sesión TCP se inicia y se detiene inmediatamente después de recuperar la página web, entonces el vRouter borra el flujo de inmediato. Usted ganó’que no sea lo suficientemente rápido para capturar la tabla de flujo en el momento adecuado. En su lugar, la descarga de un archivo de gran tamaño – ocupará la sesión de TCP siempre que la transferencia de archivos – esté en curso la sesión permanecerá y puede tomarse tiempo para investigar el flujo. Posteriormente, la sección de entrada mostrará un método diferente con una secuencia de comandos de Shell de una línea.
Por lo tanto, en la dirección URL de enrutador de cliente Pod, en lugar de simplemente para la de raíz o para’enumerar los archivos de la carpeta, voy a intentar extraer el archivo: file.txt:
$ kubectl exec -it client -- curl 10.101.102.27:9999/file.txt
Y en el conjunto de servidores, vemos el registro que indica que se inicia la descarga de archivos:
10.47.255.237 - - [05/Jul/2019 00:41:21] "GET /file.txt HTTP/1.1" 200 –
Ahora, con la transferencia de archivos continua, habrá’tiempo suficiente para recopilar la tabla de flujo de los nodos cliente y servidor, en el contenedor vRouter:
Tabla de flujo del nodo cliente:
(vrouter-agent)[root@cent222 /]$ flow --match 10.47.255.237 Flow table(size 80609280, entries 629760) Entries: Created 1361 Added 1361 Deleted 442 Changed 443Processed 1361 Used Overflow entries 0 (Created Flows/CPU: 305 342 371 343)(oflows 0) Action:F=Forward, D=Drop N=NAT(S=SNAT, D=DNAT, Ps=SPAT, Pd=DPAT, L=Link Local Port) Other:K(nh)=Key_Nexthop, S(nh)=RPF_Nexthop Flags:E=Evicted, Ec=Evict Candidate, N=New Flow, M=Modified Dm=Delete Marked TCP(r=reverse):S=SYN, F=FIN, R=RST, C=HalfClose, E=Established, D=Dead Listing flows matching ([10.47.255.237]:*) Index Source:Port/Destination:Port Proto(V) 40100<=>340544 10.47.255.237:42332 6 (3) 10.101.102.279999 (Gen: 1, K(nh):59, Action:F, Flags:, TCP:SSrEEr, QOS:-1, S(nh):59, Stats:7878/520046, SPort 65053, TTL 0, Sinfo 6.0.0.0) 340544<=>40100 10.101.102.279999 6 (3) 10.47.255.237:42332 (Gen: 1, K(nh):59, Action:F, Flags:, TCP:SSrEEr, QOS:-1, S(nh):68, Stats:142894/205180194, SPort 63010, TTL 0, Sinfo 10.169.25.21)
Los elementos destacados de este resultado son:
La caja de cliente Pod inicia la conexión TCP desde el 10.47.255.237 IP del conjunto Pod y un puerto de origen aleatorio, hacia el 10.101.102.27 IP de servicio y el puerto 9999 del servidor.
El indicador TCP de Flow SSrEEr indica que la sesión se establece de forma bidireccional.
La acción: F significa reenvío. Tenga en cuenta que no hay ningún procesamiento especial, como TDR sucede aquí.
Cuando utilice un filtro como –-15.15.15.2 de coincidencia, sólo se mostrarán las entradas de flujo con IPs de host de Internet.
Desde la perspectiva del nodo’cliente, podemos concluir que solo ve el IP del servicio y no es consciente de ninguna de las IP del Pod back-end.
’Observemos la tabla de flujo del nodo de servidor en el nodo servidor vRouter contenedor del acoplador:
vrouter-agent)[root@cent333 /]$ flow --match 10.47.255.237 Flow table(size 80609280, entries 629760) Entries: Created 1116 Added 1116 Deleted 422 Changed 422Processed 1116 Used Overflow entries 0 (Created Flows/CPU: 377 319 76 344)(oflows 0) Action:F=Forward, D=Drop N=NAT(S=SNAT, D=DNAT, Ps=SPAT, Pd=DPAT, L=Link Local Port) Other:K(nh)=Key_Nexthop, S(nh)=RPF_Nexthop Flags:E=Evicted, Ec=Evict Candidate, N=New Flow, M=Modified Dm=Delete Marked TCP(r=reverse):S=SYN, F=FIN, R=RST, C=HalfClose, E=Established, D=Dead Listing flows matching ([10.47.255.237]:*) Index Source:Port/Destination:Port Proto(V) 238980<=>424192 10.47.255.238:90 6 (2->3) 10.47.255.237:42332 (Gen: 1, K(nh):24, Action:N(SPs), Flags:, TCP:SSrEEr, QOS:-1, S(nh):24, Stats:8448/202185290, SPort 62581, TTL 0, Sinfo 3.0.0.0) 424192<=>238980 10.47.255.237:42332 6 (2->2) 10.101.102.279999 (Gen: 1, K(nh):24, Action:N(DPd), Flags:, TCP:SSrEEr, QOS:-1, S(nh):26, Stats:8067/419582, SPort 51018, TTL 0, Sinfo 10.169.25.20)
Fíjese primero – en el segundo movimiento de flujo para que el IPS tenga el mismo aspecto que el que acabamos de observar en la captura del lado del cliente. El tráfico aterriza la interfaz de estructura vRouter del nodo Pod del cliente remoto, a través del túnel de MPLSoUDP. El IP de destino y el puerto son servicio IP y puerto de servicio, respectivamente. Nada especial.
Sin embargo, la acción de flujo ahora está establecida en N (DPd), no F. Según las líneas de encabezado de la salida del comando de flujo, esto significa TDR o, en concreto, DNAT (traducción de direcciones de destino) con DPAT – (traducción de puertos de destino) tanto la dirección IP como el puerto de servicio se traducen en la IP y puerto del conjunto pod de back-end.
Ahora mire la primera entrada de flujo. La 10.47.255.238 IP de origen es la IP del pod de back-end y el puerto de origen es el puerto de servidor Python 90 abierto en el contenedor de back-end. Obviamente, se está devolviendo tráfico que indica que la descarga del archivo sigue estando en curso. La acción también es TDR (N), pero esta vez es el origen de la – operación inverso TDR (SNAT) y el origen Pat (Spat).
VRouter traducirá el puerto de’origen IP de origen del back-end a la dirección IP y al puerto de servicio, antes de colocarlos en el túnel MPLSoUDP y volver a devolver a la Pod del cliente en el nodo remoto.
El flujo completo de tráfico de extremo a extremo se ilustra en la Figure 11.
Servicio del equilibrador de carga Contrail
En el capítulo 3 se describe brevemente el servicio equilibrador de carga. Se mencionó que si el objetivo es exponer el servicio al mundo externo fuera del clúster, solo debe especificarse ServiceType como el LoadBalancer en el archivo YAML del servicio.
En Contrail, siempre que un servicio de tipo: Se crea LoadBalancer, no solo clusterIP será asignado ni expuesto a otros pods dentro del clúster, sino que también se asignará una IP flotante del grupo público de IP flotante a la instancia del equilibrador de carga como una dirección IP externa y se expondrá al mundo público fuera del clúster.
Aunque clusterIP sigue actuando como VIP del cliente dentro del clúster, la IP flotante o IP externa actuará esencialmente como una dirección VIP orientada a aquellos clientes que se encuentran fuera del clúster, por ejemplo, un host de Internet remoto que envía solicitudes al servicio a través del enrutador de la puerta de enlace.
En la siguiente sección se demuestra el modo en que el tipo de LoadBalancer de servicio funciona en nuestra configuración de extremo a extremo de la práctica, que incluye el clúster Kubernetes, el conmutador de estructuras, el enrutador de puerta de enlace y el host de Internet.
IP externa como IP flotante
Echemos’un vistazo al archivo YAML de un servicio de loadbalancer. Es’igual que el servicio clusterIP, excepto si solo hay una línea que declara el tipo de servicio:
#service-web-lb.yaml apiVersion: v1 kind: Service metadata: name: service-web-lb spec: ports: - port: 8888 targetPort: 80 selector: app: webserver type: LoadBalancer #<---
Crear y verificar el servicio:
$ kubectl apply -f service-web-lb.yaml service/service-web-lb created $ kubectl get svc -o wide NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR service-web-lb LoadBalancer 10.96.89.48 101.101.101.252 8888:32653/TCP 10s app=webserver
Compare el resultado con el tipo de servicio clusterIP, esta vez hay una dirección IP asignada en la columna de IP externa. Si recuerda lo que observamos’en la sección de Pool flotante de IP, debe comprender que esta IP externa es en realidad otra FIP, asignada desde el pool de FIP NS o el pool de FIP global. No se proporcionó información específica de grupo de IP flotante en el archivo YAML del objeto de servicio, de modo que se utilizará automáticamente el grupo de direcciones IP flotante adecuado.
Desde la UI puede ver que para el servicio loadbalancer ahora tenemos dos IP flotantes: una como clusterIP (VIP interna) y la otra como dirección IP externa (VIP externa), tal y como puede parecer en la Figure 12:
Ambas direcciones IP flotantes están asociadas a la interfaz Pod que se muestra en la siguiente captura de pantalla, Figure 13.
Amplíe la interfaz de punteo y verá dos direcciones IP flotantes en la lista fip_list:
Ahora debe comprender la única diferencia en este caso entre los dos tipos de servicios es que, para el servicio del equilibrador de carga, se asigna un FIP adicional desde el Grupo FIP público, que se anuncia en el enrutador de puerta de enlace y actúa como la dirección VIP de cara a la exterior. Así es cómo el servicio loadbalancer se expone a sí mismo al mundo exterior.
Tabla VRF de enrutadores de puerta de enlace
En la Contrail sección de IP flotante’, se aprendió cómo anunciar IP flotante. Pero ahora vamos’a revisar los conceptos principales para comprender cómo funciona en la implementación de servicios contrail.
La comunidad de destino de ruta en el PI IP VN lo hace accesible para el host de Internet, de manera que nuestro servicio también se expone ahora a Internet en lugar de a los pods dentro del clúster. Examinando el enrutador’de puerta de enlace s tabla VRF revela lo siguiente:
labroot@camaro> show route table k8s-test.inet.0 101.101.101/24 Jun 19 03:56:11 k8s-test.inet.0: 23 destinations, 40 routes (23 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 101.101.101.252/32 *[BGP/170] 00:01:11, MED 100, localpref 200, from 10.169.25.19 AS path: ?, validation-state: unverified > via gr-2/2/0.32771, Push 44
El enrutador de puerta de enlace conoce la ruta de host de IP – flotante del controlador de contrail más – específicamente, contrail nodo de control que actúa como un RR VPN de BGP MP estándar, que refleja las rutas entre los nodos de cómputo y el enrutador de la puerta de enlace. Otro punto de vista de la versión detallada de la misma ruta muestra más información acerca del proceso:
labroot@camaro> show route table k8s-test.inet.0 101.101.101/24 detail Jun 20 11:45:42 k8s-test.inet.0: 23 destinations, 41 routes (23 active, 0 holddown, 0 hidden) 101.101.101.252/32 (2 entries, 1 announced) *BGP Preference: 170/-201 Route Distinguisher: 10.169.25.20:9 ...... Source: 10.169.25.19 #<--- Next hop type: Router, Next hop index: 1266 Next hop: via gr-2/2/0.32771, selected #<--- Label operation: Push 44 Label TTL action: prop-ttl Load balance label: Label 44: None; ...... Protocol next hop: 10.169.25.21 #<--- Label operation: Push 44 Label TTL action: prop-ttl Load balance label: Label 44: None; Indirect next hop: 0x900c660 1048574 INH Session ID: 0x690 State: <Secondary Active Int Ext ProtectionCand> Local AS: 13979 Peer AS: 60100 Age: 10:15:38 Metric: 100 Metric2: 0 Validation State: unverified Task: BGP_60100_60100.10.169.25.19 Announcement bits (1): 1-KRT AS path: ? Communities: target:500:500 target:64512:8000016 ...... Import Accepted VPN Label: 44 Localpref: 200 Router ID: 10.169.25.19 Primary Routing Table bgp.l3vpn.0
Los puntos destacados de la salida son:
El origen indica de qué par BGP se ha aprendido la ruta, 10.169.25.19 es el controlador de Contrail (y Kubernetes Master) en’el libro s Lab.
El próximo salto de protocolo indica quién genera la ruta. Y 10.169.25.20 es el nodo cent222 donde se está ejecutando el conjunto Pod del servidor webback-end.
GR-2/2/0.32771 es una interfaz que representa el túnel GRE (MPLS a través de él) entre el enrutador de puerta de enlace y el nodo cent333.
Flujo de trabajo del servicio del equilibrador de carga
En Resumen, la dirección IP flotante se otorga al servicio, ya que su dirección IP externa se anuncia al enrutador de puerta de enlace y’se carga en la tabla VRF de los enrutadores. Cuando el host de Internet envía una solicitud a la dirección IP flotante a través del túnel MPLSoGRE, el enrutador de la puerta de enlace lo reenviará al nodo de computación donde se encuentra el conjunto pod de backend.
El flujo de paquetes se ilustra en la Figure 15.
A continuación, se muestra el artículo completo de la Figure 15:
Crear una agrupación de FIP a partir de una Public VN con Route-Target. El VN se anuncia al enrutador de puerta de enlace remoto a través de BGP MP.
Crear un conjunto Pod con una aplicación de etiquetas: WebServer y Kubernetes decide que la Pod se creará en el nodo cent333. El nodo publica la IP Pod a través del XMPP.
Crear un tipo de servicio loadbalancer con el puerto de servicio y la aplicación de selector de etiquetas = webserver. Kubernetes asigna una IP de servicio.
Kubernetes encuentra la caja Pod con la etiqueta coincidente y actualiza el extremo con la información de puerto o IP Pod.
Contrail crea una instancia de loadbalancer y le asigna una IP flotante. Contrail también asocia esa IP flotante a la interfaz del conjunto Pod, por lo que habrá una operación de uno a uno TDR entre la IP flotante y la IP del conjunto Pod.
Via XMPP, node cent333 anuncia esta dirección IP flotante a Contrail controladora cent111, que a su vez la anuncia al enrutador de la puerta de enlace.
Al recibir el prefijo IP flotante, el enrutador de puerta de enlace comprueba y ve que el RT’del prefijo coincide con lo que espera, e importará el prefijo en la tabla VRF local. En este momento, la puerta de enlace aprende el siguiente salto de la IP flotante es cent333, por lo que genera un túnel GRE suave hacia cent333.
Cuando el enrutador de la puerta de enlace ve una solicitud proveniente de Internet hacia la dirección IP flotante, enviará la solicitud al nodo cent333 a través del túnel de MPLS a través de GRE.
El vRouter del nodo ve los paquetes destinados a la dirección IP flotante, realizará TDR por lo que los paquetes se enviarán al conjunto pod de back-end adecuado.
Comprobar el servicio del equilibrador de carga
Para comprobar el acceso de extremo a extremo del servicio desde el host de Internet al Pod back’-end, deje que inicie sesión en el escritorio del host de Internet e inicie un explorador, con la dirección URL que señala a http://101.101.101.252:8888.
Tenga en cuenta que la solicitud de host de Internet debe enviarse a la dirección IP flotante pública, no a la IP de servicio (clusterIP) ni a la IP del conjunto pod de back-end, a la que solo se puede llegar desde dentro del clúster.
En la Figure 16puede ver la página web devuelta en el explorador que se muestra a continuación.
Este manual’s ha instalado un escritorio de la manedición como un host de Internet. 0
Para simplificar la prueba, también puede ejecutar el SSH en el host de Internet y probarlo con la herramienta doblez:
[root@cent-client ~]# curl http://101.101.101.252:8888 | w3m -T text/html | cat Hello This page is served by a Contrail pod IP address = 10.47.255.238 Hostname = webserver-846c9ccb8b-vl6zs
¡ Y el servicio Kubernetes está disponible en Internet!
ECMP de servicio del equilibrador de carga
Ha’visto cómo el tipo de equilibrador de carga de servicio se expone a Internet y cómo la IP flotante fue la baza. En la sección servicio clusterIP,’ve también cómo funciona el equilibrador de carga del servicio ECMP. Pero lo que usted’Haven a ver aún es cómo el procesamiento de ECMP funciona en el tipo de equilibrador de carga de servicio. Para demostrar que de nuevo hemos escalado el RC para que genere un conjunto pod de back-end más detrás del servicio:
$ kubectl scale deployment webserver --replicas=2 deployment.extensions/webserver scaled $ kubectl get pod -l app=webserver -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE webserver-846c9ccb8b-r9zdt 1/1 Running 0 25m 10.47.255.238 cent333 <none> webserver-846c9ccb8b-xkjpw 1/1 Running 0 23s 10.47.255.236 cent222 <none>
Aquí’la pregunta es: con dos pods en diferentes nodos, y ambos como back-end ahora, desde la’perspectiva de enrutadores de puerta de enlace, cuando recibe la solicitud de servicio, ¿a qué nodo elige elegir reenviar el tráfico?
Deje’que se vuelva a comprobar’el enrutador de la puerta de enlace de la tabla VRF:
labroot@camaro> show route table k8s-test.inet.0 101.101.101.252/32 Jun 30 00:27:03 k8s-test.inet.0: 24 destinations, 46 routes (24 active, 0 holddown, 0 hidden) @ = Routing Use Only, # = Forwarding Use Only + = Active Route, - = Last Active, * = Both 101.101.101.252/32 *[BGP/170] 00:00:25, MED 100, localpref 200, from 10.169.25.19 AS path: ? validation-state: unverified, > via gr-2/3/0.32771, Push 26 [BGP/170] 00:00:25, MED 100, localpref 200, from 10.169.25.19 AS path: ? validation-state: unverified, > via gr-2/2/0.32771, Push 26
Se importa el mismo prefijo IP flotante, tal’y como se ha visto en el ejemplo anterior, con la excepción de que ahora se ha aprendido la misma ruta dos veces y se ha creado un túnel MPLSoGRE adicional. Anteriormente, en el ejemplo de servicio clusterIP, la opción detail se usaba en el comando show Route para encontrar los puntos de conexión de túnel. En esta ocasión, examinamos la interfaz gr + de GRE suave para encontrar el mismo:
labroot@camaro> show interfaces gr-2/2/0.32771 Jun 30 00:56:01 Logical interface gr-2/2/0.32771 (Index 392) (SNMP ifIndex 1801) Flags: Up Point-To-Point SNMP-Traps 0x4000 IP-Header 10.169.25.21:192.168.0.204:47:df:64:0000000800000000 #<--- Encapsulation: GRE-NULL Copy-tos-to-outer-ip-header: Off, Copy-tos-to-outer-ip-header-transit: Off Gre keepalives configured: Off, Gre keepalives adjacency state: down Input packets : 0 Output packets: 0 Protocol inet, MTU: 9142 Max nh cache: 0, New hold nh limit: 0, Curr nh cnt: 0, Curr new hold cnt: 0, NH drop cnt: 0 Flags: None Protocol mpls, MTU: 9130, Maximum labels: 3 Flags: None labroot@camaro> show interfaces gr-2/3/0.32771 Logical interface gr-2/3/0.32771 (Index 393) (SNMP ifIndex 1703) Flags: Up Point-To-Point SNMP-Traps 0x4000 IP-Header 10.169.25.20:192.168.0.204:47:df:64:0000000800000000 #<--- Encapsulation: GRE-NULL Copy-tos-to-outer-ip-header: Off, Copy-tos-to-outer-ip-header-transit: Off Gre keepalives configured: Off, Gre keepalives adjacency state: down Input packets : 11 Output packets: 11 Protocol inet, MTU: 9142 Max nh cache: 0, New hold nh limit: 0, Curr nh cnt: 0, Curr new hold cnt: 0, NH drop cnt: 0 Flags: None Protocol mpls, MTU: 9130, Maximum labels: 3 Flags: None
El encabezado IP de la interfaz gr indica los dos puntos finales del túnel GRE:
10.169.25.20:192.168.0.204: En este caso, el túnel se encuentra entre cent222 de nodo y el enrutador de puerta de enlace.
10.169.25.21:192.168.0.204: Aquí el túnel se encuentra entre cent333 de nodo y el enrutador de puerta de enlace
Acabamos necesitando dos túneles en el enrutador de puerta de enlace, cada uno de los cuales apunta a un nodo distinto en el que se ejecuta un conjunto pod de back-end. Ahora creemos que el enrutador realizará equilibrio de carga ECMP entre los dos GRE Tun-Nels, cada vez que obtenga una solicitud de servicio hacia la misma IP flotante. Deje’que el s revise.
Comprobar la ECMP del servicio de equilibrador de carga
Para comprobarlo’ECMP, solo tiene que extraer la página unas veces más y es posible que vea que ambas direcciones IP Pod se muestran finalmente.
¡ Esto no ocurre nunca!
[root@cent-client ~]# curl http://101.101.101.252:8888 | lynx -stdin --dump Hello This page is served by a Contrail pod IP address = 10.47.255.236 Hostname = webserver-846c9ccb8b-xkjpw
Lynx es otro navegador web de terminal similar al programa w3m que utilizamos anteriormente.
La única página web procede del primer pod de back-end 10.47.255.236, WebServer-846c9ccb8b-xkjpw, que se ejecuta en el nodo cent222. El otro no aparece nunca. Por lo tanto, la ECMP esperada no se produce todavía. Pero cuando se examinan las rutas con la palabra clave Detail o extensa’, se puede encontrar la causa raíz:
labroot@camaro> show route table k8s-test.inet.0 101.101.101.252/32 detail | match state Jun 30 00:48:29 State: <Secondary Active Int Ext ProtectionCand> Validation State: unverified State: <Secondary NotBest Int Ext ProtectionCand> Validation State: unverified
Esto revela que aunque el enrutador haya aprendido el mismo prefijo de ambos nodos, solo uno está activo y’el otro ha ganado efecto porque es NotBest. Por lo tanto, la segunda ruta y la interfaz GRE correspondiente gr-2/2/0.32771 nunca se cargarán en la tabla de reenvío:
labroot@camaro> show route forwarding-table table k8s-test destination 101.101.101.252 Jun 30 00:53:12 Routing table: k8s-test.inet Internet: Enabled protocols: Bridging, All VLANs, Destination Type RtRef Next hop Type Index NhRef Netif 101.101.101.252/32 user 0 indr 1048597 2 Push 26 1272 2 gr-2/3/0.32771
Esta es la Junos predeterminada, BGP comportamiento de selección de rutas de acceso, pero una descripción detallada de eso no está en el ámbito de este libro.
Para obtener el algoritmo de selección de ruta Junos BGP, vaya a la Juniper TechLibrary: https://www. juniper.net/documentation/en_US/junos/topics/topic-map/bgp-path-selection.html.
La solución consiste en habilitar el tirador VPN de varios paths-no igual costo en la tabla VRF:
labroot@camaro# set routing-instances k8s-test routing-options multipath vpn-unequal-cost
Ahora,’deje que s vuelva a comprobar la tabla VRF:
labroot@camaro# run show route table k8s-test.inet.0 101.101.101.252/32 Jun 26 20:09:21 k8s-test.inet.0: 27 destinations, 54 routes (27 active, 0 holddown, 0 hidden) @ = Routing Use Only, # = Forwarding Use Only + = Active Route, - = Last Active, * = Both 101.101.101.252/32 @[BGP/170] 00:00:04, MED 100, localpref 200, from 10.169.25.19 AS path: ? validation-state: unverified, > via gr-2/3/0.32771, Push 72 [BGP/170] 00:00:52, MED 100, localpref 200, from 10.169.25.19 AS path: ? validation-state: unverified, > via gr-2/2/0.32771, Push 52 #[Multipath/255] 00:00:04, metric 100, metric2 0 via gr-2/3/0.32771, Push 72 > via gr-2/2/0.32771, Push 52
Se agregará una ruta múltiple con ambas interfaces GRE bajo el prefijo IP flotante y la tabla de reenvío reflejará la misma:
labroot@camaro> show route forwarding-table table k8s-test destination 101.101.101.252 Jun 30 01:12:36 Routing table: k8s-test.inet Internet: Enabled protocols: Bridging, All VLANs, Destination Type RtRef Next hop Type Index NhRef Netif 101.101.101.252/32 user 0 ulst 1048601 2 indr 1048597 2 Push 26 1272 2 gr-2/3/0.32771 indr 1048600 2 Push 26 1277 2 gr-2/2/0.32771
Ahora, intente extraer varias veces la página web desde el host de Internet con rizo o con un explorador Web’y podrá ver el resultado – aleatorio que ambos conjuntos de los backends reciben la solicitud y las respuestas:
[root@cent-client ~]# curl http://101.101.101.252:8888 | lynx -stdin --dump Hello This page is served by a Contrail pod IP address = 10.47.255.236 Hostname = webserver-846c9ccb8b-xkjpw [root@cent-client ~]# curl http://101.101.101.252:8888 | lynx -stdin --dump Hello This page is served by a Contrail pod IP address = 10.47.255.238 Hostname = webserver-846c9ccb8b-r9zdt
El flujo de paquetes de extremo a extremo se ilustra en la Figure 17.
