Reducción del 70 % en los costos de Kubernetes en la nube con NGINX, Opsani y Prometheus

“Es una tormenta perfecta” puede ser una frase común, pero resulta útil en el caso de los costos descontrolados de la computación en la nube. Varios factores se combinan para generar esta tormenta perfecta:

1. Las personas que implementan cargas de trabajo no son las personas que pagan por ellas
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 prestada” funcionalidad 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 resumen, nos encontramos en una situación en la que los desarrolladores se ven incentivados a implementar nuevas funcionalidades rápidamente aprovechando bloques de código existentes que, por lo general, no están optimizados ni optimizados para el propósito que cumplen en la nueva aplicación. Dado que el tiempo de comercialización es primordial, la optimización queda relegada a un segundo plano (muy atrás). Si el código no optimizado afecta el rendimiento, basta con realizar una llamada API para aprovisionar una infraestructura más potente. ¡Problema resuelto!

Lo que agrava el problema es la división, tanto en términos de mentalidad como de estructura organizacional, entre las personas que escriben el código y las personas que pagan las facturas. A medida que aumentan los costos de la nube empresarial, el director financiero suda. Pero los desarrolladores que provocaron las mayores facturas de la nube reciben una recompensa por la rápida entrega de sus productos, al tiempo que ignoran por completo los problemas financieros posteriores que se les ha incentivado a crear.

Para resolver el problema, F5 NGINX y Opsani se han asociado para ofrecer una solución de optimización que brinda a los suscriptores de F5 NGINX Ingress Controller beneficios adicionales de sus implementaciones existentes. NGINX Ingress Controller se convierte en una solución optimizada cuando el contenedor Opsani Servo se implementa en cargas de trabajo de KubeNest , donde aprovecha Prometheus para recopilar métricas de tasa, errores y duración (RED). Opsani utiliza sus capacidades de optimización autónomas, impulsadas por el aprendizaje automático, para optimizar continuamente la infraestructura y garantizar que se consuma la cantidad adecuada de recursos para lograr un mayor rendimiento y un menor costo.

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

Los usuarios de NGINX ya están familiarizados con la forma más básica de reducir los costos de la nube: usar herramientas livianas que agregan una latencia mínima y al mismo tiempo brindan un rendimiento increíblemente rápido. Y, por supuesto, en el mundo de Kubernetes, las herramientas simples pero potentes son un requisito previo para una implementación exitosa. En este blog, explicamos cómo puedes reducir costos y mejorar el rendimiento al mismo tiempo aprovechando tres herramientas:

• Controlador de ingreso NGINX : un controlador de ingreso basado en F5 NGINX Plus que supera sustancialmente a otros controladores de ingreso basados en NGINX porque se ajusta dinámicamente a los cambios en los puntos finales del back-end sin controladores de eventos ni recargas de configuración.
• Opsani : una solución única de optimización continua como servicio (COaaS) que permite agregar CO a su canalización de CI/CD, lo que le permite entregar código rápidamente y optimizarlo para obtener un rendimiento óptimo al menor costo posible.
• Prometheus : un popular proyecto de código abierto para monitoreo y alertas. Con el módulo NGINX Plus Prometheus , el controlador de ingreso NGINX basado en NGINXnbsp;Plus exporta cientos de métricas a un servidor Prometheus.

Uno de los casos de uso más poderosos de la versión basada en NGINX Plus de NGINX Ingress Controller es su capacidad de mejorar la visibilidad en Kubernetes con monitoreo en vivo (a través del panel de NGINX Plus ) y datos históricos (a través de Prometheus). Además, en su función como interfaz para cargas de trabajo, NGINX Ingress Controller puede recopilar métricas de velocidad, 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 la pila tecnológica en su totalidad. Incluso puede configurar Opsani para que le avise sobre los umbrales de latencia y rendimiento establecidos para el controlador de ingreso NGINX.

Una mirada a los números: los resultados de nuestras pruebas de optimización

Veamos un ejemplo de los resultados que puede esperar al implementar el controlador de ingreso NGINX basado en NGINX Plus con Opsani y Prometheus. Como se muestra en la captura de pantalla, la página Resumen de Opsani informa el volumen de tráfico (solicitudes por segundo o RPS) a lo largo del tiempo y destaca los beneficios de sus optimizaciones en comparación con las configuraciones de referencia: aquí, un ahorro del 70 % en el costo de instancia por hora y un tiempo de respuesta P50 un 5 % mejor.

Nos preguntamos cómo estos resultados podrían compararse con uno de los controladores de Ingress más conocidos: el controlador de Ingress basado en código abierto NGINX mantenido por la comunidad Kubernetes en el repositorio de GitHub kubernetes/ingress-nginx . (Siguiendo la convención NGINX establecida, lo llamaremos “controlador de ingreso de la comunidad” en el resto de este blog. El equipo de ingeniería de NGINX mantiene la versión basada en NGINX Plus de NGINX Ingress Controller en el repositorio de GitHub nginxinc/kubernetes-ingress , junto con su versión hermana NGINX Ingress Controller basada en NGINX Open Source.)

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

