Implementación del controlador de ingreso NGINX en Amazon EKS: Cómo hicimos la prueba

En NGINX buscamos constantemente formas de ayudarle a aprovechar al máximo nuestro software. Nuestros informes de soluciones y guías de dimensionamiento son un recurso importante que brindamos: al probar empíricamente el rendimiento que puede esperar en diferentes niveles de potencia informática, lo ayudamos a maximizar el rendimiento de entrega de aplicação con la infraestructura que ya tiene y a determinar gastos operativos precisos para el rendimiento y la escala para los que se está preparando.

Recientemente actualizamos el resumen de la solución NGINX Ingress Controller con pautas de tamaño para Amazon Elastic Kubernetes Service (EKS). El resumen describe el rendimiento que puede esperar lograr con el controlador de ingreso NGINX ejecutándose en varios tipos de instancias en Amazon EKS, junto con el costo total de propiedad (TCO) mensual estimado. En este blog, explicamos cómo obtuvimos esos números, incluida toda la información que necesita para realizar sus propias pruebas similares.

Topología

El siguiente diagrama muestra la topología utilizada para la prueba.

• El administrador es el usuario que realiza las pruebas ejecutando los comandos especificados en las siguientes secciones.
• Amazon ECR (Elastic Container Registry) aloja la imagen Docker oficial del controlador de ingreso NGINX Plus utilizada en las pruebas. Consulte Implementación del controlador de ingreso NGINX Plus .
• Amazon EC2 (Elastic Compute Cloud) aloja la imagen c5n.9xlarge donde se ejecuta wrk y genera las solicitudes. Ver Metodología de pruebas .
• Amazon EKS (Elastic Kubernetes Service) aloja las imágenes c5n.9xlarge para el controlador de ingreso NGINX Plus y la aplicação backend. Consulte Creación del clúster de Amazon EKS .
• El controlador de ingreso NGINX Plus envía las solicitudes generadas por wrk a la aplicação backend y devuelve las respuestas de la aplicación. Consulte Implementación del controlador de ingreso NGINX Plus .
• La aplicação backend responde a las solicitudes enviadas por proxy mediante NGINX. Consulte Implementación de pods backend .

Creación del clúster de Amazon EKS

Antes de implementar el clúster EKS, realice estos pasos en la máquina local, que está representada por el ícono de administrador en el diagrama:

1. Descargue eksctl , la interfaz de línea de comandos oficial para Amazon EKS. Si ya tiene eksctl instalado en su máquina, asegúrese de actualizarlo a la última versión.
2. Agregue las credenciales de administrador de AWS adecuadas al archivo ${HOME}/.aws/credentials .
3. Descargue los archivos YAML para este blog desde nuestro repositorio Gist.
4. Descargue rbac.yaml (o ap-rbac.yaml si está usando NGINX App Protect) del repositorio NGINX Ingress Controller en GitHub.

Para implementar el clúster EKS, ejecute el siguiente comando eksctl en la máquina local. (Se omite el indicador --nodes porque, de manera predeterminada, el comando crea los dos nodos necesarios para la prueba: uno para el controlador de ingreso NGINX Plus y otro para la aplicação base del backend).

Nota: Puede implementar el clúster EKS en cualquier región que no sea us-west-1 . La suscripción a la imagen del controlador de ingreso NGINX Plus en Amazon Marketplace for Containers (consulte la siguiente sección ) no es compatible en esa región.

# eksctl crear clúster --instance-types=c5n.9xlarge --managed --ssh-access=true --ssh-public-key=/ruta/a/clave-pública

Para conectarse a un nodo de clúster a través de SSH, ejecute este comando. Durante la prueba, debe conectarse al nodo controlador de ingreso NGINX Plus para ejecutar el comando htop y verificar que la carga del cliente wrk sea suficiente para llevar el uso de la CPU en el nodo al 100%.

# ssh -i /ruta/a/clave-privada ec2-user@< dirección-IP-pública-del-nodo-EKS >

Implementación del controlador de ingreso NGINX Plus

Implementar el controlador de ingreso NGINX Plus en Amazon EKS ahora es más fácil que nunca.

1. Cree un proveedor de identidad (IdP) OIDC para su clúster EKS.

   # eksctl utils associate-iam-oidc-provider --region=< región-clúster-eks > --cluster=< nombre-clúster-eks > --approve
   

