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

Amir Sharif

“É uma tempestade perfeita” pode ser uma expressão comum, mas é bastante apropriada quando se trata de custos descontrolados de computação em nuvem. Vários fatores se somam para criar essa tempestade perfeita:

1. As pessoas que implantam as cargas de trabalho não são as mesmas que pagam por elas
2. É fácil consumir infraestrutura sob demanda e de forma programática
3. Repositórios de código facilmente acessíveis permitem “emprestar” funcionalidades de códigos existentes escritos por outras pessoas
4. Pipelines de CI/CD e práticas de SRE ajudam os desenvolvedores a integrar e implantar código rapidamente

Juntando tudo isso, temos uma situação em que os desenvolvedores são incentivados a implantar rapidamente novas funcionalidades, aproveitando blocos de código existentes que, em geral, não são simplificados nem otimizados para a finalidade que cumprem no novo aplicativo. Como o tempo de lançamento no mercado é fundamental, a otimização fica em segundo plano (bem distante). Se o código não otimizado prejudicar o desempenho, basta uma chamada de API para provisionar uma infraestrutura mais potente. Problema resolvido!

Para agravar o problema, há uma divisão — tanto em termos de mentalidade quanto de estrutura organizacional — entre as pessoas que escrevem o código e as que pagam as contas. À medida que os custos de nuvem da empresa aumentam, o diretor financeiro fica apreensivo. Mas os desenvolvedores que provocaram o aumento das despesas com a nuvem são recompensados pela rapidez na entrega dos produtos, enquanto permanecem tranquilamente alheios aos problemas financeiros subsequentes que foram incentivados a criar.

Para resolver o problema, a F5 NGINX e a Opsani firmaram uma parceria para oferecer uma solução de otimização que proporciona aos assinantes do F5 NGINX Ingress Controller benefícios adicionais em 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, nas quais utiliza o Prometheus para coletar métricas de taxa, erros e duração (RED). A Opsani usa seus recursos de otimização autônoma, baseados em aprendizado de máquina, para otimizar continuamente a infraestrutura e garantir o consumo da quantidade adequada de recursos, proporcionando maior desempenho e menor custo.

Como usar a otimização da nuvem para reduzir custos

Os usuários do NGINX já conhecem a maneira mais básica de reduzir os custos de nuvem: usar ferramentas leves que adicionam latência mínima e, ao mesmo tempo, oferecem um 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 usando três ferramentas:

• NGINX Ingress Controller – Um controlador de Ingress baseado no F5 NGINX Plus que apresenta desempenho substancialmente superior ao de outros controladores de Ingress baseados no NGINX, pois se ajusta dinamicamente às alterações nos endpoints de back-end sem manipuladores de eventos nem recarregamentos de configuração.
• Opsani – Uma solução exclusiva de Otimização Contínua como Serviço (COaaS) que permite adicionar a Otimização Contínua ao seu pipeline de CI/CD, possibilitando entregar código rapidamente e otimizá-lo para obter o melhor desempenho pelo menor custo possível.
• Prometheus – Um projeto popular de código aberto para monitoramento e alertas. Com o módulo Prometheus do NGINX Plus, o NGINX Ingress Controller baseado no NGINXnbsp;Plus exporta centenas de métricas para um servidor Prometheus.

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

Uma análise dos números – Os resultados dos nossos testes de otimização

Vejamos um exemplo dos resultados que você pode esperar ao implantar o NGINX Ingress Controller baseado no NGINX Plus com o Opsani e o Prometheus. Como mostra a captura de tela, a página Resumo do Opsani apresenta 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 referência — neste caso, uma economia de 70% no Custo da instância por hora e uma melhoria de 5% no Tempo de resposta P50.

Queríamos saber como esses resultados se comparariam aos de um dos controladores de Ingress mais conhecidos: o controlador de Ingress baseado no NGINX Open Source, mantido pela comunidade do Kubernetes no repositório do GitHub kubernetes/ingress-nginx. (Seguindo a convenção do NGINX, vamos chamá-lo de “controlador de Ingress da comunidade” no restante deste blog. A versão do NGINX Ingress Controller baseada no NGINX Plus é mantida pela equipe de engenharia do NGINX no repositório do GitHub nginxinc/kubernetes-ingress, juntamente com seu produto irmão, o NGINX Ingress Controller baseado no NGINX Open Source.)

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

