Équilibrage de charge multi-cluster A/B dynamique et contrôles de sécurité Kubernetes avec NGINX Plus

Vous êtes un ingénieur Platform Ops ou DevOps moderne. Vous utilisez une bibliothèque d’outils open source (et peut-être certains commerciaux) pour tester, déployer et gérer de nouvelles applications et conteneurs pour votre équipe de développement. Vous avez choisi Kubernetes pour exécuter ces conteneurs et pods dans des environnements de développement, de test, de préparation et de production. Vous avez adhéré aux architectures et aux concepts des microservices et, dans la plupart des cas, cela fonctionne plutôt bien. Cependant, vous avez rencontré quelques obstacles tout au long de ce voyage.

Par exemple, lorsque vous créez et déployez de nouveaux clusters, services et applications, comment intégrez-vous ou migrez-vous facilement ces nouvelles ressources en production sans perdre de trafic ? Les appareils réseau traditionnels nécessitent des rechargements ou des redémarrages lors de la mise en œuvre de modifications de configuration des enregistrements DNS, des équilibreurs de charge, des pare-feu et des proxys. Ces ajustements ne sont pas reconfigurables sans provoquer de temps d’arrêt, car une « panne de service » ou une « fenêtre de maintenance » est nécessaire pour mettre à jour les règles DNS, d’équilibrage de charge et de pare-feu. Le plus souvent, vous devez soumettre un ticket de service redouté et attendre qu’une autre équipe approuve et apporte les modifications.

Les fenêtres de maintenance peuvent conduire votre équipe dans un fossé, bloquer la livraison des applications et vous faire déclarer : « Il doit y avoir une meilleure façon de gérer le trafic ! » Alors, explorons une solution qui vous ramènera sur la voie rapide.

Équilibrage de charge multi-cluster actif-actif

Si vous disposez de plusieurs clusters Kubernetes, il est idéal d'acheminer le trafic vers les deux clusters en même temps. Une option encore meilleure consiste à effectuer une répartition du trafic A/B, canari ou bleu-vert et à envoyer un petit pourcentage de votre trafic à titre de test. Pour ce faire, vous pouvez utiliser NGINX Plus avec ngx_http_split_clients_module .

Le module HTTP Split Clients est écrit par NGINX Open Source et permet de répartir le ratio de requêtes en fonction d'une clé. Dans ce cas d'utilisation, les clusters sont les « amonts » de NGINX. Ainsi, à mesure que les demandes des clients arrivent, le trafic est réparti entre deux clusters. La clé utilisée pour déterminer la demande du client est n'importe quelle variable client NGINX disponible. Cela dit, pour contrôler cela pour chaque demande, utilisez la variable $request_id , qui est un numéro unique attribué par NGINX à chaque demande entrante.

Pour configurer les ratios de division, déterminez les pourcentages que vous souhaitez attribuer à chaque cluster. Dans cet exemple, nous utilisons le Cluster1 de K8 comme « grand cluster » pour la production et le Cluster2 comme « petit cluster » pour les tests de pré-production. Si vous disposez d'un petit cluster pour la préparation, vous pouvez utiliser un ratio de 90:10 et tester 10 % de votre trafic sur le petit cluster pour vous assurer que tout fonctionne avant de déployer de nouvelles modifications sur le grand cluster. Si cela semble trop risqué, vous pouvez modifier le ratio à 95:5. En vérité, vous pouvez choisir le ratio que vous souhaitez, entre 0 et 100 %.

Pour la plupart du trafic de production en temps réel, vous souhaitez probablement un ratio de 50:50 où vos deux clusters sont de taille égale. Mais vous pouvez facilement fournir d’autres ratios, en fonction de la taille du cluster ou d’autres détails. Vous pouvez facilement définir le ratio sur 0:100 (ou 100:0) et mettre à niveau, corriger, réparer ou même remplacer un cluster entier sans temps d'arrêt. Laissez NGINX split_clients acheminer les requêtes vers le cluster en direct pendant que vous résolvez les problèmes sur l'autre.

# Équilibrage de charge multi-cluster Nginx
# Configuration des clients HTTP fractionnés pour les ratios Cluster1:Cluster2
# Fournir des ratios de 100, 99, 50, 1, 0 % (ajouter/modifier selon les besoins)
# Basé sur
# https://www.nginx.com/blog/dynamic-a-b-testing-with-nginx-plus/
# Chris Akker – Jan 2024
#

split_clients $request_id $split100 {
* cluster1-cafe; # Tout le trafic vers cluster1
} 

