Comment simplifier la gestion du trafic entrant et sortant de Kubernetes

L’une des façons dont un maillage de services peut réellement compliquer la gestion d’un environnement Kubernetes est lorsqu’il doit être configuré séparément du contrôleur Ingress . Les configurations séparées ne prennent pas non plus beaucoup de temps. Ils augmentent la probabilité d'erreurs de configuration qui peuvent empêcher le routage correct du trafic et même conduire à des vulnérabilités de sécurité (comme des acteurs malveillants accédant à des applications restreintes) et à de mauvaises expériences (comme des clients ne pouvant pas accéder aux applications pour lesquelles ils sont autorisés). Au-delà du temps nécessaire pour effectuer des configurations séparées, vous finissez par passer plus de temps à résoudre les erreurs.

Vous pouvez éviter ces problèmes et gagner du temps en intégrant le contrôleur d’entrée NGINX basé sur NGINX Plus avec NGINX Service Mesh pour contrôler le trafic mTLS entrant et sortant. Dans cette vidéo de démonstration, nous couvrons les étapes complètes.

La documentation complémentaire est référencée dans les sections suivantes :

• Prérequis
• Déploiement du contrôleur d'entrée NGINX avec NGINX Service Mesh
• Utilisation d'une ressource d'entrée Kubernetes standard pour exposer l'application
• Utilisation d'une ressource NGINX VirtualServer pour exposer l'application
• Configuration d'une route de sortie sécurisée avec le contrôleur d'entrée NGINX

Prérequis (0:18)

Avant de commencer la démonstration proprement dite, nous avons effectué ces prérequis :

1. J'ai installé le plan de contrôle NGINX Server Mesh dans le cluster Kubernetes et configuré mTLS et la politique stricte pour le service mesh .

