Tutoriel NGINX : protégez les API Kubernetes grâce à la limitation du débit

Daniele Polencic

Ce tutoriel fait partie d’une série de quatre qui mettent en pratique les concepts de « Microservices de mars 2022 : mise en réseau Kubernetes » :

• Réduire la latence de Kubernetes grâce à la mise à l’échelle automatique
• Protégez les API Kubernetes grâce à la limitation du débit (cet article)
• Protéger les applications Kubernetes contre les injections SQL
• Améliorez la disponibilité et la résilience grâce à un déploiement Canary

Vous souhaitez obtenir des conseils détaillés sur l’utilisation de NGINX pour encore plus de cas d’usage réseau avec Kubernetes ? Téléchargez gratuitement notre e-book, « Gestion du trafic Kubernetes avec NGINX : guide pratique ».

Votre organisation vient de lancer sa première application et sa première API dans Kubernetes. On vous a indiqué qu’il fallait vous attendre à d’importants volumes de trafic (et vous avez déjà mis en place la mise à l’échelle automatique afin que NGINX Ingress Controller puisse acheminer rapidement le trafic), mais certains craignent que l’API ne soit la cible d’une attaque malveillante. Si l’API reçoit un volume élevé de requêtes HTTP – ce qui peut arriver en cas de tentative de deviner un mot de passe par force brute ou d’attaque DDoS –, l’API et l’application risquent d’être submergées, voire de tomber en panne.

Mais vous avez de la chance ! La technique de contrôle du trafic appelée « limitation du débit » est un cas d’usage de passerelle API qui limite le débit des requêtes entrantes à une valeur correspondant à l’utilisation habituelle d’utilisateurs réels. Vous configurez NGINX Ingress Controller pour mettre en œuvre une politique de limitation du débit, ce qui évite que l’application et l’API soient submergées par un trop grand nombre de requêtes. Beau travail !

Présentation du laboratoire et du tutoriel

Cet article de blog accompagne le TP de l’unité 2 de Microservices March 2022 – « Exposer des API dans Kubernetes » et montre comment associer plusieurs contrôleurs Ingress NGINX à une limitation du débit afin d’éviter de surcharger les applications et les API.

Pour suivre ce tutoriel, vous avez besoin d’une machine disposant des éléments suivants :

• 2 processeurs ou plus
• 2 Go de mémoire disponible
• 20 Go d’espace disque disponible
• Connexion Internet
• Gestionnaire de conteneurs ou de machines virtuelles, tel que Docker, Hyperkit, Hyper-V, KVM, Parallels, Podman, VirtualBox ou VMware Fusion/Workstation
• minikube installé
• Helm installé
• Une configuration permettant d’ouvrir une fenêtre de navigateur. Si ce n’est pas possible, vous devez déterminer comment accéder aux services concernés depuis un navigateur.

Pour tirer le meilleur parti du laboratoire et du tutoriel, nous vous recommandons, avant de commencer, de :

• Regardez l’enregistrement de la présentation conceptuelle diffusée en direct
• Consultez les articles de blog, le webinaire et la vidéo de présentation
• Regardez la vidéo de 18 minutes qui résume le laboratoire :  

Ce tutoriel utilise les technologies suivantes :

• Contrôleur Ingress NGINX (basé sur NGINX Open Source)
• BusyBox
• Helm
• Locust
• minikube
• Podinfo

Les instructions de chaque défi comprennent le texte intégral des fichiers YAML utilisés pour configurer les applications. Vous pouvez également copier le texte depuis notre dépôt GitHub. Un lien vers GitHub est fourni avec le texte de chaque fichier YAML.

Ce tutoriel comprend trois défis :

1. Déployer un cluster, une application, une API et un contrôleur Ingress
2. Saturez votre application et votre API
3. Protégez votre application et votre API grâce à deux contrôleurs Ingress et à la limitation du débit

Défi 1 : déployer un cluster, une application, une API et un contrôleur Ingress

Dans cet exercice, vous allez déployer un cluster minikube et installer Podinfo comme exemple d’application et d’API. Vous allez ensuite déployer le contrôleur Ingress NGINX, configurer le routage du trafic et tester la configuration Ingress.

Créer un cluster Minikube