split_clients $request_id $split99 {
99% cluster1-cafe; # 99% cluster1, 1% cluster2
* cluster2-cafe;
} 

split_clients $request_id $split50 { 
50% cluster1-cafe; # 50 % cluster1, 50 % cluster2
* cluster2-cafe ;
}

split_clients $request_id $split1 { 
1,0 % cluster1-cafe ; # 1 % vers cluster1, 99 % vers cluster2
* cluster2-cafe ;
}

split_clients $request_id $split0 { 
* cluster2-cafe ; # Tout le trafic vers cluster2
}

# Choisissez le cluster en amont en fonction du ratio

map $split_level $upstream { 
100 $split100 ; 
99 $split99 ; 
50 $split50 ; 
1,0 $split1 ; 
0 $split0 ;
par défaut $split50 ;
}

Vous pouvez ajouter ou modifier la configuration ci-dessus pour qu'elle corresponde aux ratios dont vous avez besoin (par exemple, 90:10, 80:20, 60:40, etc.).

Note: NGINX dispose également d'un module Split Clients pour les connexions TCP dans le contexte de flux, qui peut être utilisé pour le trafic non HTTP. Cela divise le trafic en fonction des nouvelles connexions TCP, au lieu des requêtes HTTP.
 

Magasin de clés et de valeurs NGINX Plus

La prochaine fonctionnalité que vous pouvez utiliser est le magasin de clés-valeurs NGINX Plus. Il s’agit d’un objet clé-valeur dans une zone de mémoire partagée NGINX qui peut être utilisé pour de nombreux cas d’utilisation de stockage de données différents. Ici, nous l'utilisons pour stocker la valeur du rapport de division mentionnée dans la section ci-dessus. NGINX Plus vous permet de modifier n'importe quel enregistrement clé-valeur sans recharger NGINX. Cela vous permet de modifier cette valeur de division avec un appel API, créant ainsi la fonction de division dynamique.

D'après notre exemple, cela ressemble à ceci :

{“cafe.exemple.com”:90}

Cet enregistrement KeyVal indique :
La clé est le nom d'hôte « cafe.example.com »
La valeur est « 90 » pour le ratio de division

Au lieu de coder en dur le rapport de division dans les fichiers de configuration NGINX, vous pouvez utiliser à la place la mémoire clé-valeur. Cela élimine le rechargement NGINX requis pour modifier une valeur de division statique dans NGINX.

Dans cet exemple, NGINX est configuré pour utiliser 90:10 pour le rapport de division avec le grand Cluster1 pour les 90 % et le petit Cluster2 pour les 10 % restants. Comme il s’agit d’un enregistrement clé-valeur, vous pouvez modifier ce ratio à l’aide de l’API NGINX Plus de manière dynamique sans rechargement de configuration ! Le module Split Clients utilisera cette nouvelle valeur de ratio dès que vous la modifierez, lors de la prochaine requête.

Créez l'enregistrement KV, commencez avec un ratio 50/50 :

Ajoutez un nouvel enregistrement au magasin KeyValue en envoyant une commande API à NGINX Plus :

curl -iX POST -d '{"cafe.exemple.com":50}' http://nginxlb:9000/api/8/http/keyvals/split

Changer l'enregistrement KV, passer au ratio 90/10 :

Modifiez le ratio de division KeyVal à 90, en utilisant une méthode HTTP PATCH pour mettre à jour l'enregistrement KeyVal en mémoire :

curl -iX PATCH -d '{"cafe.exemple.com":90}' http://nginxlb:9000/api/8/http/keyvals/split

Ensuite, l’équipe de test de pré-production vérifie que le nouveau code d’application est prêt, vous le déployez sur le grand Cluster1 et modifiez le ratio à 100 %. Cela envoie immédiatement tout le trafic vers Cluster1 et votre nouvelle application est « active » sans aucune interruption du trafic, sans interruption de service, sans fenêtres de maintenance, sans redémarrages, sans rechargements ou sans nombreux tickets. Il suffit d'un seul appel API pour modifier ce rapport de répartition au moment de votre choix.

Bien sûr, le fait qu'il soit si facile de passer de 90 % à 100 % signifie que vous disposez d'un moyen simple de modifier le ratio de 100:0 à 50:50 (ou même 0:100). Vous pouvez donc disposer d’un cluster de sauvegarde à chaud ou faire évoluer vos clusters horizontalement avec de nouvelles ressources. À plein régime, vous pouvez même créer entièrement un nouveau cluster avec les derniers correctifs logiciels, matériels et logiciels, en déployant l'application et en migrant le trafic sur une période donnée sans interrompre une seule connexion !

