Implantando o NGINX Ingress Controller no Amazon EKS: Como testamos

Na NGINX, estamos constantemente 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 fornecemos. Ao testar empiricamente o desempenho que você pode esperar em diferentes níveis de poder de computação, ajudamos você a maximizar o desempenho de entrega de aplicativos com a infraestrutura que você já tem e a determinar despesas operacionais precisas para o desempenho e a escala para os quais você está se preparando.

Atualizamos recentemente o resumo da solução do 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 o custo total de propriedade (TCO) mensal estimado. Neste blog, explicamos como chegamos a esses números, incluindo todas as informações necessárias para você fazer testes semelhantes.

Topologia

O diagrama a seguir mostra a topologia usada para o teste.

• Admin é o usuário que realiza os testes executando os comandos especificados nas seções a seguir.
• O Amazon ECR (Elastic Container Registry) hospeda a imagem oficial do Docker do NGINX Plus Ingress Controller usada nos testes. Consulte Implantando o NGINX Plus Ingress Controller .
• O Amazon EC2 (Elastic Compute Cloud) hospeda a imagem c5n.9xlarge onde o wrk é executado, gerando as solicitações. Veja Metodologia de Testes .
• O Amazon EKS (Elastic Kubernetes Service) hospeda as imagens c5n.9xlarge para o NGINX Plus Ingress Controller e o aplicativo de backend. Consulte Criando o cluster do Amazon EKS .
• O NGINX Plus Ingress Controller envia por proxy as solicitações geradas pelo wrk para o aplicativo de backend e retorna as respostas do aplicativo. Consulte Implantando o NGINX Plus Ingress Controller .
• O aplicativo de backend responde às solicitações com proxy do NGINX. Veja Implantando os pods de backend .

Criando o cluster Amazon EKS

Antes de implantar o cluster 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 para este blog do nosso repositório Gist.
4. Baixe rbac.yaml (ou ap-rbac.yaml se estiver usando o NGINX App Protect) do repositório do NGINX Ingress Controller no GitHub.

Para implantar o cluster EKS, execute o seguinte comando eksctl na máquina local. (O sinalizador --nodes é omitido porque, por padrão, o comando cria os dois nós necessários para o teste: um para o NGINX Plus Ingress Controller e um para o aplicativo de backend base.)

Observação: Você pode implantar o cluster EKS em qualquer região diferente de 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=/caminho/para/a-chave-publica

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

# ssh -i /caminho/para/a-chave-privada ec2-user@< endereço-IP-público-do-nó-EKS >

Implantando o NGINX Plus Ingress Controller

A implantação do NGINX Plus Ingress Controller no Amazon EKS agora está mais fácil do que nunca.

1. Crie um Provedor de Identidade OIDC (IdP) para seu cluster EKS.

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

2. Crie iamserviceaccount , a função do IAM e a conta de serviço (IRSA) pareadas padrão para 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. Este comando cria automaticamente uma Conta de Serviço com uma anotação vinculada a iamserviceaccount .

   # eksctl create iamserviceaccount --name < nome-da-conta-de-serviço > --namespace nginx-ingress --cluster < nome-do-cluster-eks > --region < região-do-cluster-eks > --attach-policy-arn arn:aws:iam::aws:policy/AWSMarketplaceMeteringRegisterUsage --approve
   

3. No arquivo YAML para RBAC, edite o valor do nome no campo subjects para corresponder ao service-account-name que você definiu na etapa anterior. Isso está na linha 104 em rbac.yaml e na linha 23 em ap-rbac.yaml . Edite também o valor do namespace se necessário (linha 105 ou linha 24), mas o comando acima usa o padrão, nginx-ingress .

4. Aplique o arquivo YAML (substitua ap-rbac.yaml conforme apropriado).

   # kubectl aplicar –f rbac.yaml
   

5. Instale o software cliente Docker na máquina local.

6. Assine a listagem do NGINX Plus Ingress Controller (Premium Edition) no Amazon Marketplace for Containers .

7. Autentique seu cliente Docker com o Amazon ECR que hospeda a imagem Docker do NGINX Plus Ingress Controller.

