¡Lanzamiento de OpenNJet KIC V2.0!

[Shenzhen] Yuanchuanghui: 17.26, el salón de fiestas te está esperando”.

NGINX evoluciona hacia la nube nativa, todo en OpenNJet

Descripción general

OpenNJet KIC (Kubernetes Ingress Controller) se basa en las características dinámicas y la implementación de alto rendimiento del proxy OpenNJet. Compense las deficiencias de nginx en escenarios nativos de la nube. Proporciona capacidades avanzadas de gestión del tráfico, como ubicación dinámica, enrutamiento de host/ruta, equilibrio de carga, flujo ascendente dinámico, publicación canary, terminación TLS/SNI, TCP/UDP, WebSocket, etc.

Características principales de esta versión:

Admite procesamiento de fragmentación Ingress/VS CR
Integración de soporte con ADC
Admite operaciones de encabezado HTTP
Admite proxy TCP
Soporte de espacio de nombres cruzado
Admite proxy WebSocket
Admite proxy UDP
Soporte dinámico NJet VS/Accesslog
Admite verificación de estado activo de TCP
Apoyar el ajuste dinámico del número de procesos de trabajo.

Este artículo proporciona una breve introducción a estas nuevas características.

El diagrama de arquitectura es el siguiente:

Descripción general de las nuevas funciones

Procesamiento de fragmentación Ingress/VS CR

Hay KIC especiales para procesar diferentes recursos de Ingress/VS. Este es el mecanismo de fragmentación de KIC.

Los diferentes recursos de Ingress/VS se identifican mediante ingressClass. Los recursos de Ingress se pueden identificar mediante la anotación kubernetes.io/ingress.class o spec.ingressClassName, y los recursos de VS se pueden identificar mediante spec.ingressClassName.

Tenga en cuenta que cada KIC en este mecanismo de fragmentación se denomina tipo de KIC y corresponde a IngressClass uno a uno. En un clúster k8s, si hay varios KIC de Njet, es necesario crear varios objetos IngressClass. Cada tipo de KIC puede tener múltiples copias (correspondientes a múltiples pods en la arquitectura k8s).

El mecanismo de fragmentación hace que cada KIC tenga sus propios recursos de Ingress/VS que le interesan, en lugar de todos los recursos de Ingress/VS en el clúster k8s. Su objetivo es resolver el problema de que un solo tipo de KIC no puede soportar la presión de una configuración completa.

Integrar con ADC

Una vez que KIC se integra con ADC, ADC puede servir como LB frontal de KIC, administrando el tráfico del cliente a través de ADC y, en última instancia, equilibrando la carga con los servicios de KIC. KIC ha cumplido las siguientes funciones:

Registro de nombre de dominio ADC: KIC registra con ADC los nombres de dominio de los servicios en el clúster k8s administrado por KIC, como los servicios administrados a través de k8s ingress y vs CR. Esta función permite a los clientes realizar solicitudes directamente a través de nombres de dominio (el servidor DNS del ADC debe configurarse como el servidor DNS predeterminado).
Registro de ADC SlbPool: KIC registra el grupo de aplicaciones (nodeIP+nodePort) asociado con el servicio KIC con ADC. Esta función permite que ADC enrute al servicio KIC.
Registro de ADC VS: KIC registra un VS con ADC y lo asocia con el grupo de aplicaciones creado en el segundo paso. Esta función permite al cliente acceder directamente al VS, de modo que ADC pueda servir como el LB frontal de KIC.

El VIP en ADC VS corresponde al nombre de dominio del servicio gestionado por KIC.
El VIP en ADC VS es una IP de red pública a la que pueden acceder directamente clientes externos.

Estructura general

Gráfico de escena:

Diagrama de arquitectura de interacción:

Manipulación del encabezado HTTP

La operación del encabezado OpenNJet KIC puede modificar el encabezado de solicitud del cliente y operar en el encabezado de respuesta del servicio proxy. Incluyendo encabezados definidos por el usuario y encabezados definidos en la especificación HTTP.

proxy TCP

El proxy KIC TCP puede representar servicios TCP ascendentes. El proxy TCP proporciona capacidades de equilibrio de carga. El proxy TCP se implementa de forma totalmente dinámica y no requiere que OpenNJet realice una operación de recarga.