Créez un cluster minikube. Après quelques secondes, un message confirme que le déploiement a réussi.

$ minikube start 🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default 

Installer l’application Podinfo et l’API Podinfo

Podinfo est une « application web développée en Go qui présente les bonnes pratiques d’exécution de microservices dans Kubernetes ». Nous l’utilisons comme exemple d’application et d’API en raison de sa faible empreinte.

1. À l’aide de l’éditeur de texte de votre choix, créez un fichier YAML nommé 1-apps.yaml avec le contenu suivant (ou copiez-le depuis GitHub). Il définit un déploiement comprenant :

apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: api 
spec: 
  selector: 
    matchLabels: 
      app: api 
  template: 
    metadata: 
      labels: 
        app: api 
    spec: 
      containers: 
        - name: api 
          image: stefanprodan/podinfo 
          ports: 
            - containerPort: 9898 
--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: api 
spec: 
  ports: 
    - port: 80 
      targetPort: 9898 
      nodePort: 30001 
  selector: 
    app: api 
  type: LoadBalancer 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: frontend 
spec: 
  selector: 
    matchLabels: 
      app: frontend 
  template: 
    metadata: 
      labels: 
        app: frontend 
    spec: 
      containers: 
        - name: frontend 
          image: stefanprodan/podinfo 
          ports: 
            - containerPort: 9898 
--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: frontend 
spec: 
  ports: 
    - port: 80 
      targetPort: 9898 
      nodePort: 30002 
  selector: 
    app: frontend 
  type: LoadBalancer

• Une application web (que nous appellerons « Podinfo Frontend ») qui génère une page HTML
• Une API (API Podinfo) qui renvoie une charge utile JSON

1. Déployez l’application et l’API :

$ kubectl apply -f 1-apps.yamldeployment.apps/api created 
service/api created 
deployment.apps/frontend created 
service/frontend created 

1. Vérifiez que les pods de Podinfo API et de Podinfo Frontend ont été déployés correctement, comme l’indique la valeur Running dans la colonne STATUS.

$ kubectl get pods  
NAME                        READY   STATUS    RESTARTS  AGE 
api-7574cf7568-c6tr6        1/1     Running   0         87s 
frontend-6688d86fc6-78qn7   1/1     Running   0         87s 

Déployer le contrôleur Ingress NGINX

Le moyen le plus rapide d’installer NGINX Ingress Controller est d’utiliser Helm.

Installez NGINX Ingress Controller dans un espace de noms distinct (nginx) à l’aide de Helm.

1. Créez l’espace de noms :

$ kubectl create namespace nginx 

1. Ajoutez le dépôt NGINX à Helm :

$ helm repo add nginx-stable https://helm.nginx.com/stable 

1. Téléchargez et installez le contrôleur Ingress NGINX dans votre cluster :

$ helm install main nginx-stable/nginx-ingress \ --set controller.watchIngressWithoutClass=true \ --set controller.ingressClass=nginx \ --set controller.service.type=NodePort \ --set controller.service.httpPort.nodePort=30010 \ --set controller.enablePreviewPolicies=true \ --namespace nginx 

1. Vérifiez que le pod NGINX Ingress Controller a bien été déployé, comme l’indique la valeur « Running » dans la colonne « STATUS » (pour plus de lisibilité, la sortie est répartie sur deux lignes).

$ kubectl get pods -namespace nginx NAME                                  READY   STATUS   ...
main-nginx-ingress-779b74bb8b-d4qtc   1/1     Running  ...

      ... RESTARTS   AGE 
      ... 0          92s 

Acheminer le trafic vers votre application

1. À l’aide de l’éditeur de texte de votre choix, créez un fichier YAML nommé « 2-ingress.yaml » avec le contenu suivant (ou copiez-le depuis GitHub). Il définit le manifeste Ingress nécessaire pour acheminer le trafic vers l’application et l’API.

apiVersion: networking.k8s.io/v1 
kind: Ingress 
metadata: 
  name: first 
spec: 
  ingressClassName: nginx 
  rules: 
    - host: "example.com" 
      http: 
        paths: 
          - backend: 
              service: 
                name: frontend 
                port: 
                  number: 80 
            path: / 
            pathType: Prefix 
    - host: "api.example.com" 
      http: 
        paths: 
          - backend: 
              service: 
                name: api 
                port: 
                  number: 80 
            path: / 
            pathType: Prefix