• Topología 1 : Controlador de ingreso a la comunidad, implementado mediante el proceso estándar . Las métricas se recopilaron agregando un proxy Envoy en línea con la aplicação bajo prueba, en un contenedor sidecar en el pod de la aplicação .

  

• Topología 2 : Controlador de ingreso 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 ingreso de la comunidad, para garantizar que la recopilación de métricas no afectara el proceso de rendimiento de optimización.

  

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

  

La tabla resume los resultados de las pruebas. Como puede ver, el controlador de ingreso NGINX logra una mejor reducción de costos, optimización de CPU y optimización de memoria que el controlador de ingreso comunitario. Atribuimos esto al equilibrio de carga más eficiente del controlador de ingreso NGINX.

Los resultados del tiempo de respuesta P50 indican que Prometheus es la forma ideal de recopilar métricas, porque elimina el salto adicional que requiere el mecanismo sidecar de Envoy. Envoy no tiene ningún efecto en el tiempo de respuesta P50 para el controlador de ingreso de la comunidad, pero en realidad empeora la latencia en un 4 % con el controlador de ingreso NGINX. Por el contrario, Prometheus mejora el tiempo de respuesta P50 con NGINX Ingress Controller en un 5%.

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

Cómo Opsani optimiza el controlador de ingreso de NGINX

Opsani puede optimizar aplicações incluso si tienen un equilibrio de carga deficiente en entornos dinámicos. También puede aprovechar cualquier tipo de entrada de métricas, pero la optimización de los servicios conectados mejora drásticamente cuando la entrada proviene de una herramienta existente que recopila métricas de red. Para este fin, utilizamos un proceso de implementación simple para integrar Opsani con NGINX Ingress Controller.

En entornos donde NGINX es el controlador de ingreso (lo que se aplica a muchas aplicações hoy en día), el cambio directo al uso del controlador de ingreso NGINX basado en NGINX Plus proporciona un algoritmo de equilibrio de carga más eficiente sin afectar de otro modo el funcionamiento de la aplicação . Un segundo beneficio es que las métricas para la carga de aplicações balanceada por NGINX Ingress Controller también estarán disponibles.

El único requisito adicional es implementar un solo pod de Opsani con la aplicação bajo el espacio de nombres de optimización. La plantilla Opsani para el controlador de ingreso NGINX basado en NGINX Plus apunta el punto final de métricas al servicio de ingreso para capturar las métricas específicas de la aplicação necesarias para la optimización. Al procesar métricas de tres o cuatro períodos pico, el motor Opsani alcanza un nivel óptimo de optimización en tan solo unas pocas horas. Hasta ahora hemos conseguido optimizar la carga máxima del 30% al 70%.

Introducción a Opsani y el controlador de ingreso NGINX

Obtenga sus pruebas gratuitas de NGINX Ingress Controller y Opsani , luego diríjase a nuestro repositorio de GitHub para obtener scripts y archivos de configuración para NGINX Ingress Controller y Opsani con Prometheus.

Apéndice: Metodología de pruebas

Requisitos previos

• El controlador de ingreso NGINX basado en NGINX Plus está construido como un contenedor .
• Kubernetes está configurado y el secreto de acceso al registro está disponible para proporcionar acceso a un registro Docker privado seguro .
• El controlador de ingreso NGINX basado en NGINX Plus se implementa a través de Helm en el espacio de nombres de ingreso .
• Un recurso VirtualServer de NGINX se configura para apuntar al servicio que se va a optimizar (normalmente, el servicio de interfaz de usuario 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 Opsani Dev estándar disponible para todas las cuentas Opsani y simplemente conectamos la aplicação con NGINX Ingress Controller y apuntamos al servicio de la aplicação .

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 valores apropiados para las siguientes variables en ConfigMap:

• {{ NAMESPACE }} – Espacio de nombres del recurso de destino
• {{ IMPLEMENTACIÓN }} – Implementación de destino
• {{CONTAINER}} – Nombre del contenedor de la aplicação de destino

Además, configuramos OPSANI_ACCOUNT_NAME , OPSANI_APPLICATION_NAME y OPSANI_TOKEN de acuerdo con el documento expuesto con la implementación de la aplicação .

Si bien el ServoX predeterminado para Opsani Dev incluye una instancia de Prometheus, en su lugar implementamos la instancia de Prometheus en el mismo espacio de nombres que NGINX Ingress Controller, para reducir la necesidad de configuración de ClusterRole.

También configuramos un servicio para permitir que el pod Servo encuentre y consulte la instancia correcta. Este artefacto está cubierto en opsani-manifests-nginx-plus.yaml .

Una vez que Bank of Anthos se ejecuta como aplicação web de muestra y se ha verificado el Ingress, lanzamos la instancia de Ingress Prometheus. Por último, podemos iniciar la optimización de Opsani aplicando el archivo opsani-manifests-nginx-plus.yaml .