El servicio TCP proxy tendrá su propio puerto de escucha. Cuantos más servicios proxy, más puertos deben escucharse. En la implementación tradicional de Nginx, cada nueva escucha requiere una configuración de recarga. Para resolver el problema de recarga, utilizamos el reenvío de puertos. El método implementa el proxy del servicio TCP. El diseño específico es el siguiente:

La configuración de transmisión de OpenNJet escucha previamente un puerto 12003 (el puerto monitoreado por el servicio TCP proxy será redirigido a 12003).
KIC genera reglas de iptables a través de la API definida por el cliente y redirige el puerto de servicio TCP solicitado al puerto 12003 a través de las reglas de iptables.
El "puerto de servicio TCP" al que accede la transmisión OpenNJet a través del cliente coincide con el flujo ascendente configurado por el cliente de antemano a través de la API. Este proceso se compara a través del mapa de corrientes.
La transmisión OpenNJet envía la solicitud del cliente al servidor en el sentido ascendente que coincide con éxito (el equilibrio de carga se implementa mediante la transmisión lua).

Las reglas de iptables y las actualizaciones de contenido de mapas se actualizan dinámicamente mediante API, evitando operaciones de recarga.

La configuración de OpenNJet se implementa de la siguiente manera:

 map $njtmesh_port \$stream_upstream {
 }
 
 server {
 listen 12003 mesh;
 set $proxy_upstream_name \$stream_upstream;
 proxy_pass upstream_balancer;
 }

El puerto solicitado por el cliente es siempre el puerto del oyente en TransportServer.
El servicio proxy no puede utilizar el puerto porque KIC lo utilizará internamente. La descripción se describe en la siguiente tabla:

puerto	ilustrar
80	proxy http
443	proxy https
12001	Plano de control OpenNJet
12002	tcp lua aguas arriba
12003	Puerto proxy TCP
12004	Puerto proxy UDP
8080	stub_status y http lua en sentido ascendente
8081	Puerto de preparación del pod KIC

A través de espacios de nombres

El Ingress integrado de K8 solo puede manejar el enrutamiento de servicios en el mismo ns y no puede realizar operaciones entre ns. La función de configuración entre espacios de nombres resuelve esta limitación.

Además de que Ingress admite la configuración entre espacios de nombres, VS también admite la configuración entre ns. Los usuarios pueden elegir según sus propias circunstancias.

Ingress implementa esta función a través de diferentes tipos de Ingress. Ingress en sí no tiene concepto de tipo. Lo expresamos agregando la anotación "njet.org.cn/mergeable-ingress-type". Las anotaciones pueden tomar valores de la siguiente tabla:

valor	ilustrar	Observación
maestro	Entrada principal	uno
esbirro	DesdeIngreso	Puede ser múltiple, asociado con el ingreso maestro a través del host

El maestro y el subordinado del mismo host pueden estar en el mismo ns o en ns diferentes.

Además de la configuración cross-ns, puede elegir esta función. Cuando un host tiene una gran cantidad de rutas y el mantenimiento de un único Ingress es complicado, también puede elegir esta función para administrar rutas.

VS CR tiene la misma función que Ingress, pero el método de implementación es diferente. VS CR realiza la configuración cross-ns haciendo referencia a un recurso de subruta. La subruta es una cadena en formato ns/name, que se utiliza para representar VSR. recursos VSR es un K8s CR, un nuevo CR introducido para esta característica.

Proxy WebSocket

WebSocket es un protocolo de capa de aplicación independiente basado en TCP y un protocolo de comunicación full-duplex. Su única relación con HTTP es que el servidor HTTP interpreta su protocolo de enlace como una solicitud de actualización HTTP. Cuando finaliza el protocolo de enlace, no tiene nada que ver con HTTP. El protocolo consta de dos partes: protocolo de enlace y transferencia de datos. La fase de apretón de manos se muestra en la siguiente figura:

Ingress implementa esta función agregando anotaciones, que expresamos agregando la anotación "njet.org.cn/websocket-services".

Nombre de la anotación	formato de valor	describir
njet.org.cn/websocket-services	servicio, servicio2 (nombres de servicio separados por comas)	Soporte websocket

VS no requiere ninguna configuración.

proxy UDP

El proxy KIC UDP puede representar servicios UDP ascendentes. El proxy UDP proporciona capacidades de equilibrio de carga. El proxy UDP está implementado de forma totalmente dinámica y no requiere que OpenNJet realice una operación de recarga.

