Implementación de NGINX Ingress Controller en Amazon EKS: cómo lo probamos

Amir RawdatIngeniero de soluciones

En NGINX buscamos constantemente formas de ayudarle a sacar el máximo partido a nuestro software. Nuestros documentos de soluciones y guías de dimensionamiento son un recurso importante que ponemos a su disposición. Mediante pruebas empíricas del rendimiento que puede esperar con distintos niveles de potencia informática, le ayudamos a maximizar el rendimiento de la entrega de aplicaciones con la infraestructura que ya tiene y a calcular con precisión los gastos operativos correspondientes al rendimiento y la escala que está preparando.

Recientemente actualizamos el documento de descripción de la solución NGINX Ingress Controller con directrices de dimensionamiento para Amazon Elastic Kubernetes Service (EKS). El documento detalla el rendimiento que puede esperar obtener con NGINX Ingress Controller ejecutándose en distintos tipos de instancias de Amazon EKS, junto con el coste total de propiedad (TCO) mensual estimado. En este blog explicamos cómo obtuvimos esas cifras e incluimos toda la información necesaria para que pueda realizar pruebas similares por su cuenta.

Topología

El siguiente diagrama muestra la topología utilizada para las pruebas.

• Administrador es el usuario que realiza las pruebas ejecutando los comandos especificados en las secciones siguientes.
• Amazon ECR (Elastic Container Registry) aloja la imagen oficial de Docker de NGINX Plus Ingress Controller utilizada en las pruebas. Consulte Implementación de NGINX Plus Ingress Controller.
• Amazon EC2 (Elastic Compute Cloud) aloja la imagen c5n.9xlarge en la que se ejecuta wrk, que genera las solicitudes. Consulte Metodología de las pruebas.
• Amazon EKS (Elastic Kubernetes Service) aloja las imágenes c5n.9xlarge para NGINX Plus Ingress Controller y la aplicación de backend. Consulte Creación del clúster de Amazon EKS.
• NGINX Plus Ingress Controller redirige las solicitudes generadas por wrk a la aplicación de backend y devuelve las respuestas de la aplicación. Consulte Implementación de NGINX Plus Ingress Controller.
• Aplicación de backend responde a las solicitudes reenviadas por NGINX. Consulte Implementación de los pods de backend.

Creación del clúster de Amazon EKS

Antes de desplegar el clúster de EKS, siga estos pasos en el equipo local, representado por el icono Administrador en el diagrama:

1. Descarga eksctl, la interfaz de línea de comandos oficial de Amazon EKS. Si ya tienes eksctl instalado en tu equipo, asegúrate de actualizarlo a la versión más reciente.
2. Añada las credenciales de administrador de AWS correspondientes al archivo ${HOME}/.aws/credentials.
3. Descarga los archivos YAML de esta entrada de blog desde nuestro repositorio de Gist.
4. Descargue rbac.yaml (o ap-rbac.yaml si utiliza NGINX App Protect) del repositorio de NGINX Ingress Controller en GitHub.

Para desplegar el clúster de EKS, ejecuta el siguiente comando eksctl en la máquina local. (Se omite la opción --nodes, ya que, de forma predeterminada, el comando crea los dos nodos necesarios para las pruebas: uno para NGINX Plus Ingress Controller y otro para la aplicación backend básica.)

Nota: Puede implementar el clúster de EKS en cualquier región excepto us-west-1. La suscripción a la imagen de NGINX Plus Ingress Controller en Amazon Marketplace for Containers (consulte la sección siguiente) no está disponible en esa región.

# eksctl create cluster --instance-types=c5n.9xlarge --managed --ssh-access=true --ssh-public-key=/path/to/public-key

Para conectarse a un nodo del clúster mediante SSH, ejecute este comando. Durante las pruebas, debe conectarse al nodo de NGINX Plus Ingress Controller para ejecutar el comando htop y comprobar que la carga del cliente wrk sea suficiente para que el uso de la CPU del nodo alcance el 100 %.

# ssh -i /path/to/private-key ec2-user@<public-IP-address-of-EKS-node>

Implementación de NGINX Plus Ingress Controller