1. Déployez la ressource Ingress :

$ kubectl apply -f 2-ingress.yaml ingress.networking.k8s.io/first created 

Tester la configuration Ingress

1. Pour vous assurer que votre configuration Ingress fonctionne comme prévu, testez-la à l’aide d’un pod temporaire. Lancez un pod jetable BusyBox dans le cluster :

$ kubectl run -ti --rm=true busybox --image=busybox If you don't see a command prompt, try pressing enter.
/ #

1. Testez l’API Podinfo en envoyant une requête au pod du contrôleur Ingress NGINX avec le nom d’hôte api.example.com. Le résultat affiché indique que l’API reçoit du trafic.

/ # wget --header="Host: api.example.com" -qO- main-nginx-ingress.nginx { 
  "hostname": "api-687fd448f8-t7hqk", 
  "version": "6.0.3", 
  "revision": "", 
  "color": "#34577c", 
  "logo": "https://raw.githubusercontent.com/stefanprodan/podinfo/gh-pages/cuddle_clap.gif", 
  "message": "greetings from podinfo v6.0.3", 
  "goos": "linux", 
  "goarch": "arm64", 
  "runtime": "go1.16.9", 
  "num_goroutine": "6", 
  "num_cpu": "4" 
} 

1. Testez « Podinfo Frontend » en exécutant la commande suivante dans le même pod BusyBox afin de simuler un navigateur web et de récupérer la page web. La sortie affichée correspond au code HTML du début de la page web.

/ # wget --header="Host: example.com" --header="User-Agent: Mozilla" -qO- main-nginx-ingress.nginx <!DOCTYPE html> 
<html> 
<head> 
  <title>frontend-596d5c9ff4-xkbdc</title> 
  # ...

1. Dans un autre terminal, ouvrez Podinfo dans un navigateur. La page greetings from podinfo indique que Podinfo est en cours d’exécution.

$ minikube service podinfo

1. 
   Félicitations ! Le contrôleur Ingress NGINX reçoit les requêtes et les transmet à l’application et à l’API.
2. Dans le terminal d’origine, mettez fin à la session BusyBox :

/ # exit 
$

Défi 2 : Surchargez votre application et votre API

Dans ce défi, vous allez installer Locust, un outil open source de génération de charge, et l’utiliser pour simuler un pic de trafic qui surcharge l’API et provoque le plantage de l’application.

Installer Locust

1. À l’aide de l’éditeur de texte de votre choix, créez un fichier YAML nommé « 3-locust.yaml » avec le contenu suivant (ou copiez-le depuis GitHub). L’objet ConfigMap définit un script nommé locustfile.py qui génère les requêtes à envoyer au pod, avec les en-têtes appropriés. Le trafic n’est pas réparti uniformément entre l’application et l’API : les requêtes sont principalement dirigées vers Podinfo API, et seule 1 requête sur 5 est envoyée à Podinfo Frontend. Les objets Deployment et Service définissent le pod Locust.

apiVersion: v1 
kind: ConfigMap 
metadata: 
  name: locust-script 
data: 
  locustfile.py: |- 
    from locust import HttpUser, task, between 

    class QuickstartUser(HttpUser): 
        wait_time = between(0.7, 1.3) 

        @task(1) 
        def visit_website(self): 
            with self.client.get("/", headers={"Host": "example.com", "User-Agent": "Mozilla"}, timeout=0.2, catch_response=True) as response: 
                if response.request_meta["response_time"] > 200: 
                    response.failure("Frontend failed") 
                else: 
                    response.success() 
  
        @task(5) 
        def visit_api(self): 
            with self.client.get("/", headers={"Host": "api.example.com"}, timeout=0.2) as response: 
                if response.request_meta["response_time"] > 200: 
                    response.failure("API failed") 
                else: 
                    response.success() 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: locust 
spec: 
  selector: 
    matchLabels: 
      app: locust 
  template: 
    metadata: 
      labels: 
        app: locust 
    spec: 
      containers: 
        - name: locust 
          image: locustio/locust 
          ports: 
            - containerPort: 8089 
          volumeMounts: 
            - mountPath: /home/locust 
              name: locust-script 
      volumes: 
        - name: locust-script 
          configMap: 
            name: locust-script 
