Déploiement du contrôleur d'entrée NGINX sur Amazon EKS : Comment nous avons testé

Chez NGINX, nous recherchons constamment des moyens de vous aider à tirer le meilleur parti de nos logiciels. Nos fiches de solutions et nos guides de dimensionnement sont une ressource importante que nous fournissons. En testant empiriquement les performances que vous pouvez attendre à différents niveaux de puissance de calcul, nous vous aidons à maximiser les performances de distribution d'applications avec l'infrastructure dont vous disposez déjà et à déterminer les dépenses d'exploitation précises pour les performances et l'échelle auxquelles vous vous préparez.

Nous avons récemment mis à jour la fiche de solution NGINX Ingress Controller avec des directives de dimensionnement pour Amazon Elastic Kubernetes Service (EKS). Le dossier décrit les performances que vous pouvez espérer obtenir avec le contrôleur d'entrée NGINX exécuté sur différents types d'instances dans Amazon EKS, ainsi que le coût total de possession (TCO) mensuel estimé. Dans ce blog, nous expliquons comment nous sommes arrivés à ces chiffres, y compris toutes les informations dont vous avez besoin pour effectuer vos propres tests similaires.

Topologie

Le diagramme suivant montre la topologie utilisée pour les tests.

• L'administrateur est l'utilisateur qui effectue les tests en exécutant les commandes spécifiées dans les sections suivantes.
• Amazon ECR (Elastic Container Registry) héberge l'image Docker officielle du contrôleur d'entrée NGINX Plus utilisée dans les tests. Voir Déploiement de NGINX Plus Ingress Controller .
• Amazon EC2 (Elastic Compute Cloud) héberge l'image c5n.9xlarge où wrk s'exécute, générant les requêtes. Voir Méthodologie de test .
• Amazon EKS (Elastic Kubernetes Service) héberge les images c5n.9xlarge pour NGINX Plus Ingress Controller et l'application backend. Voir Création du cluster Amazon EKS .
• NGINX Plus Ingress Controller transmet les requêtes générées par wrk à l'application backend et renvoie les réponses de l'application. Voir Déploiement de NGINX Plus Ingress Controller .
• L'application back-end répond aux requêtes transmises par proxy par NGINX. Voir Déploiement des pods back-end .

Création du cluster Amazon EKS

Avant de déployer le cluster EKS, effectuez ces étapes sur la machine locale, représentée par l’icône Admin dans le diagramme :

1. Téléchargez eksctl , l'interface de ligne de commande officielle pour Amazon EKS. Si vous avez déjà installé eksctl sur votre machine, assurez-vous de le mettre à jour vers la dernière version.
2. Ajoutez les informations d’identification d’administrateur AWS appropriées au fichier ${HOME}/.aws/credentials .
3. Téléchargez les fichiers YAML pour ce blog depuis notre dépôt Gist.
4. Téléchargez rbac.yaml (ou ap-rbac.yaml si vous utilisez NGINX App Protect) depuis le référentiel NGINX Ingress Controller sur GitHub.

Pour déployer le cluster EKS, exécutez la commande eksctl suivante sur la machine locale. (L'indicateur --nodes est omis, car par défaut, la commande crée les deux nœuds nécessaires aux tests : un pour NGINX Plus Ingress Controller et un pour l'application backend de base.)

Note: Vous pouvez déployer le cluster EKS dans n’importe quelle région autre que us-west-1 . L'abonnement à l'image NGINX Plus Ingress Controller sur Amazon Marketplace for Containers (voir la section suivante ) n'est pas pris en charge dans cette région.

# eksctl create cluster --instance-types=c5n.9xlarge --managed --ssh-access=true --ssh-public-key=/chemin/vers/clé-publique

Pour vous connecter à un nœud de cluster via SSH, exécutez cette commande. Pendant les tests, vous devez vous connecter au nœud NGINX Plus Ingress Controller pour exécuter la commande htop et vérifier que la charge du client wrk est suffisante pour porter l'utilisation du processeur sur le nœud à 100 %.

# ssh -i /chemin/vers/clé-privée ec2-user@< adresse-IP-publique-du-nœud-EKS >

Déploiement du contrôleur d'entrée NGINX Plus

Le déploiement du contrôleur d'entrée NGINX Plus sur Amazon EKS est désormais plus simple que jamais.

1. Créez un fournisseur d’identité OIDC (IdP) pour votre cluster EKS.

   # eksctl utils associate-iam-oidc-provider --region=< région-cluster-eks > --cluster=< nom-cluster-eks > --approve
   