8. Edite os seguintes valores em nginx-ingress.yaml :

   • kubernetes.io/hostname no campo nodeSelector (linha 23) – O rótulo para o nó do NGINX Plus Ingress Controller no cluster EKS, obtido do comando kubectl get nodes --show-labels
   • serviceAccountName (linha 24) — O nome do iamserviceaccount IRSA, especificado como service-account-name na Etapa 2 .
   • imagem no campo de contêineres (linha 26) – O local da imagem do Docker do NGINX Plus Ingress Controller no Amazon ECR

9. Aplique o manifesto YAML:

   # kubectl aplicar –f nginx-ingress.yaml
   

Implantando os Pods de Backend

Execute as seguintes etapas para implantar o aplicativo de backend:

1. Em backend-deployment.yaml , edite o valor de kubernetes.io/hostname no campo nodeSelector (linha 15), substituindo o rótulo obtido do comando kubectl get nodes --show-labels .

2. Aplique o manifesto YAML:

   # kubectl apply –f implantação de backend.yaml
   

3. Escale o aplicativo de backend até três réplicas, o suficiente para lidar com a carga gerada pelo wrk :

   # kubectl escala implantação web-server-payload --replicas=3
   

Metodologia de Teste

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

# wrk -t < número-de-threads > -c < número-de-conexões > -d 180s http[s]://< endereço-do-controlador-de-entrada-NGINX-Plus >

• A opção –c especifica o número de conexões TCP a serem criadas. Defina esta opção conforme necessário para atingir 100% de uso da CPU, até 500 conexões.
• A opção –d especifica por quanto tempo gerar tráfego (a duração de cada execução de teste). Defina esta opção para 180 segundos (3 minutos).
• A opção –t especifica o número de threads a serem criados. Defina esta opção conforme necessário para atingir 100% de uso da CPU, até 16 threads (um 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 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, com média em um período de tempo fixo. Neste 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 as balanceia entre os pods do aplicativo 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. Neste caso, use o esquema https:// no comando wrk . Use RSA com um tamanho de 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 é fechada após a solicitação ser atendida.

Conforme observado em Criando o 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 estão 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 para a diretiva worker_processes .

Software usado

Utilizamos o seguinte software para os testes:

• A máquina cliente que executa o wrk gerou o tráfego que o Ingress Controller enviou por proxy. 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.
• Controlador NGINX Plus Ingress versão 1.11.0
• O Amazon Linux 2 LTS foi executado em todas as três máquinas com OpenSSL 1.0.2k–fips

Análise de desempenho

Conforme mencionado acima, executamos o NGINX Plus Ingress Controller em uma instância c5n.9xlarge em cada execução de teste, usando a diretiva worker_processes para controlar quantas CPUs foram usadas. Na tabela abaixo, relatamos o tipo de instância na família c5n que suporta cada número de CPUs, juntamente com o TCO mensal para esse tipo de instância.

A tabela relata o número de RPS e SSL TPS alcançados com diferentes números de CPUs disponíveis para o NGINX Plus Ingress Controller, a partir dos testes descritos em Metodologia de Testes .

Observe que os RPS não crescem linearmente com um número maior de CPUs e, de fato, a melhoria percentual tende a diminuir à medida que o número de CPUs aumenta. A taxa de melhoria cai ainda mais acima de 16 núcleos, porque as instâncias c5n.9xlarge são habilitadas com hyperthreading e equipadas com 18 núcleos e 2 threads por núcleo, para até 36 CPUs no total. O hyperthreading melhora apenas marginalmente o número de RPS.

A relação entre SSL TPS e número de CPUs também é menos que linear, mas não cai tão drasticamente até que escalemos além de 16 CPUs. O hyperthreading melhora o desempenho de operações paralelizáveis limitadas à CPU, como handshakes TLS. Por isso, o desempenho do SSL TPS aumenta mesmo quando escalamos mais de 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á-lo para testar outras famílias de instâncias EKS e provisionar uma solução acessível que atenda aos seus requisitos de desempenho e dimensionamento para cargas de trabalho de produção no Kubernetes.

Nossos resultados para HTTP RPS mostram que a porcentagem de melhoria no desempenho diminui à medida que dobramos o número de CPUs, convergindo para aproximadamente 300.000 RPS. Os resultados para SSL TPS mostram que o desempenho aumenta quase linearmente à medida que dobramos o número de CPUs, mesmo quando iniciamos o hyperthreading (usando dois threads por núcleo), porque os handshakes TLS são limitados pela CPU.

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

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