Déploiement du contrôleur Ingress NGINX sur Amazon EKS : notre méthode de test

Amir RawdatIngénieur solutions

Chez NGINX, nous cherchons constamment des moyens de vous aider à tirer le meilleur parti de nos logiciels. Nos présentations de solutions et guides de dimensionnement constituent une ressource importante que nous mettons à votre disposition. En testant de manière empirique les performances auxquelles vous pouvez vous attendre selon les différents niveaux de puissance de calcul, nous vous aidons à optimiser les performances de mise à disposition des applications avec l’infrastructure dont vous disposez déjà, et à déterminer précisément les dépenses d’exploitation correspondant aux performances et à l’échelle que vous prévoyez.

Nous avons récemment mis à jour la présentation de la solution NGINX Ingress Controller en y ajoutant des recommandations de dimensionnement pour Amazon Elastic Kubernetes Service (EKS). Cette présentation décrit les performances que vous pouvez espérer atteindre avec NGINX Ingress Controller sur différents types d’instances dans Amazon EKS, ainsi que le coût total de possession (TCO) mensuel estimé. Dans cet article de blog, nous expliquons comment nous avons obtenu ces chiffres et vous fournissons toutes les informations nécessaires pour effectuer vous-même des tests similaires.

Topologie

Le schéma suivant présente la topologie utilisée pour les tests.

• L’administrateur est l’utilisateur qui effectue les tests en exécutant les commandes indiquées dans les sections suivantes.
• Amazon ECR (Elastic Container Registry) héberge l’image Docker officielle de NGINX Plus Ingress Controller utilisée pour les tests. Consultez la section « Déploiement de NGINX Plus Ingress Controller ».
• Amazon EC2 (Elastic Compute Cloud) héberge l’image c5n.9xlarge sur laquelle wrk s’exécute et génère les requêtes. Consultez la section « Méthodologie de test ».
• Amazon EKS (Elastic Kubernetes Service) héberge les images c5n.9xlarge pour NGINX Plus Ingress Controller et l’application backend. Consultez la section « 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. Consultez Déploiement de NGINX Plus Ingress Controller.
• Application backend répond aux requêtes transmises par NGINX. Consultez Déploiement des pods backend.

Création du cluster Amazon EKS

Avant de déployer le cluster EKS, effectuez les étapes suivantes sur la machine locale, représentée par l’icône « Admin » dans le schéma :

1. Téléchargez eksctl, l’interface de ligne de commande officielle d’Amazon EKS. Si eksctl est déjà installé sur votre machine, veillez à le mettre à jour vers la dernière version.
2. Ajoutez les identifiants d’administrateur AWS appropriés dans le fichier « ${HOME}/.aws/credentials ».
3. Téléchargez les fichiers YAML de cet article depuis notre dépôt Gist.
4. Téléchargez rbac.yaml (ou ap-rbac.yaml si vous utilisez NGINX App Protect) depuis le dépôt NGINX Ingress Controller sur GitHub.

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

Remarque : vous pouvez déployer le cluster EKS dans n’importe quelle région à l’exception de us-west-1. L’abonnement à l’image de NGINX Plus Ingress Controller dans 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=/path/to/public-key

Pour vous connecter à un nœud du 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 générée par le client wrk suffit à porter l’utilisation du processeur du nœud à 100 %.

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

Déploiement de NGINX Plus Ingress Controller

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

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

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

1. Créez iamserviceaccount, l’association standard d’un rôle IAM et d’un compte de service (IRSA) pour EKS, puis attachez la stratégie IAM AWSMarketplaceMeteringRegisterUsage afin de surveiller l’utilisation de l’image NGINX Plus Ingress Controller et d’autoriser le déploiement. Cette commande crée automatiquement un compte de service avec une annotation qui le lie à 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. Dans le fichier YAML pour le RBAC, modifiez la valeur de name dans le champ subjects afin qu’elle corresponde au service-account-name défini à l’étape précédente. Cette valeur se trouve à 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.
2. Appliquez le fichier YAML (remplacez-le par « ap-rbac.yaml » le cas échéant).

# kubectl apply –f rbac.yaml

1. Installez le logiciel client Docker sur la machine locale.
2. Abonnez-vous à l’offre NGINX Plus Ingress Controller (édition Premium) disponible sur Amazon Marketplace for Containers.
3. Authentifiez votre client Docker auprès d’Amazon ECR, qui héberge l’image Docker de NGINX Plus Ingress Controller.
4. Modifiez les valeurs suivantes dans le fichier nginx-ingress.yaml :
   • kubernetes.io/hostname dans le champ nodeSelector (ligne 23) – Le libellé du nœud du contrôleur Ingress NGINX Plus dans le cluster EKS, obtenu à l’aide de la commande kubectl get nodes --show-labels command
   • serviceAccountName (ligne 24) — Le nom de l’IRSA iamserviceaccount, indiqué sous la forme service-account-name à l’étape 2.
   • image dans le champ containers (ligne 26) – L’emplacement de l’image Docker de NGINX Plus Ingress Controller dans Amazon ECR
5. Appliquez le manifeste YAML :

# kubectl apply –f nginx-ingress.yaml

Déploiement des pods backend

Suivez les étapes ci-dessous 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 la remplaçant par le libellé obtenu à l’aide de la commande kubectl get nodes --show-labels.
2. Appliquez le manifeste YAML :

# kubectl apply –f backend-deployment.yaml

1. Faites passer l’application backend à trois réplicas, ce qui suffit pour gérer la charge générée par « wrk » :

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