2. Créez iamserviceaccount , le compte de service et de rôle IAM (IRSA) standard associé pour EKS, et attachez la stratégie IAM AWSMarketplaceMeteringRegisterUsage pour surveiller l'utilisation de l'image NGINX Plus Ingress Controller et autoriser le déploiement. Cette commande crée automatiquement un compte de service avec une annotation liée à iamserviceaccount .

   # eksctl create iamserviceaccount --name < nom-du-compte-de-service > --namespace nginx-ingress --cluster < nom-du-cluster-eks > --region < région-du-cluster-eks > --attach-policy-arn arn:aws:iam::aws:policy/AWSMarketplaceMeteringRegisterUsage --approve
   

3. Dans le fichier YAML pour RBAC, modifiez la valeur du nom dans le champ sujets pour qu’elle corresponde au nom du compte de service que vous avez défini à l’étape précédente. Ceci se trouve sur la ligne 104 dans rbac.yaml et la ligne 23 dans ap-rbac.yaml . Modifiez également la valeur de l'espace de noms si nécessaire (ligne 105 ou ligne 24), mais la commande ci-dessus utilise la valeur par défaut, nginx-ingress .

4. Appliquez le fichier YAML (remplacez ap-rbac.yaml si nécessaire).

   # kubectl apply –f rbac.yaml
   

5. Installez le logiciel client Docker sur la machine locale.

6. Abonnez-vous à la liste NGINX Plus Ingress Controller (Premium Edition) sur Amazon Marketplace pour les conteneurs .

7. Authentifiez votre client Docker avec Amazon ECR qui héberge l’image Docker du contrôleur d’entrée NGINX Plus.

8. Modifiez les valeurs suivantes dans nginx-ingress.yaml :

   • kubernetes.io/hostname dans le champ nodeSelector (ligne 23) – L'étiquette du nœud NGINX Plus Ingress Controller dans le cluster EKS, obtenue à partir de la commande kubectl get nodes --show-labels
   • serviceAccountName (ligne 24) — Le nom du compte iamserviceaccount IRSA, spécifié comme service-account-name à l'étape 2 .
   • image dans le champ conteneurs (ligne 26) – L'emplacement de l'image Docker du contrôleur d'entrée NGINX Plus dans Amazon ECR

9. Appliquer le manifeste YAML :

   # kubectl apply –f nginx-ingress.yaml
   

Déploiement des pods backend

Procédez comme suit pour déployer l’application backend :

1. Dans backend-deployment.yaml , modifiez la valeur de kubernetes.io/hostname dans le champ nodeSelector (ligne 15), en remplaçant l'étiquette obtenue à partir de la commande kubectl get nodes --show-labels .

2. Appliquer le manifeste YAML :

   # kubectl apply –f déploiement-backend.yaml
   

3. Faites évoluer l'application backend jusqu'à trois répliques, suffisamment pour gérer la charge générée par wrk :

   # déploiement à l'échelle de kubectl web-server-payload --replicas=3
   

Méthodologie de test

Exécutez la commande wrk suivante sur l'AMI client c5n.9xlarge hébergée dans Amazon EC2, en ajustant les valeurs selon les besoins pour que l'utilisation du processeur sur l'instance NGINX Plus Ingress Controller atteigne 100 % à chaque exécution de test :

# wrk -t < nombre-de-threads > -c < nombre-de-connexions > -d 180s http[s]://< adresse-du-contrôleur-d'entrée-NGINX-Plus >

