Reduzindo os custos do Kubernetes em 70% na nuvem com NGINX, Opsani e Prometheus

“É uma tempestade perfeita” pode ser uma frase comum, mas é útil no caso de custos descontrolados de computação em nuvem. Vários fatores se complementam para gerar essa tempestade perfeita:

1. As pessoas que implementam as cargas de trabalho não são as pessoas que pagam por elas
2. É fácil consumir infraestrutura sob demanda e programaticamente
3. Repositórios de código facilmente acessíveis tornam possível “emprestar” funcionalidades de código existente escrito por outra pessoa
4. Os pipelines de CI/CD e as práticas de SRE ajudam os desenvolvedores a integrar e implantar o código rapidamente

Juntando tudo isso, temos uma situação em que os desenvolvedores são incentivados a implementar novas funcionalidades rapidamente, aproveitando blocos de código existentes que geralmente não são simplificados nem otimizados para o propósito que atendem no novo aplicativo. Como o tempo de lançamento no mercado é primordial, a otimização fica em segundo plano (muito para trás). Se o código não otimizado prejudicar o desempenho, o provisionamento de uma infraestrutura mais poderosa estará a apenas uma chamada de API de distância. Problema resolvido!

O problema é agravado pela divisão – em termos de mentalidade e estrutura organizacional – entre as pessoas que escrevem o código e as pessoas que pagam as contas. À medida que os custos da nuvem empresarial aumentam, o CFO fica tenso. Mas os desenvolvedores que causaram as contas de nuvem mais altas são recompensados pela entrega rápida dos produtos, enquanto ignoram completamente os problemas financeiros posteriores que foram incentivados a criar.

Para resolver o problema, a F5 NGINX e a Opsani fizeram uma parceria para fornecer uma solução de otimização que oferece aos assinantes do F5 NGINX Ingress Controller benefícios adicionais de suas implantações existentes. O NGINX Ingress Controller se torna uma solução otimizada quando o contêiner Opsani Servo é implantado em cargas de trabalho do KubeNest , onde ele utiliza o Prometheus para coletar métricas de taxa, erros e duração (RED). A Opsani usa seus recursos de otimização autônoma – alimentados por aprendizado de máquina – para otimizar continuamente a infraestrutura e garantir que a quantidade certa de recursos seja consumida para maior desempenho e menor custo.

Usando a otimização da nuvem para reduzir custos

Os usuários do NGINX já estão familiarizados com a maneira mais básica de reduzir os custos da nuvem: usar ferramentas leves que adicionam latência mínima e, ao mesmo tempo, oferecem desempenho extremamente rápido. E, claro, no mundo do Kubernetes, ferramentas simples, porém poderosas, são um pré-requisito para uma implantação bem-sucedida. Neste blog, explicamos como você pode reduzir custos e melhorar o desempenho ao mesmo tempo aproveitando três ferramentas:

• Controlador de entrada NGINX – Um controlador de entrada baseado no F5 NGINX Plus que supera substancialmente outros controladores de entrada baseados em NGINX porque ele se ajusta dinamicamente às alterações nos endpoints de back-end sem manipuladores de eventos ou recarregamentos de configuração.
• Opsani – Uma solução exclusiva de Otimização Contínua como Serviço (COaaS) que torna possível adicionar CO ao seu pipeline de CI/CD, permitindo que você entregue código rapidamente e otimize esse código para desempenho ideal ao menor custo possível.
• Prometheus – Um projeto popular de código aberto para monitoramento e alerta. Com o módulo NGINX Plus Prometheus , o NGINX Ingress Controller baseado no NGINX Plus exporta centenas de métricas para um servidor Prometheus.

Um dos casos de uso mais poderosos para a versão do NGINX Ingress Controller baseada no NGINX Plus é sua capacidade de melhorar a visibilidade no Kubernetes com monitoramento ao vivo (por meio do painel do NGINX Plus ) e dados históricos (por meio do Prometheus). Além disso, em sua função como front-end para cargas de trabalho, o NGINX Ingress Controller pode coletar métricas de taxa, erros e duração (RED) e alimentá-las (por meio do Prometheus) ao Opsani. A Opsani usa aprendizado de máquina para correlacionar as métricas com a infraestrutura implantada atualmente e recomendar alterações que otimizem o NGINX Ingress Controller, seus aplicativos ou a pilha de tecnologia como um todo. Você pode até configurar o Opsani para alertá-lo sobre os limites de latência e desempenho definidos para o NGINX Ingress Controller.

Uma olhada nos números – Os resultados dos nossos testes de otimização

Vejamos um exemplo dos resultados que você pode esperar da implantação do NGINX Ingress Controller baseado no NGINX Plus com Opsani e Prometheus. Conforme mostrado na captura de tela, a página Resumo do Opsani relata o volume de tráfego (solicitações por segundo ou RPS) ao longo do tempo e destaca os benefícios de suas otimizações em comparação com as configurações de linha de base – aqui, uma economia de 70% no Custo de Instância por Hora e 5% melhor Tempo de Resposta P50 .

Ficamos imaginando como esses resultados poderiam ser comparados a um dos controladores Ingress mais conhecidos: o controlador Ingress baseado em código aberto NGINX mantido pela comunidade Kubernetes no repositório GitHub kubernetes/ingress-nginx . (Seguindo a convenção NGINX estabelecida, nós o chamaremos de “controlador Ingress da comunidade” pelo restante deste blog. A versão do NGINX Ingress Controller baseada no NGINX Plus é mantida pela equipe de engenharia do NGINX no repositório nginxinc/kubernetes-ingress do GitHub, junto com seu controlador irmão NGINX Ingress Controller baseado no NGINX Open Source.)

