O Red Hat OpenShift Container Platform (OCP) é uma das plataformas Kubernetes gerenciadas mais populares e, assim como seus concorrentes, o OCP inclui ferramentas de gerenciamento de tráfego padrão para ajudar os usuários a começar rapidamente. O roteador OCP – baseado em HAProxy – é o ponto de entrada padrão para clusters OCP. Ele pode balancear a carga do tráfego HTTP e WebSocket, oferece suporte à terminação TLS e TLS entre o roteador e as instâncias do aplicativo, e pode balancear a carga das conexões TLS em um modo passthrough.
Os clientes costumam nos perguntar: “Por que devo usar o NGINX Ingress Controller no OpenShift quando o roteador está disponível gratuitamente?” Em Por que você precisa de um controlador de entrada de nível empresarial no OpenShift , o blogueiro convidado Max Mortillaro da GigaOm compartilha alguns motivos qualitativos pelos quais você pode querer usar o controlador de entrada NGINX : gerenciamento avançado de tráfego, facilidade de uso, validação JWT e integração WAF. Mas também é importante responder a essa pergunta de um ponto de vista quantitativo, e é por isso que testamos o desempenho do roteador e do controlador de entrada NGINX baseado no NGINX Plus ( nginxinc/kubernetes-ingress ) no ambiente OCP, em uma implantação dinâmica na qual aumentamos e diminuímos o número de servidores upstream (backend) durante o teste.
Quando realizamos testes de desempenho, observamos dois fatores para avaliar o desempenho das ferramentas:
Fator 1: Resultados de latência para implantações dinâmicas
Descobrimos que a métrica mais eficaz para medir a experiência do usuário final em uma implantação dinâmica é a distribuição de percentil de latência. Quanto mais latência um sistema adiciona, mais a experiência do usuário é afetada. Também descobrimos que, para obter uma imagem real da experiência do usuário, as latências nos percentis superiores da distribuição precisam ser incluídas; para uma explicação detalhada, consulte a seção Resultados de desempenho do NGINX e do HAProxy: Testando a experiência do usuário na nuvem em nosso blog.
Fator 2: Tempos limite e erros
Quando um sistema em teste causa latência em uma implantação dinâmica, normalmente é porque o sistema tem problemas para lidar com recarregamentos dinâmicos, apresentando tempos limite ou erros.
Vamos direto à parte interessante e analisar os resultados. Detalhes sobre a topologia e o método de teste seguem.
Conforme discutido acima, consideramos dois fatores ao avaliar o desempenho: latência e tempos limite/erros.
Conforme ilustra o gráfico a seguir, o NGINX Ingress Controller adicionou latência insignificante durante o teste, atingindo um máximo de menos de 700 ms no percentil 99,999. Em contraste, o roteador OCP adicionou latência em percentis bastante baixos, e a latência aumentou exponencialmente até atingir um patamar de pouco mais de 25.000 ms (25 segundos) no percentil 99,99. Isso demonstra que, quando sob carga e com alterações no ambiente do cluster aplicadas com frequência, o roteador pode causar uma experiência ruim ao usuário.
A latência observada acima pode ser atribuída a tempos limite e erros: o roteador OCP produziu 260 tempos limite de conexão e 85 erros de leitura de soquete, enquanto o controlador de entrada NGINX não produziu nenhum. Como vimos em outros testes de desempenho (consulte Teste de desempenho de controladores de entrada NGINX em um ambiente de nuvem Kubernetes dinâmico ), os tempos limite e erros do roteador são causados pela maneira como o HAproxy lida com recarregamentos dinâmicos. O NGINX Ingress Controller baseado no NGINX Plus não causa tempos limite ou erros porque usa a API do NGINX Plus para atualizar dinamicamente a configuração do NGINX quando os endpoints mudam.
Executamos os mesmos testes no NGINX Ingress Controller e no OpenShift Router do sistema em teste (SUT). O SUT encerrou as conexões TLS 1.3 do cliente e encaminhou a solicitação do cliente por uma conexão separada para a implantação de backend.
O cliente foi hospedado em uma máquina separada executando o CentOS 7, localizada na mesma LAN que o cluster OpenShift.
A implantação do SUT e do backend foi executada em um cluster OCP hospedado no VMware vSphere 6.7.0.45100.
Para criptografia TLS, usamos RSA com um tamanho de chave de 2048 bits e Perfect Forward Secrecy.
Cada resposta do aplicativo de backend consistia em cerca de 1 KB de metadados básicos do servidor, juntamente com o 200
OK
Código de status HTTP.
Usando o wrk2 (versão 4.0.0), executamos o seguinte script na máquina cliente, executando o teste por 60 segundos (definido com a opção -d
) a uma taxa de transferência constante de 1000 solicitações por segundo (RPS, definida com a opção -R
):
./wrk -t 2 -c 50 -d 60s -R 1000 -L https:// ingress-url :443/
Realizamos testes com uma implantação dinâmica do aplicativo de backend, usando o seguinte script para aumentar e diminuir o número de réplicas de backend periodicamente. Isso emula um ambiente OpenShift dinâmico e mede a eficácia com que o NGINX Ingress Controller ou o OCP Router se adapta às alterações de endpoint.
enquanto [ 1 -eq 1 ]
fazer
implantação de escala oc nginx-backend --replicas=4
dormir 10
implantação de escala oc nginx-backend --replicas=2
dormir 10
feito
A maioria das empresas que adotam metodologias de microsserviços está impulsionando novos desenvolvimentos por meio de seus pipelines de CI/CD com frequências mais altas do que nunca. Por esse motivo, é crucial que você aproveite um plano de dados que cresça com essas novas metodologias em capacidade e desempenho, sem interromper a experiência do usuário final. Oferecer uma experiência ideal ao usuário final envolve fornecer consistentemente baixa latência para todas as conexões do cliente, em todas as circunstâncias.
Com base nos resultados de desempenho, o NGINX Ingress Controller oferece a experiência ideal ao usuário final em ambientes em contêineres onde a necessidade de iterar e melhorar o desenvolvimento é alta.
Para começar, baixe uma avaliação gratuita do NGINX Ingress Controller e descubra como implantar usando o NGINX Ingress Operator .
"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."