2. J'ai installé le contrôleur d'entrée NGINX basé sur NGINX Plus en tant que déploiement (plutôt qu'un DaemonSet) dans le cluster Kubernetes, j'ai activé egress et je l'ai exposé en tant que service de type LoadBalancer .

   Note: La démo ne fonctionne pas avec le contrôleur d’entrée NGINX Open Source basé sur NGINX. Pour faciliter la lecture, nous désignons le contrôleur d'entrée NGINX basé sur NGINX Plus simplement par « contrôleur d'entrée NGINX » dans le reste de ce blog.

3. Suivez nos instructions pour télécharger l’exemple d’application bookinfo , injecter le sidecar NGINX Service Mesh et déployer l’application.

En raison de la politique stricte créée à l’étape 1, les demandes adressées à l’application bookinfo par des clients extérieurs au maillage sont refusées au niveau du side-car. Nous illustrons cela dans la démonstration en exécutant d’abord la commande suivante pour configurer la redirection de port :

> kubectl port-forward svc/product-page 9080 Transfert depuis 127.0.0.1:9080 -> 9080 Transfert depuis [::1]:9080 -> 9080 Gestion de la connexion pour 9080

Lorsque nous essayons d'accéder à l'application, nous obtenons un code d'état503 parce que notre machine locale ne fait pas partie du service mesh :

> curl localhost:9080503

Déploiement de NGINX Ingress Controller avec NGINX Service Mesh (1:50)

La première étape du processus d’exposition d’une application consiste à déployer une instance NGINX Ingress Controller. Les instructions correspondantes sont fournies dans notre didacticiel, Déployer avec NGINX Plus Ingress Controller pour Kubernetes .

NGINX fournit à la fois des manifestes de déploiement et de DaemonSet à cette fin. Dans la démo, nous utilisons le manifeste de déploiement, nginx-plus-ingress.yaml . Il inclut des annotations pour acheminer le trafic entrant et sortant via la même instance de contrôleur d'entrée NGINX :

Le manifeste permet l'intégration directe de NGINX Ingress Controller avec Spire, l'autorité de certification (CA) pour NGINX Service Mesh, éliminant ainsi le besoin d'injecter le sidecar NGINX Service Mesh dans NGINX Ingress Controller. Au lieu de cela, NGINX Ingress Controller récupère les certificats et les clés directement auprès de l'autorité de certification Spire à utiliser pour mTLS avec les pods du maillage. Le manifeste spécifie l'adresse de l'agent Spire :

et monte le socket UNIX de l'agent Spire sur le pod NGINX Ingress Controller :

La dernière chose à noter à propos du manifeste est l’argument CLI -enable-internal-routes , qui nous permet d’acheminer vers les services de sortie :

Avant de commencer la démonstration, nous avons exécuté la commande kubectl apply -f nginx-plus-ingress.yaml pour installer NGINX Ingress Controller , et à ce stade, nous inspectons le déploiement dans l'espace de noms nginx-ingress . Comme indiqué dans la colonne READY de la sortie suivante, il n’existe qu’un seul conteneur pour le pod NGINX Ingress Controller, car nous ne l’avons pas injecté avec un side-car NGINX Service Mesh.

Nous avons également déployé un service de type LoadBalancer pour exposer l'adresse IP externe du contrôleur d'entrée NGINX (ici, 35.233.133.188) en dehors du cluster. Nous accéderons à l’exemple d’application bookinfo à cette adresse IP.

> kubectl get pods --namespace=nginx-ingress NOM PRÊT ÉTAT RESTARTS AGE pod/nginx-ingress-867f954b8f0fzdrm 1/1 En cours d'exécution 0 3d3h NOM TYPE CLUSTER-IP EXTERNAL-IP ... service-nginx-ingress LoadBalancer 10.31.245.207 35.233.133.188 ... ... ÂGE DU(DES) PORT(S) ... 80:31469/TCP,443:32481/TCP 4d2h ...

Utilisation d'une ressource d'entrée Kubernetes standard pour exposer l'application (3:55)

Nous exposons maintenant l'application bookinfo dans le maillage, en utilisant une ressource Kubernetes Ingress standard telle que définie dans bookinfo-ingress.yaml . Des instructions correspondantes sont fournies dans notre didacticiel, Exposer une application avec NGINX Plus Ingress Controller .

La ressource fait référence à un secret Kubernetes pour l'application bookinfo sur la ligne 10 et inclut une règle de routage qui spécifie que les requêtes pour bookinfo.example.com sont envoyées au service productpage ( lignes 11 à 18 ). Le secret est défini dans bookinfo-secret.yaml :

Nous exécutons cette commande pour charger la clé et le certificat, qui dans la démo est auto-signé :

> kubectl apply -f bookinfo-secret.yaml secret/bookinfo-secret inchangé

Nous activons la ressource Ingress :

> kubectl apply -f bookinfo-ingress.yaml ingress.networking.k8s.io/bookinfo-ingress supprimé

et vérifiez que Ingress Controller a ajouté la route définie dans la ressource, comme confirmé par l'événement à la fin de la sortie :

> kubectl décrit l'entrée bookinfo-ingress ...
Événements:
  Type Raison Âge Du message ---- ------ ---- ---- ------- Normal Ajouté ou mis à jour 5 s nginx-ingress-controller Configuration pour ... ...default/bookinfo-ingress a été ajouté ou mis à jour

Dans la démo, nous utilisons maintenant un navigateur pour accéder à l'application bookinfo sur https://bookinfo.example.com/ . (Nous avons précédemment ajouté un mappage dans le fichier local /etc/hosts entre l'adresse IP du service Ingress Controller – 35.233.133.188 dans la démo, comme indiqué ci-dessus – et bookinfo.example.com . Pour les instructions, consultez la documentation .) Les informations de la section Critiques de livres de la page changent périodiquement à mesure que les demandes parcourent les trois versions du service d'avis défini dans bookinfo.yaml ( télécharger ).

Nous inspectons ensuite le trafic entrant dans les clusters. Nous exécutons le script generate-traffic.sh pour effectuer des requêtes au service productpage via l'adresse IP publique du contrôleur d'entrée NGINX, puis exécutons la commande nginx-meshctl top pour surveiller le trafic :

> nginxmesh-ctl top deploy/productpage-v1 Direction du déploiement Taux de réussite des ressources P99 P90 P50 ... productpage-v1 Vers details-v1 100,00 % 3 ms 3 ms 2 ms Vers reviews-v2 100,00 % 99 ms 90 ms 20 ms Vers reviews-v3 100,00 % 99 ms 85 ms 18 ms Vers reviews-v1 100,00 % 20 ms 17 ms 9 ms Depuis nginx-ingress 100,00 % 192 ms 120 ms 38 ms ... Nombre de requêtes ... 14 ... 5 ... 5 ... 12

