Cómo reducir un 70 % los costes de Kubernetes en la nube con NGINX, Opsani y Prometheus

Amir Sharif

«Es la tormenta perfecta» puede ser una expresión habitual, pero resulta muy apropiada para describir el aumento descontrolado de los costes de la computación en la nube. Varios factores se combinan y se potencian entre sí hasta provocar esta tormenta perfecta:

1. Quienes implementan las cargas de trabajo no son quienes las pagan
2. Es fácil consumir infraestructura bajo demanda y de forma programática
3. Los repositorios de código de fácil acceso permiten «tomar prestadas» funcionalidades de código existente escrito por otra persona
4. Las canalizaciones de CI/CD y las prácticas de SRE ayudan a los desarrolladores a integrar e implementar código rápidamente

En definitiva, nos encontramos en una situación en la que se incentiva a los desarrolladores a implementar rápidamente nuevas funcionalidades aprovechando bloques de código existentes que, por lo general, no están simplificados ni optimizados para la función que desempeñan en la nueva aplicación. Dado que reducir el tiempo de comercialización es primordial, la optimización queda relegada a un segundo plano (muy, muy secundario). Si el código no optimizado perjudica el rendimiento, basta con una llamada a la API para aprovisionar una infraestructura más potente. ¡Problema resuelto!

El problema se ve agravado por la brecha —tanto en términos de mentalidad como de estructura organizativa— entre quienes escriben el código y quienes pagan las facturas. A medida que aumentan los costes de la nube para la empresa, el director financiero empieza a sudar. Sin embargo, los desarrolladores que han provocado el aumento de las facturas de la nube son recompensados por la rapidez con la que entregan el producto, mientras permanecen felizmente ajenos a los problemas financieros posteriores que se les ha incentivado a generar.

Para resolver el problema, F5 NGINX y Opsani se han asociado para ofrecer una solución de optimización que proporciona a los suscriptores de F5 NGINX Ingress Controller ventajas adicionales en sus implementaciones actuales. NGINX Ingress Controller se convierte en una solución optimizada cuando el contenedor Opsani Servo se implementa en cargas de trabajo de KubeNest, donde utiliza Prometheus para recopilar métricas de tasa, errores y duración (RED). Opsani utiliza sus capacidades de optimización autónoma, basadas en aprendizaje automático, para optimizar continuamente la infraestructura y garantizar que se consuma la cantidad adecuada de recursos a fin de mejorar el rendimiento y reducir los costes.

Uso de la optimización de la nube para reducir costes

Los usuarios de NGINX ya conocen la forma más básica de reducir los costes de la nube: utilizar herramientas ligeras que añadan una latencia mínima y, al mismo tiempo, ofrezcan un rendimiento ultrarrápido. Y, por supuesto, en el mundo de Kubernetes, las herramientas sencillas pero potentes son un requisito indispensable para que una implementación tenga éxito. En este blog, explicamos cómo puede reducir los costes y mejorar el rendimiento al mismo tiempo aprovechando tres herramientas:

• NGINX Ingress Controller – Un controlador de Ingress basado en F5 NGINX Plus que supera considerablemente en rendimiento a otros controladores de Ingress basados en NGINX porque se adapta dinámicamente a los cambios en los endpoints de backend sin controladores de eventos ni recargas de configuración.
• Opsani – Una solución única de optimización continua como servicio (COaaS) que permite añadir la optimización continua a su canalización de CI/CD, lo que le permite entregar código rápidamente y optimizarlo para obtener el máximo rendimiento al menor coste posible.
• Prometheus – Un popular proyecto de código abierto para la monitorización y las alertas. Con el módulo Prometheus de NGINX Plus, el controlador de entrada NGINX basado en NGINXnbsp;Plus exporta cientos de métricas a un servidor Prometheus.