2. Cree iamserviceaccount , la cuenta de servicio y rol de IAM (IRSA) emparejada estándar para EKS, y adjunte la política de IAM AWSMarketplaceMeteringRegisterUsage para monitorear el uso de la imagen del controlador de ingreso NGINX Plus y autorizar la implementación. Este comando crea automáticamente una cuenta de servicio con una anotación vinculada a iamserviceaccount .

   # eksctl create iamserviceaccount --name < nombre-de-cuenta-de-servicio > --namespace nginx-ingress --cluster < nombre-de-clúster-eks > --region < región-de-clúster-eks > --attach-policy-arn arn:aws:iam::aws:policy/AWSMarketplaceMeteringRegisterUsage --approve
   

3. En el archivo YAML para RBAC, edite el valor del nombre en el campo de sujetos para que coincida con el nombre de la cuenta de servicio que configuró en el paso anterior. Esto está en la línea 104 en rbac.yaml y en la línea 23 en ap-rbac.yaml . También edite el valor del espacio de nombres si es necesario (línea 105 o línea 24), pero el comando anterior usa el valor predeterminado, nginx-ingress .

4. Aplique el archivo YAML (sustituya ap-rbac.yaml según corresponda).

   # kubectl aplicar –f rbac.yaml
   

5. Instale el software cliente Docker en la máquina local.

6. Suscríbase al listado de NGINX Plus Ingress Controller (Premium Edition) en Amazon Marketplace para contenedores .

7. Autentique su cliente Docker con Amazon ECR que aloja la imagen Docker del controlador de ingreso NGINX Plus.

8. Edite los siguientes valores en nginx-ingress.yaml :

   • kubernetes.io/hostname en el campo nodeSelector (línea 23): la etiqueta para el nodo del controlador de ingreso NGINX Plus en el clúster EKS, obtenida del comando kubectl get nodes --show-labels
   • serviceAccountName (línea 24): el nombre de la IRSA iamserviceaccount , especificado como service-account-name en el Paso 2 .
   • imagen en el campo de contenedores (línea 26): la ubicación de la imagen Docker del controlador de ingreso NGINX Plus en Amazon ECR

9. Aplicar el manifiesto YAML:

   # kubectl aplicar –f nginx-ingress.yaml
   

Implementación de los pods de backend

Realice los siguientes pasos para implementar la aplicação backend:

1. En backend-deployment.yaml , edite el valor de kubernetes.io/hostname en el campo nodeSelector (línea 15), sustituyendo la etiqueta obtenida con el comando kubectl get nodes --show-labels .

2. Aplicar el manifiesto YAML:

   # kubectl apply –f backend-deployment.yaml
   

3. Escale la aplicação backend hasta tres réplicas, suficientes para manejar la carga generada por wrk :

   # Implementación a escala de kubectl carga útil del servidor web --replicas=3
   

Metodología de pruebas

Ejecute el siguiente comando wrk en la AMI del cliente c5n.9xlarge alojada en Amazon EC2, ajustando los valores según sea necesario para que el uso de la CPU en la instancia del controlador de ingreso NGINX Plus alcance el 100 % en cada ejecución de prueba:

# wrk -t < número-de-subprocesos > -c < número-de-conexiones > -d 180s http[s]://< dirección-del-controlador-de-ingreso-NGINX-Plus >

• La opción –c especifica el número de conexiones TCP a crear. Configure esta opción según sea necesario para lograr un uso de CPU del 100 %, hasta 500 conexiones.
• La opción –d especifica durante cuánto tiempo generar tráfico (la duración de cada ejecución de prueba). Establezca esta opción en 180 segundos (3 minutos).
• La opción –t especifica el número de subprocesos a crear. Configure esta opción según sea necesario para lograr un uso de CPU del 100 %, hasta 16 subprocesos (uno por cada CPU que se utilice en el cliente durante la ejecución de la prueba).

Usamos la versión de wrk disponible en GitHub en julio de 2021 y recomendamos usar la versión actual al reproducir las pruebas.

Ejecute pruebas para recopilar dos métricas de rendimiento:

• Solicitudes por segundo (RPS) : la cantidad de solicitudes que NGINX Plus Ingress Controller puede procesar por segundo, promediadas durante un período de tiempo fijo. En este caso, utilice el esquema http:// en el comando wrk .

  El controlador de ingreso NGINX Plus acepta las solicitudes de un archivo de 1 KB (contenido estático) y equilibra su carga entre los pods de la aplicação de backend. El archivo tiene aproximadamente el tamaño de un archivo CSS o JavaScript pequeño, o de una imagen muy pequeña.