--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: locust 
spec: 
  ports: 
    - port: 8089 
      targetPort: 8089 
      nodePort: 30015 
  selector: 
    app: locust 
  type: LoadBalancer

1. Déployez Locust :

$ kubectl apply -f 3-locust.yaml configmap/locust-script created 
deployment.apps/locust created 
service/locust created 

1. Vérifiez le déploiement de Locust. Dans l’exemple de sortie suivant, la commande de vérification a été exécutée quelques secondes seulement après la commande kubectl apply. L’installation est donc toujours en cours, comme l’indique la valeur ContainerCreating du pod Locust dans le champ STATUS. Attendez que la valeur soit Running avant de passer à la section suivante. (La sortie est répartie sur deux lignes pour en faciliter la lecture.)

$ kubectl get pods
NAME                        READY   STATUS            ...           api-7574cf7568-c6tr6        1/1     Running           ...
frontend-6688d86fc6-78qn7   1/1     Running           ...            locust-77c699c94d-hc76t     0/1     ContainerCreating ...

      ... RESTARTS   AGE 
      ... 0          33m
      ... 0          33m
      ... 0           4s

Simuler un pic de trafic

1. Ouvrez Locust dans un navigateur.

$ minikube service locust

1. 
2. Saisissez les valeurs suivantes dans les champs :
   • Nombre d’utilisateurs – 1000
   • Taux d’apparition – 30
   • Hôte – http://main-nginx-ingress
3. Cliquez sur le bouton « Start swarming » pour envoyer du trafic vers l’API Podinfo et le frontend Podinfo. Observez les tendances du trafic dans les onglets Charts et Failures de Locust :
   • Graphique – À mesure que le nombre de requêtes API augmente, les temps de réponse de l’API Podinfo se dégradent.
   • Échecs – Comme Podinfo API et Podinfo Frontend partagent un contrôleur Ingress, l’augmentation du nombre de requêtes API entraîne rapidement l’apparition d’erreurs dans l’application web.

Cela pose problème, car un seul acteur malveillant utilisant l’API peut rendre indisponibles non seulement l’API, mais aussi toutes les applications desservies par NGINX Ingress Controller !

Défi 3 : protégez votre application et votre API grâce à deux contrôleurs Ingress et à la limitation du débit

Dans le dernier défi, vous déployez deux contrôleurs Ingress NGINX afin de remédier aux limites du déploiement précédent, en créant un espace de noms distinct pour chacun d’eux, en installant des instances distinctes du contrôleur Ingress NGINX pour Podinfo Frontend et Podinfo API, en reconfigurant Locust pour diriger le trafic de l’application et de l’API vers leurs contrôleurs Ingress NGINX respectifs, puis en vérifiant que la limitation du débit est efficace. Voyons d’abord comment résoudre le problème d’architecture. Lors du défi précédent, vous avez saturé le contrôleur Ingress NGINX avec des requêtes d’API, ce qui a également affecté l’application. Cela s’est produit parce qu’un seul contrôleur Ingress était chargé d’acheminer le trafic à la fois vers l’application web (Podinfo Frontend) et vers l’API (Podinfo API).

L’exécution d’un pod NGINX Ingress Controller distinct pour chacun de vos services évite que votre application ne soit affectée par un trop grand nombre de requêtes API. Cette configuration n’est pas forcément nécessaire dans tous les cas, mais notre simulation permet de constater facilement les avantages liés à l’exécution de plusieurs NGINX Ingress Controllers.

La deuxième partie de la solution, qui empêche l’API Podinfo d’être submergée, consiste à mettre en œuvre une limitation du débit en utilisant NGINX Ingress Controller comme passerelle API.

Qu’est-ce que la limitation du débit ?

La limitation du débit restreint le nombre de requêtes qu’un utilisateur peut effectuer au cours d’une période donnée. Pour atténuer une attaque DDoS, par exemple, vous pouvez l’utiliser afin de limiter le débit des requêtes entrantes à une valeur correspondant à l’activité habituelle d’utilisateurs réels. Lorsque la limitation du débit est mise en œuvre avec NGINX, les clients qui envoient trop de requêtes sont redirigés vers une page d’erreur afin qu’ils ne puissent pas nuire à l’API. Pour en savoir plus sur son fonctionnement, consultez la documentation de NGINX Ingress Controller.