Uno de los casos de uso más potentes de la versión de NGINX Ingress Controller basada en NGINX Plus es su capacidad para mejorar la visibilidad en Kubernetes mediante la supervisión en tiempo real (a través del panel de NGINX Plus) y los datos históricos (a través de Prometheus). Además, en su función de front-end para las cargas de trabajo, NGINX Ingress Controller puede recopilar métricas de tasa, errores y duración (RED) y enviarlas (a través de Prometheus) a Opsani. Opsani utiliza el aprendizaje automático para correlacionar las métricas con la infraestructura implementada actualmente y recomendar cambios que optimicen NGINX Ingress Controller, sus aplicaciones o el conjunto de tecnologías en su totalidad. Incluso puede configurar Opsani para que le avise cuando se alcancen los umbrales de latencia y rendimiento establecidos para NGINX Ingress Controller.

Un vistazo a las cifras: resultados de nuestras pruebas de optimización

Veamos un ejemplo de los resultados que puede esperar al implementar NGINX Ingress Controller basado en NGINX Plus con Opsani y Prometheus. Como se muestra en la captura de pantalla, la página Resumen de Opsani muestra la evolución del volumen de tráfico (solicitudes por segundo o RPS) y destaca las ventajas de sus optimizaciones frente a la configuración de referencia: en este caso, un ahorro del 70 % en el coste por hora de la instancia y una mejora del 5 % en el tiempo de respuesta P50.

Nos preguntamos cómo se compararían estos resultados con los de uno de los controladores Ingress más conocidos: el controlador Ingress basado en NGINX Open Source que mantiene la comunidad de Kubernetes en el repositorio de GitHub kubernetes/ingress-nginx,. (Siguiendo la convención de NGINX, en el resto de este blog lo llamaremos «controlador Ingress de la comunidad». La versión de NGINX Ingress Controller basada en NGINX Plus la mantiene el equipo de ingeniería de NGINX en el repositorio de GitHub nginxinc/kubernetes-ingress, junto con su controlador NGINX Ingress Controller hermano basado en NGINX Open Source).

Probamos el rendimiento de los dos controladores Ingress en tres topologías:

• Topología 1 – Controlador Ingress de la comunidad, implementado mediante el proceso estándar. Las métricas se recopilaron añadiendo un proxy Envoy en línea con la aplicación sometida a prueba, en un contenedor sidecar dentro del pod de la aplicación.
  
• Topología 2 – Controlador de entrada NGINX basado en NGINX Plus, implementado mediante Helm. Las métricas se recopilaron con la misma implementación y configuración de Envoy que para el controlador de entrada de la comunidad, a fin de garantizar que su recopilación no afectara al proceso de optimización del rendimiento.
  

• Topología 3 – Controlador de entrada NGINX basado en NGINX Plus, también implementado mediante Helm. Las métricas se recopilaron mediante Prometheus.
  

La tabla resume los resultados de las pruebas. Como puede observarse, NGINX Ingress Controller logra una mayor reducción de costes y una mejor optimización de la CPU y la memoria que el controlador Ingress de la comunidad. Esto se debe, en nuestra opinión, al balanceo de carga más eficiente de NGINX Ingress Controller.

Los resultados del tiempo de respuesta P50 indican que Prometheus es la opción ideal para recopilar métricas, ya que elimina el salto adicional que requiere el mecanismo sidecar de Envoy. Envoy no afecta al tiempo de respuesta P50 del controlador Ingress de la comunidad, pero aumenta la latencia en un 4 % con NGINX Ingress Controller. En cambio, Prometheus mejora en un 5 % el tiempo de respuesta P50 con NGINX Ingress Controller.

Para obtener información sobre cómo realizamos las pruebas, consulte el Apéndice.

Cómo optimiza Opsani NGINX Ingress Controller

Opsani puede optimizar aplicaciones incluso si el equilibrio de carga es deficiente en entornos dinámicos. También puede aprovechar cualquier tipo de datos de métricas, pero la optimización de los servicios conectados mejora considerablemente cuando los datos proceden de una herramienta existente que recopila métricas de red. Para ello, utilizamos un sencillo proceso de despliegue para integrar Opsani con NGINX Ingress Controller.