• Transacciones SSL/TLS por segundo (TPS) : la cantidad de nuevas conexiones HTTPS que NGINX Plus Ingress Controller puede establecer y atender por segundo. En este caso, utilice el esquema https:// en el comando wrk . Utilice RSA con un tamaño de clave de 2048 bits y Perfect Forward Secrecy; el cifrado SSL es ECDHE-RSA-AES256-GCM-SHA384 .

  El cliente envía una serie de solicitudes HTTPS, cada una en una nueva conexión. El cliente y el controlador de ingreso NGINX Plus realizan un protocolo de enlace TLS para establecer una conexión segura, luego el controlador de ingreso NGINX Plus analiza la solicitud y devuelve una respuesta de 0 KB . La conexión se cierra después de satisfacer la solicitud.

Como se indica en Creación del clúster de Amazon EKS , para simplificar, puede ejecutar el controlador de ingreso NGINX Plus en una instancia c5n.9xlarge en cada ejecución de prueba. Para controlar cuántas CPU están disponibles durante cada ejecución de prueba (de 1 a 36, como se especifica en la tabla en Análisis de rendimiento ), configure el parámetro en la directivaworker_processes .

Software utilizado

Utilizamos el siguiente software para las pruebas:

• La máquina cliente que ejecuta wrk generó el tráfico que el controlador de ingreso redireccionó. Usamos la versión de wrk que estaba disponible en GitHub en julio de 2021 y recomendamos usar la versión actual al reproducir las pruebas.
• Controlador de ingreso NGINX Plus versión 1.11.0
• Amazon Linux 2 LTS se ejecutó en las tres máquinas con OpenSSL 1.0.2k–fips

Análisis de rendimiento

Como se mencionó anteriormente, ejecutamos el controlador de ingreso NGINX Plus en una instancia c5n.9xlarge en cada ejecución de prueba, usando la directivaworker_processes para controlar cuántas CPU se usaron. En la siguiente tabla, informamos el tipo de instancia de la familia c5n que admite cada cantidad de CPU, junto con el TCO mensual para ese tipo de instancia.

La tabla informa la cantidad de RPS y TPS SSL logrados con diferentes cantidades de CPU disponibles para el controlador de ingreso NGINX Plus, a partir de las pruebas descritas en Metodología de prueba .

Tenga en cuenta que los RPS no crecen linealmente con un mayor número de CPU y, de hecho, el porcentaje de mejora tiende a disminuir a medida que aumenta el número de CPU. La tasa de mejora cae aún más por encima de los 16 núcleos, porque las instancias c5n.9xlarge están habilitadas con hiperprocesamiento y equipadas con 18 núcleos y 2 subprocesos por núcleo, para un total de hasta 36 CPU. El hyperthreading sólo mejora marginalmente el número de RPS.

La relación entre TPS de SSL y la cantidad de CPU también es menos que lineal, pero no disminuye tan drásticamente hasta que superamos las 16 CPU. El hyperthreading mejora el rendimiento de las operaciones paralelizables y limitadas por la CPU, como los protocolos de enlace TLS. Debido a esto, el rendimiento de SSL TPS aumenta incluso cuando superamos las 18 CPU.

CONCLUSIÓN

Hemos proporcionado detalles de implementación que puede utilizar para determinar el rendimiento esperado del controlador de ingreso NGINX Plus que se ejecuta en Amazon EKS. Puede usarlo para probar otras familias de instancias EKS y para proporcionar una solución asequible que satisfaga sus requisitos de rendimiento y escalabilidad para cargas de trabajo de producción en Kubernetes.

Nuestros resultados para HTTP RPS muestran que el porcentaje de mejora del rendimiento disminuye a medida que duplicamos la cantidad de CPU, convergiendo a aproximadamente 300 000 RPS. Los resultados de SSL TPS muestran que el rendimiento aumenta casi linealmente a medida que duplicamos la cantidad de CPU, incluso cuando comenzamos a utilizar hyperthreading (utilizando dos subprocesos por núcleo) porque los protocolos de enlace TLS están limitados por la CPU.

Consulte el resumen de la solución y pruebe usted mismo el rendimiento de NGINX Plus Ingress Controller: ¡ comience hoy mismo!

Para probar el controlador de ingreso NGINX con NGINX Open Source, puede obtener el código fuente o descargar un contenedor prediseñado desde DockerHub .