Implantação do NGINX Ingress Controller no Amazon EKS: como testamos

Amir RawdatEngenheiro de Soluções

Na NGINX, estamos sempre buscando maneiras de ajudar você a aproveitar ao máximo nosso software. Nossos resumos de soluções e guias de dimensionamento são um recurso importante que oferecemos. Ao testar empiricamente o desempenho que você pode esperar em diferentes níveis de capacidade computacional, ajudamos você a maximizar o desempenho da entrega de aplicações com a infraestrutura que já possui e a determinar com precisão as despesas operacionais necessárias para o desempenho e a escala que está planejando.

Recentemente, atualizamos o resumo da solução NGINX Ingress Controller com diretrizes de dimensionamento para o Amazon Elastic Kubernetes Service (EKS). O resumo descreve o desempenho que você pode esperar alcançar com o NGINX Ingress Controller em execução em vários tipos de instância no Amazon EKS, juntamente com a estimativa do custo total de propriedade (TCO) mensal. Neste blog, explicamos como chegamos a esses números e fornecemos todas as informações necessárias para você realizar testes semelhantes.

Topologia

O diagrama a seguir mostra a topologia usada nos testes.

• Administrador é o usuário que realiza os testes executando os comandos especificados nas seções a seguir.
• Amazon ECR (Elastic Container Registry) hospeda a imagem oficial do Docker do NGINX Plus Ingress Controller usada nos testes. Consulte Implantação do NGINX Plus Ingress Controller.
• Amazon EC2 (Elastic Compute Cloud) hospeda a imagem c5n.9xlarge em que o wrk é executado, gerando as solicitações. Consulte Metodologia de teste.
• Amazon EKS (Elastic Kubernetes Service) hospeda as imagens c5n.9xlarge do NGINX Plus Ingress Controller e da aplicação de backend. Consulte Como criar o cluster do Amazon EKS.
• NGINX Plus Ingress Controller encaminha as solicitações geradas pelo wrk para a aplicação de backend e retorna as respostas da aplicação. Consulte Implantação do NGINX Plus Ingress Controller.
• Aplicação de backend responde às solicitações encaminhadas pelo NGINX. Consulte Implantação dos pods de backend.

Como criar o cluster do Amazon EKS

Antes de implantar o cluster do EKS, execute estas etapas na máquina local, que é representada pelo ícone Admin no diagrama:

1. Baixe o eksctl, a interface de linha de comando oficial do Amazon EKS. Se você já tiver o eksctl instalado em sua máquina, atualize-o para a versão mais recente.
2. Adicione as credenciais de administrador da AWS apropriadas ao arquivo ${HOME}/.aws/credentials.
3. Baixe os arquivos YAML deste blog em nosso repositório Gist.
4. Baixe rbac.yaml (ou ap-rbac.yaml se você estiver usando o NGINX App Protect) do repositório do NGINX Ingress Controller no GitHub.

Para implantar o cluster do EKS, execute o seguinte comando eksctl na máquina local. (A opção --nodes foi omitida porque, por padrão, o comando cria os dois nós necessários para o teste: um para o NGINX Plus Ingress Controller e outro para a aplicação de backend básica.)

Observação: você pode implantar o cluster do EKS em qualquer região, exceto us-west-1. A assinatura da imagem do NGINX Plus Ingress Controller no Amazon Marketplace for Containers (consulte a próxima seção) não é compatível com essa região.

# eksctl create cluster --instance-types=c5n.9xlarge --managed --ssh-access=true --ssh-public-key=/path/to/public-key

Para se conectar a um nó do cluster via SSH, execute este comando. Durante os testes, você precisa se conectar ao nó do NGINX Plus Ingress Controller para executar o comando htop e verificar se a carga gerada pelo cliente wrk é suficiente para elevar o uso da CPU no nó a 100%.

# ssh -i /path/to/private-key ec2-user@<public-IP-address-of-EKS-node>

Implantando o NGINX Plus Ingress Controller

Implantar o NGINX Plus Ingress Controller no Amazon EKS agora está mais fácil do que nunca.

1. Crie um provedor de identidade (IdP) OIDC para o seu cluster do EKS.

# eksctl utils associate-iam-oidc-provider --region=<eks-cluster-region> --cluster=<eks-cluster-name> --approve