La implementación del proxy del servicio UDP es básicamente la misma que la del proxy del servicio TCP, excepto que la configuración de flujo OpenNJet escucha previamente un puerto 12004 (el puerto monitoreado por el servicio UDP proxy será redirigido a 12004), mientras que TCP escucha previamente un puerto 12003. Para obtener instrucciones detalladas, consulte Proxy TCP.

La configuración de OpenNJet se implementa de la siguiente manera:

map $njtmesh_port \$stream_upstream_udp {
}

server {
listen 12004 udp mesh;
set $proxy_upstream_name $stream_upstream_udp;
proxy_pass upstream_balancer;
}

NJet dinámico VS

En comparación con la primera versión, cambiamos el enfoque de servidor único y ubicación múltiple para lograr la coincidencia del encabezado del host HTTP y la coincidencia de ruta al enfoque de servidor múltiple y ubicación múltiple. Usamos el nombre_servidor estándar de nginx para implementar la coincidencia del encabezado del host, pero. actualizó dinámicamente la configuración. Sí, no se requiere ninguna operación de recarga. La segunda versión no agrega funciones adicionales para Ingress y VirtualServer.

Registro de acceso dinámico

La función KIC Accesslog le permite aplicar políticas de registro de acceso (incluido el estado del interruptor y la ruta del archivo de registro de acceso) individualmente a una determinada aplicación. La configuración global también se puede realizar a través de njet-config ConfigMap, pero "aplicar la política de registro de acceso individualmente a una aplicación" tiene mayor prioridad.

Comprobación de estado proactiva de TCP

Para los recursos del servidor de transporte, se admite la configuración de un puerto TCP. La verificación de estado activa detectará si el puerto TCP está escuchando normalmente de acuerdo con el intervalo de verificación configurado, y el backend estará en línea y fuera de línea según los resultados de la verificación.

apiVersion: k8s.njet.org/v1alpha1
 kind: TransportServer
 metadata:
 name: testapp-tcp
 spec:
 listener:
 name: test-tcp
 protocol: TCP
 upstreams:
 - name: testapp1
 service: testapp
 port: 80
 healthCheck:
 enable: true
 interval: 20s
 timeout: 5s
 fails: 1
 passes: 1
 port: 83
 action:
 pass: testapp1

Las instrucciones de configuración son las siguientes:

Campo	describir	tipo	¿Es necesario?
permitir	Si se debe habilitar la verificación de estado, por defecto es falso	booleano	No
intervalo	El intervalo entre controles. El valor predeterminado es 5	cadena	No
falla	Después de algunos fallos, se le considerará desconectado. Predeterminado 1 vez	entero	No
pasa	Se considerará online después de varios éxitos. Predeterminado 1 vez	entero	No
puerto	El puerto donde se encuentra el servicio de control sanitario.	entero	No
se acabó el tiempo	Tiempo de espera de conexión de verificación de estado	cadena	No

Ajuste dinámico del número de procesos de trabajo

Admite la configuración de la cantidad de procesos de trabajo de instancias de njet a través de los recursos de ConfigMap. Después de actualizar los elementos de configuración en ConfigMap, la cantidad de procesos de trabajo se modificará dinámicamente.

Elementos de configuración	ilustrar	Tipo de campo	valor por defecto	Observación
procesos de trabajo	Número de procesos de trabajo (valores permitidos 1 - 512)	Cadena	El valor predeterminado es la cantidad de procesos generados automáticamente según la cantidad de núcleos de CPU.

Link de referencia

Manual de usuario de OpenNJetKIC

Dirección del código fuente OpenNJet KIC

El motor de aplicaciones NJet logra capacidades únicas de carga de configuración dinámica en tiempo de ejecución a través de la reconstrucción del kernel y es una nueva generación de motores de aplicaciones web de alto rendimiento . NJet tiene capacidades de procesamiento de planos de datos de alto rendimiento y programa múltiples funciones auxiliares, como agrupación en clústeres, alta disponibilidad, comprobaciones de estado activas y API declarativas a través del marco de servicio CoPilot exclusivo de NJet para facilitar la expansión de funciones y aislar los pares de funciones de gestión/control. Además del impacto en el plano de datos, el rendimiento del motor de aplicaciones NJet supera tres veces el del motor de aplicaciones Envoy recomendado por CNCF. Sitio web oficial del grupo de correo.