Méthodologie de test

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

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

• L’option « –c » spécifie le nombre de connexions TCP à créer. Définissez cette option selon les besoins afin d’atteindre une utilisation du processeur de 100 %, avec un maximum de 500 connexions.
• L’option –d indique la durée pendant laquelle le trafic doit être généré (la durée de chaque exécution du test). Définissez cette option sur 180 secondes (3 minutes).
• L’option –t spécifie le nombre de threads à créer. Définissez cette option selon les besoins afin d’atteindre une utilisation du processeur de 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 pour reproduire les tests.

Exécutez les tests afin de recueillir deux indicateurs de performance :

• Requêtes par seconde (RPS) – Nombre de requêtes que NGINX Plus Ingress Controller peut traiter par seconde, calculé en moyenne sur une période fixe. Dans ce cas, utilisez le schéma http:// dans la commande wrk. NGINX Plus Ingress Controller accepte les requêtes portant sur un fichier de 1 Ko (contenu statique) et les répartit entre les pods de l’application backend. La taille du fichier correspond approximativement à celle d’un petit fichier CSS ou JavaScript, ou d’une très petite image.
• Transactions SSL/TLS par seconde (TPS) – Nombre de nouvelles connexions HTTPS que NGINX Plus Ingress Controller peut établir et traiter par seconde. Dans ce cas, utilisez le schéma https:// dans la commande wrk. Utilisez RSA avec une clé de 2 048 bits et la confidentialité persistante (Perfect Forward Secrecy) ; la suite de 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 afin d’établir une connexion sécurisée, puis NGINX Plus Ingress Controller analyse la requête et renvoie une réponse de 0 Ko. La connexion est fermée une fois la requête traitée.

Comme indiqué dans Création du cluster Amazon EKS, pour plus de simplicité, vous pouvez exécuter le contrôleur Ingress NGINX Plus sur une instance c5n.9xlarge lors de chaque série de tests. Pour contrôler le nombre de processeurs disponibles lors de chaque série de tests (de 1 à 36, comme indiqué dans le tableau de la section Analyse des performances), définissez le paramètre de la directive worker_processes.

Logiciels utilisés

Nous avons utilisé les logiciels suivants pour les tests :

• La machine cliente exécutant « wrk » a généré le trafic transmis par le contrôleur Ingress. Nous avons utilisé la version de « wrk » disponible sur GitHub en juillet 2021 et recommandons d’utiliser la version actuelle pour reproduire les tests.
• Contrôleur Ingress NGINX Plus version 1.11.0
• Amazon Linux 2 LTS s’exécutait sur les trois machines avec OpenSSL 1.0.2k–fips

Analyse des performances

Comme indiqué précédemment, nous avons exécuté le contrôleur Ingress NGINX Plus sur une instance c5n.9xlarge lors de chaque test, en utilisant la directive « worker_processes » pour contrôler le nombre de processeurs utilisés. Le tableau ci-dessous indique le type d’instance de la famille c5n prenant en charge chaque nombre de processeurs, ainsi que le coût total de possession mensuel correspondant.

Le tableau indique le nombre de RPS et de TPS SSL atteint selon le nombre de processeurs disponibles pour NGINX Plus Ingress Controller, d’après les tests décrits dans la section « Méthodologie de test ».

Notez que le nombre de RPS n’augmente pas de manière linéaire avec le nombre de CPU. En réalité, le pourcentage d’amélioration tend à diminuer à mesure que le nombre de CPU augmente. Le taux d’amélioration baisse encore davantage au-delà de 16 cœurs, car les instances c5n.9xlarge prennent en charge l’hyperthreading et sont équipées de 18 cœurs et de 2 threads par cœur, soit jusqu’à 36 CPU au total. L’hyperthreading n’améliore que marginalement le nombre de RPS.

La relation entre le nombre de transactions SSL par seconde (TPS) et le nombre de processeurs n’est pas non plus linéaire, mais les performances ne diminuent pas aussi fortement tant que l’on ne dépasse pas 16 processeurs. L’hyperthreading améliore effectivement les performances des opérations parallélisables fortement tributaires du processeur, telles que les négociations TLS. Par conséquent, le nombre de transactions SSL par seconde continue d’augmenter même au-delà de 18 processeurs.

Conclusion

Nous avons fourni des informations détaillées sur le déploiement afin de vous permettre d’évaluer les performances attendues de NGINX Plus Ingress Controller exécuté dans Amazon EKS. Vous pouvez les utiliser pour tester d’autres familles d’instances EKS et mettre en place une solution abordable répondant à vos exigences de performances et de mise à l’échelle pour les charges de travail de production dans Kubernetes.

Nos résultats concernant le nombre de requêtes HTTP par seconde (RPS) montrent que le pourcentage d’amélioration des performances diminue à mesure que nous doublons le nombre de processeurs, pour converger vers environ 300 000 RPS. Les résultats concernant le nombre de transactions SSL par seconde (TPS) montrent que les performances augmentent de manière presque linéaire lorsque nous doublons le nombre de processeurs, même lorsque nous activons l’hyperthreading (deux threads par cœur), car les négociations TLS sont limitées par les capacités du processeur.

Consultez la présentation de la solution, et testez vous-même les performances de NGINX Plus Ingress Controller – lancez-vous dès maintenant !

Pour essayer NGINX Ingress Controller avec NGINX Open Source, vous pouvez obtenir le code source, ou télécharger une image de conteneur précompilée depuis DockerHub.

À propos de l’auteur

Amir RawdatIngénieur solutions

Autres articles de Amir Rawdat