Cas d'utilisation

L'utilisation du module HTTP Split Clients avec le magasin de clés-valeurs dynamiques peut fournir les cas d'utilisation suivants :

• Équilibrage de charge actif-actif – Pour équilibrer la charge sur plusieurs clusters.
• Équilibrage de charge actif-passif – Pour équilibrer la charge vers les clusters et applications principaux, de sauvegarde et de reprise après sinistre.
• Tests A/B, bleu-vert et canari – Utilisés avec les nouvelles applications Kubernetes.
• Mise à l'échelle horizontale du cluster : ajoute davantage de ressources au cluster et modifie le ratio lorsque vous êtes prêt.
• Mises à niveau de cluster sans interruption – Possibilité d’utiliser un cluster pendant que vous mettez à niveau, corrigez ou réparez l’autre cluster.
• Basculement instantané – Si un cluster présente un problème grave, vous pouvez modifier le ratio pour utiliser votre autre cluster.

Exemples de configuration

Voici un exemple de configuration clé-valeur :

# Définir le magasin de valeurs clés, le fichier d'état de sauvegarde, le délai d'expiration et activer la synchronisation 
keyval_zone zone=split:1m state=/var/lib/nginx/state/split.keyval timeout=365d sync;

keyval $host $split_level zone=split;

Et voici un exemple de configuration de l'application cafe.example.com :

# Définir les blocs de serveur et d'emplacement pour cafe.example.com, avec TLS server { listen 443 ssl; server_name cafe.example.com; status_zone https://cafe.example.com; ssl_certificate /etc/ssl/nginx/cafe.example.com.crt; ssl_certificate_key /etc/ssl/nginx/cafe.example.com.key; location / { status_zone /; proxy_set_header Host $host; proxy_http_version 1.1; proxy_set_header "Connection" ""; proxy_pass https://$upstream; # Répartition du trafic en blocs en amont } # Définir 2 blocs en amont – un pour chaque cluster # Serveurs gérés dynamiquement par NLK, sauvegarde du fichier d'état # Cluster1 upstreams upstream cluster1-cafe { zone cluster1-cafe 256k; least_time last_byte; keepalive 16; #serveurs gérés par l'état du contrôleur NLK /var/lib/nginx/state/cluster1-cafe.state; } # Cluster2 en amont cluster2-cafe { zone cluster2-cafe 256k; least_time last_byte; keepalive 16; #serveurs gérés par l'état du contrôleur NLK /var/lib/nginx/state/cluster2-cafe.state; }

Les ports IP du serveur en amont sont gérés par NGINX Loadbalancer pour Kubernetes , un nouveau contrôleur qui utilise également l'API NGINX Plus pour configurer NGINX Plus de manière dynamique. Les détails sont dans la section suivante .

Jetons un œil au trafic HTTP réparti au fil du temps avec Grafana , un outil de surveillance et de visualisation populaire. Vous utilisez NGINX Prometheus Exporter (basé sur njs ) pour exporter toutes vos métriques NGINX Plus, qui sont ensuite collectées et représentées graphiquement par Grafana. Les détails de configuration de Prometheus et Grafana peuvent être trouvés ici .

Il y a quatre serveurs en amont dans le graphique : Deux pour Cluster1 et deux pour Cluster2 . Nous utilisons un outil de génération de charge HTTP pour créer des requêtes HTTP et les envoyer à NGINX Plus.

Dans les trois graphiques ci-dessous, vous pouvez voir que le ratio de répartition est de 50:50 au début du graphique.

Ensuite, le ratio passe à 10:90 à 12:56:30.

Puis il passe à 90:10 à 13:00:00.

Vous pouvez trouver des configurations fonctionnelles de Prometheus et Grafana sur le référentiel GitHub NGINX Loadbalancer pour Kubernetes .

Flux montants HTTP dynamiques : Équilibreur de charge NGINX pour Kubernetes

Vous pouvez modifier la configuration NGINX Upstream statique en clusters dynamiques en amont à l'aide de l'API NGINX Plus et du contrôleur NGINX Loadbalancer pour Kubernetes . Ce projet gratuit est un contrôleur Kubernetes qui surveille NGINX Ingress Controller et met automatiquement à jour une instance NGINX Plus externe configurée pour l'équilibrage de charge TCP/HTTP. Sa conception est très simple et il est facile à installer et à utiliser. Avec cette solution en place, vous pouvez implémenter l'équilibrage de charge TCP/HTTP dans les environnements Kubernetes, garantissant que les nouvelles applications et services sont immédiatement détectés et disponibles pour le trafic, sans aucun rechargement nécessaire.