• Topologia 1 – Controlador Ingress da comunidade, implantado usando o processo padrão. As métricas foram coletadas adicionando um proxy Envoy em linha com a aplicação em teste, em um contêiner sidecar no pod da aplicação.
  
• Topologia 2 – Controlador de Ingress NGINX baseado no NGINX Plus, implantado usando Helm. As métricas foram coletadas com a mesma implantação e configuração do Envoy usadas no controlador de Ingress da comunidade, para garantir que a coleta de métricas não afetasse o processo de otimização de desempenho.
  

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

A tabela resume os resultados dos testes. Como você pode ver, o NGINX Ingress Controller proporciona maior redução de custos e melhor otimização de CPU e 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 P50 indicam que o Prometheus é a forma ideal de coletar métricas, pois elimina o salto adicional exigido pelo mecanismo de sidecar do Envoy. O Envoy não afeta o tempo de resposta P50 do controlador Ingress da comunidade, mas aumenta a latência em 4% com o NGINX Ingress Controller. Em contrapartida, o Prometheus melhora o tempo de resposta P50 com o NGINX Ingress Controller em 5%.

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

Como a Opsani otimiza o NGINX Ingress Controller

A Opsani pode otimizar aplicações mesmo quando o balanceamento de carga é inadequado em ambientes dinâmicos. Ela também pode utilizar qualquer tipo de entrada de métricas, mas a otimização dos serviços conectados melhora significativamente quando os dados vêm de uma ferramenta existente que coleta métricas de rede. Para isso, usamos um processo simples de implantação para integrar a Opsani ao NGINX Ingress Controller.

Em ambientes em que o NGINX é o controlador de Ingress – o que se aplica a muitas aplicações atualmente –, a simples mudança para o NGINX Ingress Controller baseado no NGINX Plus oferece um algoritmo de balanceamento de carga mais eficiente sem afetar o funcionamento da aplicação. Outro benefício é que as métricas das aplicações cujo balanceamento de carga é realizado pelo NGINX Ingress Controller também ficam disponíveis.

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

Comece a usar o Opsani e o NGINX Ingress Controller

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

Apêndice: Metodologia de testes

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 ingress.
• Um recurso VirtualServer do NGINX é configurado para apontar para o serviço a ser otimizado (geralmente, o serviço de frontend por padrão). Consulte frontend-virtualserver.yaml em nosso repositório do GitHut para ver um exemplo.

Topologia e configuração

Criamos três instâncias do Opsani. Para as Topologias 1 e 2, usamos o modelo padrão Opsani Dev, disponível para todas as contas do Opsani, e simplesmente colocamos o NGINX Ingress Controller na frente da aplicação, apontando-o para o serviço da aplicação.

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 do GitHub. Assim como no modelo padrão, substituímos as seguintes variáveis no ConfigMap pelos valores apropriados:

• {{ NAMESPACE }} – Namespace do recurso de destino
• {{ DEPLOYMENT }} – Implantação de destino
• {{ CONTAINER }} – Nome do contêiner do aplicativo de destino

Além disso, definimos OPSANI_ACCOUNT_NAME, OPSANI_APPLICATION_NAME e OPSANI_TOKEN de acordo com o documento disponibilizado com a implantação da aplicação.

Embora o ServoX padrão para o Opsani Dev inclua uma instância do Prometheus, optamos por implantar a instância do Prometheus no mesmo namespace do NGINX Ingress Controller, reduzindo a necessidade de configurar o ClusterRole.

Também configuramos um serviço para permitir que o pod do Servo encontre e consulte a instância correta. Esse artefato está incluído em opsani-manifests-nginx-plus.yaml.

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

Sobre o autor

Amir Sharif

Mais publicações de Amir Sharif