Qu’est-ce qu’une passerelle API ?

Une passerelle d’API achemine les requêtes API des clients vers les services appropriés. Cette définition simple donne souvent lieu à une importante erreur d’interprétation, qui consiste à considérer une passerelle d’API comme une technologie à part entière. Ce n’est pas le cas. Le terme « passerelle d’API » désigne plutôt un ensemble de cas d’usage pouvant être mis en œuvre au moyen de différents types de proxys : le plus souvent, un contrôleur de mise à disposition d’applications (ADC) ou un équilibreur de charge et un proxy inverse, mais aussi, de plus en plus, un contrôleur Ingress ou un maillage de services. La limitation du débit est un cas d’usage courant pour le déploiement d’une passerelle d’API. Pour en savoir plus sur les cas d’usage des passerelles d’API dans Kubernetes, consultez l’article Comment choisir ? Passerelle d’API, contrôleur Ingress ou maillage de services sur notre blog.

Préparez votre cluster

Avant de pouvoir mettre en œuvre la nouvelle architecture et la limitation du débit, vous devez supprimer la configuration précédente du contrôleur Ingress NGINX.

1. Supprimez la configuration du contrôleur Ingress NGINX :

$ kubectl delete -f 2-ingress.yaml 
ingress.networking.k8s.io "first" deleted 

1. Créez un espace de noms appelé « nginx‑web » pour Podinfo Frontend :

$ kubectl create namespace nginx-web 
namespace/nginx-web created 

1. Créez un espace de noms appelé « nginx‑api » pour l’API Podinfo :

$ kubectl create namespace nginx-api 
namespace/nginx-api created 

Installer le contrôleur Ingress NGINX pour le frontend de Podinfo

1. Installez le contrôleur Ingress NGINX :

$ helm install web nginx-stable/nginx-ingress --set controller.ingressClass=nginx-web \ --set controller.service.type=NodePort \ --set controller.service.httpPort.nodePort=30020 \ --namespace nginx-web

1. Créez un manifeste Ingress nommé « 4-ingress-web.yaml » pour Podinfo Frontend (ou copiez-le depuis GitHub). apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: rate-limit-policy spec: rateLimit: rate: 10r/s key: ${binary_remote_addr} zoneSize: 10M --- apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: api-vs spec: ingressClassName: nginx-api host: api.example.com policies: - name: rate-limit-policy upstreams: - name: api service: api port: 80 routes: - path: / action: pass: api
2. Déployez le nouveau manifeste :

$ kubectl apply -f 4-ingress-web.yaml 
ingress.networking.k8s.io/frontend created  

Reconfigurer Locust

À présent, reconfigurez Locust et vérifiez que :

• L’API Podinfo n’est pas surchargée.
• Quel que soit le nombre de requêtes envoyées à l’API Podinfo, cela n’a aucune incidence sur le frontend Podinfo.

Effectuez les étapes suivantes :

1. Modifiez le script Locust comme suit : étant donné que Locust ne prend en charge qu’une seule URL dans le tableau de bord, codez la valeur en dur dans le script Python à l’aide du fichier YAML « 6-locust.yaml » avec le contenu suivant (ou copiez-le depuis GitHub). Notez les URL de chaque tâche.

apiVersion: v1 
kind: ConfigMap 
metadata: 
  name: locust-script 
data: 
  locustfile.py: |- 
    from locust import HttpUser, task, between 

    class QuickstartUser(HttpUser): 
        wait_time = between(0.7, 1.3) 

        @task(1) 
        def visit_website(self): 
            with self.client.get("http://web-nginx-ingress.nginx-web/", headers={"Host": "example.com", "User-Agent": "Mozilla"}, timeout=0.2, catch_response=True) as response: 
                if response.request_meta["response_time"] > 200: 
                    response.failure("Frontend failed") 
                else: 
                    response.success() 
  

        @task(5) 
        def visit_api(self): 
            with self.client.get("http://api-nginx-ingress.nginx-api/", headers={"Host": "api.example.com"}, timeout=0.2) as response: 
                if response.request_meta["response_time"] > 200: 
                    response.failure("API failed") 
                else: 
                    response.success() 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: locust 