En entornos en los que NGINX es el controlador de Ingress —como ocurre actualmente con muchas aplicaciones—, el sencillo cambio al controlador NGINX Ingress Controller basado en NGINX Plus proporciona un algoritmo de equilibrio de carga más eficiente sin afectar al funcionamiento de las aplicaciones. Otra ventaja es que también pasan a estar disponibles las métricas de las aplicaciones cuya carga equilibra NGINX Ingress Controller.

El único requisito adicional es desplegar un único pod de Opsani junto con la aplicación en el espacio de nombres de optimización. La plantilla de Opsani para NGINX Ingress Controller basado en NGINX Plus dirige el punto de conexión de métricas al servicio Ingress para recopilar las métricas específicas de la aplicación necesarias para la optimización. Al procesar las métricas de tres o cuatro periodos de máxima demanda, el motor de Opsani alcanza un nivel óptimo de optimización en tan solo unas horas. Hasta la fecha, hemos logrado una optimización de la carga máxima de entre el 30 % y el 70 %.

Empiece a utilizar Opsani y NGINX Ingress Controller

Obtén tus pruebas gratuitas de NGINX Ingress Controller y Opsani, y después visita nuestro repositorio de GitHub para acceder a los scripts y archivos de configuración de NGINX Ingress Controller y Opsani con Prometheus.

Apéndice: metodología de las pruebas

Requisitos previos

• NGINX Ingress Controller basado en NGINX Plus se compila como un contenedor.
• Kubernetes está configurado y el secreto de acceso al registro está disponible para proporcionar acceso a un registro privado seguro de Docker.
• El controlador NGINX Ingress basado en NGINX Plus se implementa mediante Helm en el espacio de nombres ingress.
• Se configura un recurso VirtualServer de NGINX para que apunte al servicio que se va a optimizar (normalmente, el servicio frontend de forma predeterminada). Consulte frontend-virtualserver.yaml en nuestro repositorio de GitHut para ver un ejemplo.

Topología y configuración

Creamos tres instancias de Opsani. Para las topologías 1 y 2, utilizamos la plantilla estándar de Opsani Dev disponible para todas las cuentas de Opsani y simplemente colocamos NGINX Ingress Controller delante de la aplicación y lo dirigimos al servicio de la aplicación.

Para la topología 3, utilizamos la misma plantilla predeterminada y modificamos la configuración de Servo con el ConfigMap definido en opsani-manifests-nginx-plus.yaml en el repositorio de GitHub. Al igual que con la plantilla estándar, sustituimos las siguientes variables del ConfigMap por los valores adecuados:

• {{ NAMESPACE }} – Espacio de nombres del recurso de destino
• {{ DEPLOYMENT }} – Implementación de destino
• {{ CONTAINER }} – Nombre del contenedor de la aplicación de destino

Además, configuramos OPSANI_ACCOUNT_NAME, OPSANI_APPLICATION_NAME y OPSANI_TOKEN de acuerdo con el documento proporcionado con el despliegue de la aplicación.

Aunque la versión predeterminada de ServoX para Opsani Dev incluye una instancia de Prometheus, nosotros implementamos la instancia de Prometheus en el mismo espacio de nombres que NGINX Ingress Controller para reducir la necesidad de configurar ClusterRole.

También configuramos un servicio para que el pod de Servo pueda encontrar y consultar la instancia correcta. Este recurso se incluye en opsani-manifests-nginx-plus.yaml.

Una vez que Bank of Anthos se esté ejecutando como aplicación web de ejemplo y se haya verificado el Ingress, iniciamos la instancia de Prometheus del Ingress. Por último, podemos iniciar la optimización de Opsani aplicando el archivo opsani-manifests-nginx-plus.yaml.

Sobre el autor

Amir Sharif

Más artículos de Amir Sharif