Architecture et flux

L'équilibreur de charge NGINX pour Kubernetes se trouve à l'intérieur d'un cluster Kubernetes. Il est enregistré auprès de Kubernetes pour surveiller le service NGINX Ingress Controller ( nginx-ingress ). Lorsqu'une modification est apportée aux contrôleurs d'entrée, NGINX Loadbalancer pour Kubernetes collecte les adresses IP des travailleurs et les numéros de port TCP NodePort, puis envoie les adresses IP : ports à NGINX Plus via l' API NGINX Plus .

Les serveurs en amont NGINX sont mis à jour sans rechargement requis, et NGINX Plus équilibre la charge du trafic vers les serveurs en amont et les NodePorts Kubernetes appropriés. Des instances NGINX Plus supplémentaires peuvent être ajoutées pour atteindre une haute disponibilité .

Un aperçu de NGINX Loadbalancer pour Kubernetes en action

Dans la capture d'écran ci-dessous, il y a deux fenêtres qui montrent que NGINX Loadbalancer pour Kubernetes est déployé et fait son travail :

1. Type de service – LoadBalancer pour nginx-ingress
2. IP externe – Se connecte aux serveurs NGINX Plus
3. Ports – NodePort est mappé à 443:30158 avec les serveurs NGINX en amont correspondants (comme indiqué dans le tableau de bord en temps réel de NGINX Plus)
4. Journaux – Indique que NGINX Loadbalancer pour Kubernetes envoie correctement les données à NGINX Plus

Note : Dans cet exemple, les nœuds de travail Kubernetes sont 10.1.1.8 et 10.1.1.10

Ajout des fonctionnalités de sécurité NGINX Plus

À mesure que de plus en plus d’applications exécutées dans Kubernetes sont exposées à l’Internet ouvert, la sécurité devient nécessaire. Heureusement, NGINX Plus dispose de fonctionnalités de sécurité de classe entreprise qui peuvent être utilisées pour créer une architecture de défense en profondeur à plusieurs niveaux.

Avec NGINX Plus devant vos clusters et exécutant la fonction split_clients , pourquoi ne pas tirer parti de cette présence et ajouter des fonctionnalités de sécurité bénéfiques ? Voici quelques-unes des fonctionnalités de NGINX Plus qui pourraient être utilisées pour améliorer la sécurité, avec des liens et des références vers d'autres documentations qui peuvent être utilisées pour les configurer, les tester et les déployer.

• Listes de blocage/autorisation IP – Contrôle l’accès en fonction de l’adresse IP source. Vous pouvez trouver un guide de configuration sur l'utilisation du magasin de clés-valeurs NGINX Plus pour les listes de blocage/d'autorisation d'adresses IP dynamiques à l'aide de l'API Plus sur la page Liste de blocage dynamique des adresses IP dans la documentation NGINX.
• Limitation du débit – Contrôle le nombre de connexions TCP, de requêtes HTTP et l’utilisation de la bande passante pour les applications, les points de terminaison API et les téléchargements multimédias. Pour plus d'informations sur la limitation de débit avec NGINX, consultez la section Limitation de l'accès aux ressources HTTP proxy dans la documentation NGINX et les articles de blog Limitation de débit avec NGINX et NGINX Plus et Limites de bande passante dynamiques à l'aide du magasin de clés-valeurs NGINX Plus .
• Module dynamique GeoIP2 – Collecte les métadonnées de localisation en fonction de l’adresse IP source. Pour en savoir plus à ce sujet, consultez la page Restriction de l’accès par emplacement géographique dans la documentation NGINX.
• Module JWT et OpenID Connect (OIDC) – Contrôle l'accès des utilisateurs avec des protocoles standard de l'industrie. Vous trouverez plus d’informations à ce sujet sur la page Configuration de l’authentification JWT dans la documentation NGINX.
• NGINX App Protect – Un pare-feu d’application Web léger et à faible latence qui protège contre les menaces existantes et en évolution.

Commencez dès aujourd'hui

Si vous êtes frustré par les défis de mise en réseau à la périphérie de votre cluster Kubernetes, envisagez d'essayer cette solution multi-cluster NGINX. Essayez le logiciel NGINX Loadbalancer pour Kubernetes et dites-nous ce que vous en pensez. Le code source est open source (sous licence Apache 2.0) et toutes les instructions d'installation sont disponibles sur GitHub .

Pour nous faire part de vos commentaires, laissez-nous un commentaire dans le dépôt ou envoyez-nous un message sur le Slack de la communauté NGINX .