Descripción de entrada

Por qué necesitamos entradas

Un Service se utiliza generalmente para reenviar solicitudes de acceso basadas en TCP y UDP y proporcionar balanceo de carga de capa 4 para clústeres. Sin embargo, en escenarios reales, si hay un gran número de solicitudes de acceso HTTP/HTTPS en la capa de aplicación, el Service no puede cumplir con los requisitos de reenvío. Por lo tanto, el clúster de Kubernetes proporciona un modo de acceso basado en HTTP, es decir, entrada.

Una entrada es un recurso independiente en el clúster de Kubernetes y define reglas para reenviar el tráfico de acceso externo. Como se muestra en Figura 1, puede personalizar las reglas de reenvío basadas en nombres de dominio y URL para implementar una distribución detallada del tráfico de acceso.

Figura 1 Diagrama de entrada

A continuación se describen las definiciones relacionadas con la entrada:

• Objeto de entrada: un conjunto de reglas de acceso que reenvía solicitudes a los servicios especificados en función de nombres de dominio o direcciones URL. Puede agregarse, eliminarse, modificarse y consultarse invocando a las API.
• Ingress Controller: un ejecutor para el reenvío de solicitudes. Supervisa los cambios de objetos de recursos como entradas, Services, puntos de conexión, secretos (principalmente certificados y claves TLS), nodos y ConfigMaps en tiempo real, analiza las reglas definidas por entradas, y reenvía solicitudes a los Services de backend correspondientes.

Los Ingress Controllers proporcionados por diferentes proveedores se implementan de diferentes maneras. Basado en los tipos de balanceadores de carga, Ingress Controllers se clasifican en ELB Ingress Controller y Nginx Ingress Controller. Ambos son compatibles con CCE. ELB Ingress Controller reenvía el tráfico con ELB. Nginx Ingress Controller utiliza las plantillas e imágenes mantenidas por la comunidad de Kubernetes para reenviar el tráfico a través del componente de Nginx.

Comparación de características de entrada

ELB Ingress es esencialmente diferente del Nginx Ingress de código abierto. Por lo tanto, sus tipos de Service soportados también son diferentes.

ELB Ingress Controller se despliega en un nodo principal. Todas las políticas y comportamientos de reenvío se configuran en el lado de ELB. Los balanceadores de carga fuera del clúster solo pueden conectarse a los nodos del clúster con la dirección IP de VPC en escenarios de redes sin paso. Por lo tanto, ELB Ingress solo admite los Services de NodePort. Sin embargo, en el escenario de redes de paso (cluster de Turbo de CCE + balanceador de carga dedicado), ELB puede reenviar directamente el tráfico a los pods del clúster. En este caso, además de los Services de NodePort, la entrada también puede interconectarse con los Services de ClusterIP.

Nginx Ingress Controller se ejecuta en un clúster y se expone como un Service con NodePort. El tráfico se reenvía a otros Services en el clúster con Nginx-ingress. El comportamiento de reenvío de tráfico y el objeto de reenvío están en el clúster. Por lo tanto, se admiten los Services de ClusterIP y de NodePort.

En conclusión, ELB Ingress utiliza balanceadores de carga de nivel empresarial para reenviar el tráfico y ofrece un alto rendimiento y estabilidad. Nginx Ingress Controller se despliega en nodos de clúster, que consume recursos de clúster, pero tiene mejor capacidad de configuración.

Principio de funcionamiento del ELB Ingress Controller

ELB Ingress Controller desarrollado por CCE implementa el acceso a la red de capa 7 para Internet e Intranet (en la misma VPC) basado en ELB y distribuye el tráfico de acceso a los Services correspondientes usando diferentes URLs.

ELB Ingress Controller se despliega en el nodo principal y se vincula al balanceador de carga en la VPC donde reside el clúster. Se pueden configurar diferentes nombres de dominio, puertos y políticas de reenvío para el mismo balanceador de carga (con la misma dirección IP). Figura 2 muestra el principio de funcionamiento del ELB Ingress Controller.

1. Un usuario crea un objeto de ingreso y configura una regla de acceso de tráfico en el ingreso, incluidos el balanceador de carga, el URL, SSL y el puerto de servicio de backend.
2. Cuando Ingress Controller detecta que el objeto de entrada cambia, reconfigura el oyente y la ruta de servidor backend en el lado de ELB según la regla de acceso de tráfico.
3. Cuando un usuario accede a una carga de trabajo, el tráfico se reenvía al puerto de Service backend correspondiente basándose en la política de reenvío configurada en ELB y, a continuación, se reenvía a cada carga de trabajo asociada a través del Service.

Figura 2 Principio de funcionamiento del ELB Ingress Controller

Principio de funcionamiento del Nginx Ingress Controller

Una entrada de Nginx utiliza ELB como entrada de tráfico. El complemento nginx-ingress se despliega en un clúster para equilibrar el tráfico y controlar el acceso.

El complemento de nginx-ingress en CCE se implementa usando el gráfico y la imagen de comunidad de código abierto. CCE no mantiene el complemento. Por lo tanto, no se recomienda que el complemento de nginx-ingress se use comercialmente.

Puede visitar la comunidad de código abierto para obtener más información.

Nginx Ingress Controller se despliega en los nodos de trabajo con pods, lo que resultará en costos de operación y gastos generales de ejecución del componente de Nginx. Figura 3 muestra los principios de funcionamiento de Nginx Ingress Controller.

1. Después de actualizar los recursos de ingreso, Nginx Ingress Controller escribe una regla de reenvío definida en los recursos de ingreso en el archivo de configuración nginx.conf de Nginx.
2. El componente de Nginx integrado recarga el archivo de configuración actualizado para modificar y actualizar la regla de reenvío de Nginx.
3. Cuando el tráfico accede a un clúster, el balanceador de carga creado primero reenvía el tráfico al componente de Nginx en el clúster. A continuación, el componente de Nginx reenvía el tráfico a cada carga de trabajo basándose en la regla de reenvío.

Figura 3 Principio de funcionamiento del Nginx Ingress Controller