Utilisation d'une ressource NGINX VirtualServer pour exposer l'application (6:45)

Nous montrons ensuite une manière alternative d’exposer une application, en utilisant une ressource NGINX VirtualServer . Il s’agit d’une ressource NGINX Ingress Controller personnalisée qui prend en charge une gestion du trafic plus complexe, telle que la répartition du trafic et le routage basé sur le contenu.

Nous supprimons d’abord la ressource Ingress standard :

> kubectl delete -f bookinfo-ingress.yaml ingress.networking.k8s.io "bookinfo-ingress" supprimé

Notre fichier bookinfo-vs.yaml configure mTLS avec le même secret que dans bookinfo-ingress.yaml ( lignes 7–8 ). Les lignes 9 à 12 définissent le service productpage comme étant en amont, et les lignes 13 à 24 un itinéraire qui envoie toutes les requêtes GET effectuées sur bookinfo.example.com à ce service en amont. Pour les méthodes HTTP autres que GET , il renvoie le code d'état405 .

Nous appliquons la ressource :

> kubectl apply -f bookinfo-vs.yaml virtualserver.kubernetes.nginx.org/bookinfo-vs créé

Nous effectuons ensuite les mêmes étapes qu’avec la ressource Ingress : exécutons la commande kubectl describe pour confirmer le déploiement correct et accédons à l’application dans un navigateur. Une autre confirmation que l'application fonctionne correctement est qu'elle rejette la méthode POST :

> curl -k -X POST https://bookinfo.example.com/ Méthode non autorisée

Configuration d'une route de sortie sécurisée avec le contrôleur d'entrée NGINX (8:44)

Nous montrons maintenant comment acheminer le trafic de sortie via NGINX Ingress Controller. Notre tutoriel Configurer une route de sortie sécurisée avec NGINX Plus Ingress Controller couvre le processus, à l'aide de différentes applications d'exemple.

Nous avons déjà défini un pod bash simple dans bash.yaml et l'avons déployé dans l'espace de noms par défaut à partir duquel nous envoyons des requêtes. Comme indiqué dans la colonne READY de cette sortie, il a été injecté avec le sidecar NGINX Service Mesh.

> kubectl récupère toutNOM ÉTAT PRÊT REDÉMARRAGES ÂGE
pod/bash-6ccb678958-zsgm7 2/2 En cours d'exécution 0 77s

NOM TYPE CLUSTER-IP EXTERNE-IP PORT(S) ÂGE
service/kubernetes ClusterIP 10.31.240.1 <none> 443/TCP 4d2h
...

Il existe plusieurs cas d'utilisation dans lesquels vous souhaiterez peut-être activer les requêtes depuis le pod vers un service de sortie , qui est toute entité qui ne fait pas partie de NGINX Service Mesh. Voici des exemples de services déployés :

• En dehors du cluster
• Sur un autre cluster
• Sur le même cluster, mais non injecté avec le sidecar NGINX Service Mesh

Dans la démo, nous considérons le cas d'utilisation final. Nous avons une application déployée dans l’espace de noms hérité , qui n’est pas contrôlé par NGINX Service Mesh et où l’injection automatique du sidecar NGINX Service Mesh est désactivée. Il n'y a qu'un seul pod en cours d'exécution pour l'application.

> kubectl obtient tous les --namespaces=legacyNOM ÉTAT PRÊT REDÉMARRAGES ÂGE
pod/target-5f7bcb96c6-km9lz 1/1 En cours d'exécution 0 27m

NOM TYPE CLUSTER-IP EXTERNE-IP PORT(S) ÂGE
service/target-svc ClusterIP 10.31.245.213 <none> 80/TCP,443/TCP 27m
...

N'oubliez pas que nous avons configuré une politique mTLS stricte pour NGINX Service Mesh ; par conséquent, nous ne pouvons pas envoyer de requêtes directement depuis le pod bash vers le service cible, car les deux ne peuvent pas s'authentifier l'un avec l'autre. Lorsque nous essayons, nous obtenons un code d'état503 comme illustré ici :

> kubectl exec -it bash-6ccb678958-zsgm7 -c bash -- curl target-svc.legacy curl : (56) Échec de réception : la connexion est réinitialisée par la commande 503 de l'homologue et s'est terminée avec le code de sortie 56