1. Crie iamserviceaccount, o par padrão de Função do IAM e Conta de Serviço (IRSA) para o EKS, e anexe a política do IAM AWSMarketplaceMeteringRegisterUsage para monitorar o uso da imagem do NGINX Plus Ingress Controller e autorizar a implantação. Esse comando cria automaticamente uma Conta de Serviço com uma anotação vinculada a iamserviceaccount.

# eksctl create iamserviceaccount --name <service-account-name> --namespace nginx-ingress --cluster <eks-cluster-name> --region <eks-cluster-region> --attach-policy-arn arn:aws:iam::aws:policy/AWSMarketplaceMeteringRegisterUsage --approve

1. No arquivo YAML do RBAC, edite o valor de name no campo subjects para que corresponda ao service-account-name definido na etapa anterior. Esse valor está na linha 104 do arquivo rbac.yaml e na linha 23 do arquivo ap-rbac.yaml. Edite também o valor do namespace, se necessário (linha 105 ou linha 24), mas o comando acima usa o valor padrão, nginx-ingress.
2. Aplique o arquivo YAML (substitua por ap-rbac.yaml conforme apropriado).

# kubectl apply –f rbac.yaml

1. Instale o cliente Docker na máquina local.
2. Assine a oferta do NGINX Plus Ingress Controller (Edição Premium) no Amazon Marketplace for Containers.
3. Autentique seu cliente Docker no Amazon ECR que hospeda a imagem Docker do NGINX Plus Ingress Controller.
4. Edite os seguintes valores em nginx-ingress.yaml:
   • kubernetes.io/hostname no campo nodeSelector (linha 23) – O rótulo do nó do NGINX Plus Ingress Controller no cluster do EKS, obtido com o comando kubectl get nodes --show-labels command
   • serviceAccountName (linha 24) — O nome da IRSA iamserviceaccount, especificado como service-account-name na Etapa 2.
   • image no campo containers (linha 26) – O local da imagem Docker do NGINX Plus Ingress Controller no Amazon ECR
5. Aplique o manifesto YAML:

# kubectl apply –f nginx-ingress.yaml

Implantando os pods de backend

Siga as etapas abaixo para implantar a aplicação de backend:

1. No arquivo backend-deployment.yaml, edite o valor de kubernetes.io/hostname no campo nodeSelector (linha 15), substituindo-o pelo rótulo obtido com o comando kubectl get nodes --show-labels.
2. Aplique o manifesto YAML:

# kubectl apply –f backend-deployment.yaml

1. Escale a aplicação de backend para três réplicas, o suficiente para lidar com a carga gerada pelo wrk:

# kubectl scale deployment web-server-payload --replicas=3

Metodologia de Testes

Execute o seguinte comando wrk no cliente c5n.9xlarge com AMI hospedado no Amazon EC2, ajustando os valores conforme necessário para que o uso da CPU na instância do NGINX Plus Ingress Controller atinja 100% em cada execução do teste:

# wrk -t <number-of-threads> -c <number-of-connections> -d 180s http[s]://<address-of-NGINX-Plus-Ingress-Controller>

• A opção –c especifica o número de conexões TCP a serem criadas. Defina essa opção conforme necessário para atingir 100% de uso da CPU, com até 500 conexões.
• A opção –d especifica por quanto tempo o tráfego deve ser gerado (a duração de cada execução de teste). Defina essa opção como 180 segundos (3 minutos).
• A opção –t especifica o número de threads a serem criadas. Defina essa opção conforme necessário para atingir 100% de uso da CPU, até o limite de 16 threads (uma para cada CPU usada no cliente durante a execução do teste).

Usamos a versão do wrk disponível no GitHub em julho de 2021 e recomendamos usar a versão atual ao reproduzir os testes.

Execute os testes para coletar duas métricas de desempenho:

• Solicitações por segundo (RPS) – O número de solicitações que o NGINX Plus Ingress Controller pode processar por segundo, calculado como média durante um período fixo. Nesse caso, use o esquema http:// no comando wrk. O NGINX Plus Ingress Controller aceita as solicitações de um arquivo de 1 KB (conteúdo estático) e distribui a carga entre os pods da aplicação de backend. O arquivo tem aproximadamente o tamanho de um pequeno arquivo CSS ou JavaScript, ou de uma imagem muito pequena.
• Transações SSL/TLS por segundo (TPS) – O número de novas conexões HTTPS que o NGINX Plus Ingress Controller pode estabelecer e atender por segundo. Nesse caso, use o esquema https:// no comando wrk. Use RSA com uma chave de 2048 bits e Perfect Forward Secrecy; a cifra SSL é ECDHE-RSA-AES256-GCM-SHA384. O cliente envia uma série de solicitações HTTPS, cada uma em uma nova conexão. O cliente e o NGINX Plus Ingress Controller realizam um handshake TLS para estabelecer uma conexão segura. Em seguida, o NGINX Plus Ingress Controller analisa a solicitação e retorna uma resposta de 0 KB. A conexão é encerrada após a solicitação ser atendida.

Conforme observado em Criação do cluster do Amazon EKS, para simplificar, você pode executar o NGINX Plus Ingress Controller em uma instância c5n.9xlarge em cada execução de teste. Para controlar quantas CPUs ficam disponíveis durante cada execução de teste (de 1 a 36, conforme especificado na tabela em Análise de desempenho), defina o parâmetro da diretiva worker_processes.

Software utilizado

Usamos os seguintes softwares para os testes:

• A máquina cliente executando o wrk gerou o tráfego encaminhado pelo Ingress Controller. Usamos a versão do wrk que estava disponível no GitHub em julho de 2021 e recomendamos usar a versão atual ao reproduzir os testes.
• NGINX Plus Ingress Controller versão 1.11.0
• O Amazon Linux 2 LTS foi executado nas três máquinas com o OpenSSL 1.0.2k–fips

Análise de desempenho

Como mencionado acima, executamos o NGINX Plus Ingress Controller em uma instância c5n.9xlarge em cada teste, usando a diretiva worker_processes para controlar quantas CPUs eram utilizadas. Na tabela abaixo, apresentamos o tipo de instância da família c5n compatível com cada quantidade de CPUs, juntamente com o TCO mensal desse tipo de instância.

A tabela apresenta o número de RPS e TPS de SSL alcançado com diferentes quantidades de CPUs disponíveis para o NGINX Plus Ingress Controller, com base nos testes descritos em Metodologia de testes.

Observe que o número de RPS não aumenta linearmente à medida que o número de CPUs cresce e, na verdade, o percentual de melhoria tende a diminuir conforme o número de CPUs aumenta. A taxa de melhoria cai ainda mais acima de 16 núcleos, pois as instâncias c5n.9xlarge têm hyperthreading habilitado e são equipadas com 18 núcleos e 2 threads por núcleo, totalizando até 36 CPUs. O hyperthreading melhora apenas marginalmente o número de RPS.

A relação entre o TPS de SSL e o número de CPUs também é menos que linear, mas não cai de forma tão acentuada até ultrapassarmos 16 CPUs. O hyperthreading melhora o desempenho de operações paralelizáveis e limitadas pela CPU, como os handshakes de TLS. Por isso, o desempenho do TPS de SSL aumenta mesmo quando ultrapassamos 18 CPUs.

Conclusão

Fornecemos detalhes de implantação que você pode usar para determinar o desempenho esperado do NGINX Plus Ingress Controller em execução no Amazon EKS. Você pode usá-los para testar outras famílias de instâncias do EKS e provisionar uma solução acessível que atenda aos seus requisitos de desempenho e escalabilidade para cargas de trabalho de produção no Kubernetes.

Nossos resultados de RPS HTTP mostram que o ganho percentual de desempenho diminui à medida que dobramos o número de CPUs, convergindo para aproximadamente 300.000 RPS. Os resultados de TPS SSL mostram que o desempenho aumenta de forma quase linear à medida que dobramos o número de CPUs, mesmo quando começamos a usar hyperthreading (dois threads por núcleo), pois os handshakes TLS são limitados pela CPU.

Confira o resumo da solução, teste você mesmo o desempenho do NGINX Plus Ingress Controller e comece hoje mesmo!

Para experimentar o NGINX Ingress Controller com o NGINX Open Source, você pode obter o código-fonte ou baixar um contêiner pré-compilado do DockerHub.

Sobre o autor

Amir RawdatEngenheiro de Soluções

Mais publicações de Amir Rawdat