Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Servicio Contrail

 

El capítulo 3 introdujo’ Kubernetes implementación predeterminada del servicio a través de Kube-proxy. En el capítulo 3, mencionamos que los proveedores CNI pueden tener sus propias implementaciones. Bien, en Contrail, el servicio nodePort lo implementa Kube-proxy. Sin embargo, los servicios clusterIP y loadbalancer son implementados por Contrail’s LOADBALANCER (lb).

Antes de profundizar en los detalles del servicio Kubernetes en Contrail’, deje que se revise el concepto heredado de equilibrador de carga basado en OpenStack en contrail.

Tip

Para mayor brevedad, a veces el loadbalancer también se conoce como LB.

Equilibrador de carga de Contrail OpenStack

Contrail equilibrador de carga es una característica de Foundation que se admite desde su primera versión. Permite crear un grupo de máquinas virtuales que atienden aplicaciones, compartiendo una virtual-IP (VIP) como la dirección IP de front-end hacia los clientes. Figure 1 ilustra contrail equilibrador de carga y sus componentes.

Figure 1: Equilibrador de carga de Contrail OpenStack
Equilibrador de carga de Contrail OpenStack

Algunos aspectos destacados del Figure 1 son:

  • El LB se creó con una VIP interna 30.1.1.1. También se crea una escucha LB para cada puerto de escucha.

  • Juntos, todas las máquinas virtuales de back-end componen un grupo que se encuentra en la subred 30.1.1.0’/24, lo mismo que la dirección VIP interna de lb s.

  • A cada VM back-end de la agrupación, también denominada miembro, se le asigna una dirección IP de la subred del grupo 30.1.1.0/24.

  • Para exponer el LB al mundo exterior, se le ha asignado otra VIP, que es una VIP externa 20.1.1.1.

  • Un cliente solo ve una dirección VIP externa 20.1.1.1, que representa todo el servicio.

  • Cuando LB detecta una solicitud proveniente del cliente, realiza el proxy de la conexión TCP. Esto significa que establece la conexión TCP con el cliente, extrae las’solicitudes http/https del cliente, crea una nueva conexión TCP a una de las máquinas virtuales del back-end desde la agrupación y envía la solicitud a la nueva conexión TCP.

  • Cuando LB obtiene su respuesta de la máquina virtual, reenvía la respuesta al cliente.

  • Y cuando el cliente cierra la conexión a las LB, el LB también puede cerrar su conexión con la VM back-end.

Tip

Cuando el cliente cierra su conexión con las LB, es posible que la LB o no cierre su conexión con la VM back-end. Dependiendo del rendimiento o de otras consideraciones, puede que utilice un tiempo de espera antes de anular la sesión.

Puede ver que este modelo de equilibrador de carga es muy similar al concepto de servicio Kubernetes:

  • VIP es la IP de servicio.

  • la VM back-end se convierte en pods backend.

  • Kubernetes se agrega a los miembros en lugar de a OpenStack.

De hecho, Contrail vuelve a usar una buena parte de este modelo en su implementación del servicio Kubernetes. Para admitir el equilibrio de la carga en el servicio, Contrail extiende el equilibrador de carga con un controlador nuevo. Junto con el controlador, el servicio se implementará como un equilibrador de carga de ruta múltiple de costos iguales (ECMP) que funciona en la capa 4 (capa de transporte). Ésta es la diferencia principal cuando se compara con el modo proxy usado por el tipo de equilibrador de carga OpenStack.

  • En realidad, cualquier equilibrador de carga se puede integrar con Contrail a través de la Contrail componente Conrail-SVC-monitor.

  • Cada equilibrador de carga tiene un controlador de equilibrador de carga registrado para Contrail con un tipo de loadbalancer_provider.

  • Contrail-SVC-monitor escucha a Contrail objetos loadbalancer, Listener, Listen, pool y Member. También llama al controlador del equilibrador de carga registrado para llevar a cabo otros trabajos necesarios según el tipo de loadbalancer_provider.

  • Contrail proporciona de forma predeterminada equilibrador de carga ECMP (loadbalancer_provider es nativo) y equilibrador de carga HAProxy (loadbalancer_provider es opencontrail).

  • El equilibrador de carga OpenStack está usando HAProxy equilibrador de carga.

  • Por otro lado, la entrada es conceptualmente más cercana al equilibrador de carga OpenStack, en el sentido de que ambos son basados en el proxy de capa 7 (Capa de aplicación). Más información sobre la entrada se tratará en secciones posteriores.