• L'option –c spécifie le nombre de connexions TCP à créer. Définissez cette option selon vos besoins pour atteindre une utilisation du processeur à 100 %, jusqu'à 500 connexions.
• L'option –d spécifie la durée de génération du trafic (la durée de chaque exécution de test). Réglez cette option sur 180 secondes (3 minutes).
• L'option –t spécifie le nombre de threads à créer. Définissez cette option selon vos besoins pour atteindre une utilisation du processeur à 100 %, jusqu'à 16 threads (un pour chaque processeur utilisé sur le client pendant l'exécution du test).

Nous avons utilisé la version de wrk disponible sur GitHub en juillet 2021 et recommandons d'utiliser la version actuelle lors de la reproduction des tests.

Exécutez des tests pour collecter deux mesures de performances :

• Requêtes par seconde (RPS) – Le nombre de requêtes que NGINX Plus Ingress Controller peut traiter par seconde, en moyenne sur une période de temps fixe. Dans ce cas, utilisez le schéma http:// dans la commande wrk .

  NGINX Plus Ingress Controller accepte les demandes pour un fichier de 1 Ko (contenu statique) et équilibre la charge entre les pods d'application back-end. Le fichier a à peu près la taille d’un petit fichier CSS ou JavaScript, ou d’une très petite image.

• Transactions SSL/TLS par seconde (TPS) – Le nombre de nouvelles connexions HTTPS que NGINX Plus Ingress Controller peut établir et servir par seconde. Dans ce cas, utilisez le schéma https:// dans la commande wrk . Utilisez RSA avec une taille de clé de 2048 bits et Perfect Forward Secrecy ; le chiffrement SSL est ECDHE-RSA-AES256-GCM-SHA384 .

  Le client envoie une série de requêtes HTTPS, chacune sur une nouvelle connexion. Le client et NGINX Plus Ingress Controller effectuent une négociation TLS pour établir une connexion sécurisée, puis NGINX Plus Ingress Controller analyse la demande et renvoie une réponse de 0 Ko . La connexion est fermée une fois la demande satisfaite.

Comme indiqué dans Création du cluster Amazon EKS , pour plus de simplicité, vous pouvez exécuter le contrôleur d’entrée NGINX Plus sur une instance c5n.9xlarge à chaque exécution de test. Pour contrôler le nombre de processeurs disponibles pendant chaque exécution de test (de 1 à 36 comme spécifié dans le tableau de l'analyse des performances ), définissez le paramètre sur la directive worker_processes .

Logiciels utilisés

Nous avons utilisé le logiciel suivant pour les tests :

• La machine cliente exécutant wrk a généré le trafic que le contrôleur d’entrée a proxy. Nous avons utilisé la version de wrk disponible sur GitHub en juillet 2021 et recommandons d'utiliser la version actuelle lors de la reproduction des tests.
• Contrôleur d'entrée NGINX Plus version 1.11.0
• Amazon Linux 2 LTS fonctionnait sur les trois machines avec OpenSSL 1.0.2k–fips

Analyse des performances

Comme mentionné ci-dessus, nous avons exécuté le contrôleur d’entrée NGINX Plus sur une instance c5n.9xlarge à chaque exécution de test, en utilisant la directive worker_processes pour contrôler le nombre de processeurs utilisés. Dans le tableau ci-dessous, nous signalons le type d'instance de la famille c5n qui prend en charge chaque nombre de CPU, ainsi que le TCO mensuel pour ce type d'instance.

Le tableau indique le nombre de RPS et de TPS SSL obtenus avec différents nombres de CPU disponibles pour NGINX Plus Ingress Controller, à partir des tests décrits dans la méthodologie de test .

Notez que les RPS ne croissent pas de manière linéaire avec un nombre plus important de CPU, et en fait, le pourcentage d'amélioration a tendance à diminuer à mesure que le nombre de CPU augmente. Le taux d'amélioration diminue encore plus au-dessus de 16 cœurs, car les instances c5n.9xlarge sont activées avec l'hyperthreading et équipées de 18 cœurs et de 2 threads par cœur, pour un total de 36 CPU. L'hyperthreading n'améliore que marginalement le nombre de RPS.

La relation entre le TPS SSL et le nombre de processeurs est également moins que linéaire, mais ne diminue pas de manière aussi spectaculaire jusqu'à ce que nous dépassions 16 processeurs. L'hyperthreading améliore les performances des opérations parallélisables liées au processeur telles que les négociations TLS. De ce fait, les performances du SSL TPS augmentent même lorsque nous dépassons 18 CPU.

Conclusion

Nous avons fourni des détails de déploiement que vous pouvez utiliser pour déterminer les performances attendues du contrôleur d'entrée NGINX Plus exécuté dans Amazon EKS. Vous pouvez l'utiliser pour tester d'autres familles d'instances EKS et pour fournir une solution abordable qui répond à vos exigences de performances et de mise à l'échelle pour les charges de travail de production dans Kubernetes.

Nos résultats pour HTTP RPS montrent que le pourcentage d’amélioration des performances diminue à mesure que nous doublons le nombre de processeurs, convergeant vers environ 300 000 RPS. Les résultats pour SSL TPS montrent que les performances augmentent presque linéairement à mesure que nous doublons le nombre de processeurs, même lorsque nous commençons l'hyperthreading (en utilisant deux threads par cœur) car les poignées de main TLS sont liées au processeur.

Consultez la présentation de la solution et testez par vous-même les performances du contrôleur d’entrée NGINX Plus – commencez dès aujourd’hui !

Pour essayer le contrôleur d'entrée NGINX avec NGINX Open Source, vous pouvez obtenir le code source ou télécharger un conteneur prédéfini depuis DockerHub .