spec: 
  selector: 
    matchLabels: 
      app: locust 
  template: 
    metadata: 
      labels: 
        app: locust 
    spec: 
      containers: 
        - name: locust 
          image: locustio/locust 
          ports: 
            - containerPort: 8089 
          volumeMounts: 
            - mountPath: /home/locust 
              name: locust-script 
      volumes: 
        - name: locust-script 
          configMap: 
            name: locust-script 
--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: locust 
spec: 
  ports: 
    - port: 8089 
      targetPort: 8089 
      nodePort: 30015 
  selector: 
    app: locust 
  type: LoadBalancer 

• Toutes les requêtes adressées à Podinfo Frontend sont redirigées vers le contrôleur Ingress NGINX nginx‑web à l’adresse http://web-nginx-ingress.nginx-web
• Toutes les requêtes adressées à Podinfo API sont dirigées vers le contrôleur Ingress NGINX nginx‑api à l’adresse http://api-nginx-ingress.nginx-api

1. Déployez la nouvelle configuration de Locust. La sortie confirme que le script a été modifié, mais que les autres éléments restent inchangés.

$ kubectl apply -f 6-locust.yaml 
configmap/locust-script configured 
deployment.apps/locust unchanged 
service/locust unchanged

1. Supprimez le pod Locust pour forcer le rechargement de la nouvelle ConfigMap. Pour identifier le pod à supprimer, l’argument de la commande kubectl delete pod est exprimé sous la forme de commandes chaînées qui sélectionnent le pod Locust dans la liste de tous les pods.

$ kubectl delete pod `kubectl get pods | grep locust | awk {'print $1'}` 

1. Vérifiez que Locust a été rechargé (la valeur du pod Locust dans la colonne AGE n’est que de quelques secondes).

$ kubectl get pods
NAME                        READY   STATUS   ...           api-7574cf7568-jrlvd        1/1     Running  ...
frontend-6688d86fc6-vd856   1/1     Running  ...            locust-77c699c94d-6chsg     0/1     Running  ...

      ... RESTARTS   AGE 
      ... 0        9m57s
      ... 0        9m57s
      ... 0           6s

Vérifier la limitation du débit

1. Revenez dans Locust et modifiez les paramètres dans les champs suivants :
   • Nombre d’utilisateurs – 400
   • Taux d’apparition – 10
   • Hôte – http://main-nginx-ingress
2. Cliquez sur le bouton « Start swarming » pour envoyer du trafic à l’API Podinfo et à Podinfo Frontend. Dans la barre de titre de Locust, en haut à gauche, observez que lorsque le nombre d’utilisateurs augmente dans la colonne STATUS, la valeur de la colonne FAILURES augmente également. Cependant, les erreurs ne proviennent plus de Podinfo Frontend, mais de l’API Podinfo, car la limite de débit définie pour l’API entraîne le rejet des requêtes excessives. Dans la trace en bas à droite, vous pouvez voir que NGINX renvoie le message 503 Service Temporarily Unavailable, qui fait partie de la fonctionnalité de limitation du débit et peut être personnalisé. Le débit de l’API est limité, tandis que l’application web reste toujours disponible. Bravo !
   

Étapes suivantes

Dans la pratique, la limitation du débit ne suffit pas à protéger vos applications et vos API contre les acteurs malveillants. Vous devez mettre en œuvre au moins une ou deux des méthodes suivantes pour protéger les applications, les API et l’infrastructure Kubernetes :

• Authentification et autorisation
• Pare-feu d’application web et protection contre les attaques DDoS
• Chiffrement de bout en bout et modèle Zero Trust
• Conformité aux réglementations du secteur

Nous abordons ces sujets et bien d’autres dans l’unité 3 de Microservices March 2022 – Modèle de sécurité des microservices dans Kubernetes. Pour essayer NGINX Ingress Controller pour Kubernetes avec NGINX Plus et NGINX App Protect, commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation. Pour essayer NGINX Ingress Controller avec NGINX Open Source, vous pouvez obtenir le code source de la version ou télécharger un conteneur précompilé depuis DockerHub.

À propos de l’auteur

Daniele Polencic

Autres articles de Daniele Polencic