La solution consiste à permettre au pod bash d’envoyer le trafic de sortie via NGINX Ingress Controller. Nous supprimons le commentaire de l'annotation sur les lignes 14–15 de bash.yaml :

Ensuite, nous appliquons la nouvelle configuration :

> kubectl apply -f bash.yaml déploiement.apps/bash configuré

et vérifiez qu'un nouveau pod bash a démarré :

> kubectl get pods NOM PRÊT ÉTAT RESTARTS AGE bash-678c8b4579-7sfml 2/2 En cours d'exécution 0 6s bash-6ccb678958-zsgm7 2/2 Fin 0 3m28s

Maintenant, lorsque nous exécutons la même commande kubectl exec que précédemment, pour envoyer une requête du pod bash au service cible, nous obtenons le code d'état404 au lieu de503 . Cela indique que le pod bash a envoyé avec succès la demande au contrôleur d'entrée NGINX, mais ce dernier ne sait pas où la transmettre car aucune route n'est définie.

Nous créons l’itinéraire requis avec la définition de ressource Ingress suivante dans legacy-route.yaml . L'annotation de route interne sur la ligne 7 signifie que le service cible n'est pas exposé à Internet, mais uniquement aux charges de travail au sein de NGINX Service Mesh.

Nous activons la nouvelle ressource et confirmons que NGINX Ingress Controller a ajouté la route définie dans la ressource :

> kubectl apply -f legacy-route.yaml ingress.networking.k8s.io/target-internal-route créé > kubectl describe ingress target-internal-route -n legacy ...
Événements:
  Type Raison Âge Du message ---- ------ ---- ---- ------- Normal Ajouté ou mis à jour 6 s Configuration du contrôleur d'entrée nginx pour ... ...legacy/target-internal-route a été ajouté ou mis à jour

Maintenant, lorsque nous exécutons la commande kubectl exec , nous atteignons le service cible :

{"req": {"méthode": "GET" "url": "/",
"host": "target-svc.legacy",
"remoteAddr": "10.28.2.76:56086"}}

L’un des avantages du routage du trafic sortant via NGINX Ingress Controller est que vous pouvez contrôler exactement quels services externes peuvent être atteints depuis l’intérieur du cluster – il s’agit uniquement de ceux pour lesquels vous définissez un itinéraire.

Une dernière chose que nous montrons dans la démo est comment surveiller le trafic de sortie. Nous exécutons la commande kubectl exec pour envoyer plusieurs requêtes, puis exécutons cette commande :

> nginxmesh-ctl top deploy/nginx-ingress -n nginx-ingress Direction du déploiement Taux de réussite des ressources P99 P90 P50 NumRequests nginx-ingress Vers la cible 100,00 % 1 ms 1 ms 1 ms 9 Depuis bash 100,00 % 0 ms 0 ms 0 ms 9

Dites « non » à la latence – Essayez NGINX Service Mesh avec NGINX Ingress Controller

De nombreux services mesh offrent des options de passerelle d'entrée et de sortie, mais nous pensons que vous apprécierez un avantage supplémentaire de l'intégration NGINX : une latence plus faible. La plupart des maillages nécessitent l'injection d'un side-car dans le contrôleur Ingress, ce qui oblige le trafic à effectuer un saut supplémentaire sur son chemin vers vos applications. Les secondes comptent, et ce temps supplémentaire qui ralentit vos expériences numériques peut inciter les clients à se tourner vers un autre fournisseur. NGINX Service Mesh n'ajoute pas de latence inutile car il n'injecte pas de side-car dans NGINX Ingress Controller. Au lieu de cela, en s'intégrant directement à Spire, l'autorité de certification du maillage, NGINX Ingress Controller devient une partie de NGINX Service Mesh. NGINX Ingress Controller récupère simplement les certificats et les clés de l'agent Spire et les utilise pour participer à l'échange de certificats mTLS avec des pods maillés.

Il existe deux versions de NGINX Ingress Controller pour Kubernetes : NGINX Open Source et NGINX Plus. Pour déployer NGINX Ingress Controller avec NGINX Service Mesh comme décrit dans ce blog, vous devez utiliser la version NGINX Plus, disponible pour un essai gratuit de 30 jours .

NGINX Service Mesh est entièrement gratuit et disponible en téléchargement immédiat et peut être déployé en moins de 10 minutes ! Pour commencer, consultez la documentation et faites-nous savoir comment cela se passe via GitHub .