Testamos o desempenho dos dois controladores Ingress em três topologias:

• Topologia 1 – Controlador de entrada da comunidade, implantado usando o processo padrão . As métricas foram coletadas adicionando um proxy Envoy em linha com o application em teste, em um contêiner sidecar no pod do application .

  

• Topologia 2 – NGINX Ingress Controller baseado no NGINX Plus, implantado usando Helm . As métricas foram coletadas com a mesma implantação e configuração do Envoy do Ingress Controller da comunidade, para garantir que a coleta de métricas não afetasse o processo de desempenho de otimização.

  

• Topologia 3 – NGINX Ingress Controller baseado no NGINX Plus, também implantado usando Helm. As métricas foram coletadas usando o Prometheus.

  

A tabela resume os resultados dos testes. Como você pode ver, o NGINX Ingress Controller alcança melhor redução de custos, otimização de CPU e otimização de memória do que o controlador Ingress da comunidade. Atribuímos isso ao balanceamento de carga mais eficiente do NGINX Ingress Controller.

Os resultados do tempo de resposta do P50 indicam que o Prometheus é a maneira ideal de coletar métricas, porque elimina o salto extra exigido pelo mecanismo sidecar do Envoy. O Envoy não tem efeito no tempo de resposta do P50 para o controlador Community Ingress, mas na verdade piora a latência em 4% com o controlador NGINX Ingress. Em contraste, o Prometheus melhora o tempo de resposta do P50 com o NGINX Ingress Controller em 5%.

Para obter informações sobre como executamos os testes, consulte o Apêndice .

Como o Opsani otimiza o controlador de entrada NGINX

O Opsani pode otimizar applications mesmo que eles tenham balanceamento de carga ruim em ambientes dinâmicos. Ele também pode aproveitar qualquer tipo de entrada de métricas, mas a otimização dos serviços conectados é drasticamente melhorada quando a entrada vem de uma ferramenta existente que reúne métricas de rede. Para isso, usamos um processo de implantação simples para integrar o Opsani com o NGINX Ingress Controller.

Em ambientes onde o NGINX é o controlador de entrada (o que se aplica a muitos applications hoje em dia), a troca direta para o uso do controlador de entrada NGINX baseado no NGINX Plus fornece um algoritmo de balanceamento de carga mais eficiente sem afetar o funcionamento do application . Um segundo benefício é que as métricas para a carga de applications balanceada pelo NGINX Ingress Controller também ficam disponíveis.

O único requisito adicional é implantar um único pod Opsani com o application no namespace de otimização. O modelo Opsani para o NGINX Ingress Controller baseado no NGINX Plus aponta o ponto de extremidade de métricas para o serviço Ingress para capturar as métricas específicas do application necessárias para a otimização. Ao processar métricas de três ou quatro períodos de pico, o mecanismo Opsani atinge um nível ideal de otimização em apenas algumas horas. Até o momento, alcançamos uma otimização de pico de carga de 30% para 70%.

Introdução ao Opsani e ao NGINX Ingress Controller

Obtenha suas avaliações gratuitas do NGINX Ingress Controller e Opsani e, em seguida, acesse nosso repositório GitHub para obter scripts e arquivos de configuração para o NGINX Ingress Controller e Opsani com Prometheus.

Apêndice: Metodologia de Teste

Pré-requisitos

• O NGINX Ingress Controller baseado no NGINX Plus é criado como um contêiner .
• O Kubernetes está configurado e o segredo de acesso ao registro está disponível para fornecer acesso a um registro privado seguro do Docker .
• O NGINX Ingress Controller baseado no NGINX Plus é implantado via Helm no namespace de entrada .
• Um recurso NGINX VirtualServer é configurado para apontar para o serviço a ser otimizado (geralmente o serviço frontend por padrão). Veja frontend-virtualserver.yaml em nosso repositório GitHut para um exemplo.

Topologia e Configuração

Criamos três instâncias do Opsani. Para as topologias 1 e 2 , usamos o modelo Opsani Dev padrão disponível para todas as contas Opsani e simplesmente fazemos o front-end do application com o NGINX Ingress Controller e apontamos para o serviço do application .

Para a Topologia 3 , usamos o mesmo modelo padrão e modificamos a configuração do Servo com o ConfigMap definido em opsani-manifests-nginx-plus.yaml no repositório GitHub. Assim como no modelo padrão, substituímos valores apropriados para as seguintes variáveis no ConfigMap:

• {{ NAMESPACE }} – Espaço de nomes do recurso de destino
• {{ DEPLOYMENT }} – Implantação de destino
• {{ CONTAINER }} – Nome do contêiner do application de destino

Além disso, definimos OPSANI_ACCOUNT_NAME , OPSANI_APPLICATION_NAME e OPSANI_TOKEN de acordo com o documento exposto com a implantação do application .

Embora o ServoX padrão para Opsani Dev inclua uma instância do Prometheus, implantamos a instância do Prometheus no mesmo namespace do NGINX Ingress Controller para reduzir a necessidade de configuração do ClusterRole.

Também configuramos um serviço para permitir que o pod Servo encontre e consulte a instância correta. Este artefato é abordado em opsani-manifests-nginx-plus.yaml .

Depois que o Bank of Anthos estiver em execução como o application web de exemplo e o Ingress tiver sido verificado, iniciamos a instância do Ingress Prometheus. Por fim, podemos iniciar a otimização do Opsani aplicando o arquivo opsani-manifests-nginx-plus.yaml .