Implementar NGINX Plus Ingress Controller en Amazon EKS es ahora más fácil que nunca.

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

# eksctl utils associate-iam-oidc-provider --region=<eks-cluster-region> --cluster=<eks-cluster-name> --approve

1. Cree iamserviceaccount, la combinación estándar de rol de IAM y cuenta de servicio (IRSA) para EKS, y adjunte la política de IAM AWSMarketplaceMeteringRegisterUsage para supervisar el uso de la imagen de NGINX Plus Ingress Controller y autorizar la implementación. Este comando crea automáticamente una cuenta de servicio con una anotación que la vincula a iamserviceaccount.

# eksctl create iamserviceaccount --name <service-account-name> --namespace nginx-ingress --cluster <eks-cluster-name> --region <eks-cluster-region> --attach-policy-arn arn:aws:iam::aws:policy/AWSMarketplaceMeteringRegisterUsage --approve

1. En el archivo YAML de RBAC, edite el valor de name en el campo subjects para que coincida con el valor de service-account-name que estableció en el paso anterior. Se encuentra en la línea 104 de rbac.yaml y en la línea 23 de ap-rbac.yaml. Edite también el valor del espacio de nombres si es necesario (línea 105 o línea 24), aunque el comando anterior utiliza el valor predeterminado, nginx-ingress.
2. Aplique el archivo YAML (sustituya ap-rbac.yaml según corresponda).

# kubectl apply –f rbac.yaml

1. Instale el cliente de Docker en el equipo local.
2. Suscríbase a la oferta de NGINX Plus Ingress Controller (Premium Edition) en Amazon Marketplace for Containers.
3. Autentique su cliente de Docker en Amazon ECR, donde se aloja la imagen de Docker de NGINX Plus Ingress Controller.
4. Edite los siguientes valores en nginx-ingress.yaml:
   • kubernetes.io/hostname en el campo nodeSelector (línea 23): la etiqueta del nodo de NGINX Plus Ingress Controller en el clúster de EKS, obtenida mediante el comando kubectl get nodes --show-labels command
   • serviceAccountName (línea 24) — El nombre de la iamserviceaccount de IRSA, especificado como service-account-name en el paso 2.
   • image en el campo containers (línea 26) – La ubicación de la imagen de Docker de NGINX Plus Ingress Controller en Amazon ECR
5. Aplique el manifiesto YAML:

# kubectl apply –f nginx-ingress.yaml

Despliegue de los pods del backend

Siga los pasos que se indican a continuación para desplegar la aplicación de backend:

1. En backend-deployment.yaml, edite el valor de kubernetes.io/hostname en el campo nodeSelector (línea 15) y sustitúyalo por la etiqueta obtenida mediante el comando kubectl get nodes --show-labels.
2. Aplica el manifiesto YAML:

# kubectl apply –f backend-deployment.yaml

1. Escala la aplicación de backend a tres réplicas, suficientes para gestionar la carga generada por «wrk»:

# kubectl scale deployment web-server-payload --replicas=3

Metodología de las pruebas

Ejecute el siguiente comando wrk en el cliente c5n.9xlarge con una AMI alojada en Amazon EC2 y ajuste los valores según sea necesario para que el uso de la CPU de la instancia de NGINX Plus Ingress Controller alcance el 100 % en cada ejecución de la prueba:

# wrk -t <number-of-threads> -c <number-of-connections> -d 180s http[s]://<address-of-NGINX-Plus-Ingress-Controller>

• La opción –c especifica el número de conexiones TCP que se crearán. Configure esta opción según sea necesario para alcanzar un uso de la CPU del 100 %, hasta un máximo de 500 conexiones.
• La opción –d especifica durante cuánto tiempo se genera 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 hilos que se deben crear. Configure esta opción según sea necesario para alcanzar un uso de la CPU del 100 %, hasta un máximo de 16 hilos (uno por cada CPU utilizada en el cliente durante la ejecución de la prueba).

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

Ejecute las pruebas para recopilar dos métricas de rendimiento:

• Solicitudes por segundo (RPS) – El número de solicitudes que NGINX Plus Ingress Controller puede procesar por segundo, calculado como promedio durante un periodo de tiempo fijo. En este caso, utilice el esquema http:// en el comando wrk. NGINX Plus Ingress Controller acepta las solicitudes de un archivo de 1 KB (contenido estático) y las distribuye entre los pods de la aplicación 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) – El número 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 secreto perfecto hacia adelante; el cifrado SSL es ECDHE-RSA-AES256-GCM-SHA384. El cliente envía una serie de solicitudes HTTPS, cada una a través de una nueva conexión. El cliente y NGINX Plus Ingress Controller realizan un protocolo de enlace TLS para establecer una conexión segura; a continuación, NGINX Plus Ingress Controller analiza la solicitud y devuelve una respuesta de 0 KB. La conexión se cierra una vez atendida la solicitud.

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

Software utilizado

Utilizamos el siguiente software para las pruebas:

• La máquina cliente que ejecutaba wrk generó el tráfico que el Ingress Controller redirigió. Utilizamos la versión de wrk que estaba disponible en GitHub en julio de 2021 y recomendamos utilizar la versión actual al reproducir las pruebas.
• NGINX Plus Ingress Controller versión 1.11.0
• Amazon Linux 2 LTS se ejecutó en las tres máquinas con OpenSSL 1.0.2k–fips

Análisis del rendimiento

Como se ha mencionado anteriormente, ejecutamos NGINX Plus Ingress Controller en una instancia c5n.9xlarge en cada prueba y utilizamos la directiva «worker_processes» para controlar cuántas CPU se usaban. En la tabla siguiente, indicamos el tipo de instancia de la familia c5n que admite cada número de CPU, junto con el coste total de propiedad mensual de dicho tipo de instancia.

La tabla muestra el número de RPS y TPS SSL alcanzado con distintas cantidades de CPU disponibles para NGINX Plus Ingress Controller, según las pruebas descritas en Metodología de las pruebas.

Tenga en cuenta que las RPS no aumentan de forma lineal al incrementar el número de CPU; de hecho, el porcentaje de mejora tiende a disminuir a medida que aumenta dicho número. La tasa de mejora se reduce aún más por encima de los 16 núcleos, ya que las instancias c5n.9xlarge tienen habilitado el hyperthreading y están equipadas con 18 núcleos y 2 hilos por núcleo, lo que supone un total de hasta 36 CPU. El hyperthreading solo mejora de forma marginal el número de RPS.

La relación entre los TPS de SSL y el número de CPU tampoco es lineal, pero no disminuye de forma tan drástica hasta que superamos las 16 CPU. Hyper-Threading mejora el rendimiento de las operaciones paralelizables que hacen un uso intensivo de la CPU, como los protocolos de enlace TLS. Por este motivo, el rendimiento de los TPS de SSL aumenta incluso cuando superamos las 18 CPU.

Conclusión

Hemos proporcionado información detallada sobre la implementación que puede utilizar para determinar el rendimiento esperado de NGINX Plus Ingress Controller ejecutándose en Amazon EKS. Puede utilizarla para probar otras familias de instancias de EKS y aprovisionar una solución asequible que satisfaga sus requisitos de rendimiento y escalabilidad para cargas de trabajo de producción en Kubernetes.

Nuestros resultados de RPS HTTP muestran que el porcentaje de mejora del rendimiento disminuye a medida que duplicamos el número de CPU, hasta converger en aproximadamente 300.000 RPS. Los resultados de TPS SSL muestran que el rendimiento aumenta de forma casi lineal al duplicar el número de CPU, incluso cuando empezamos a utilizar hyperthreading (dos hilos por núcleo), ya que los protocolos de enlace TLS dependen de la CPU.

Consulta el resumen de la solución, y comprueba por ti mismo el rendimiento de NGINX Plus Ingress Controller. Empieza hoy mismo.

Para probar NGINX Ingress Controller con NGINX Open Source, puede obtener el código fuente o descargar un contenedor precompilado de DockerHub.

Sobre el autor

Amir RawdatIngeniero de soluciones

Más artículos de Amir Rawdat