Déploiement de BIG-IP et du contrôleur d'entrée NGINX dans la même architecture

Dans notre précédente série de blogs, Déploiement de services d’application dans Kubernetes , nous avons évoqué un modèle que nous observons chez de nombreux clients au cours de leur parcours de transformation numérique. La plupart des parcours commencent par le modèle traditionnel de création et de déploiement d'applications (généralement des monolithes), en répartissant la responsabilité de ces deux fonctions entre des équipes de développement et d'exploitation cloisonnées. À mesure que les organisations évoluent vers un modèle plus moderne, elles créent des applications basées sur des microservices et les déploient à l’aide de pratiques DevOps qui brouillent la division entre les silos traditionnels.

Alors que les équipes DevOps et les propriétaires d’applications prennent un contrôle plus direct sur la manière dont leurs applications sont déployées, gérées et livrées, il n’est souvent pas pratique de briser les cloisons en une seule fois – et nous ne pensons pas que cela soit nécessaire. Au contraire, nous observons qu’une répartition logique des responsabilités s’applique toujours :

• Les équipes réseau et sécurité continuent de se concentrer sur la sécurité globale, les performances et la disponibilité de l’infrastructure de l’entreprise. Ils s’intéressent surtout aux services mondiaux, qui sont généralement déployés à la « porte d’entrée » de cette infrastructure.

  Ces équipes s'appuient sur F5 BIG-IP pour des cas d'utilisation tels que l'équilibrage de la charge du serveur global (GSLB), la résolution DNS et l'équilibrage de la charge, ainsi que la mise en forme sophistiquée du trafic. BIG‑IQ et NGINX Controller [désormais F5 NGINX Management Suite ] fournissent des mesures et des alertes sous une forme qui convient le mieux aux équipes NetOps, et pour les équipes SecOps, ils offrent la visibilité et le contrôle sur la sécurité dont SecOps doit disposer pour protéger les actifs de l'organisation et se conformer aux réglementations du secteur.

• Les équipes d’exploitation (DevOps avec un accent sur les opérations) créent et gèrent des applications individuelles selon les besoins de leurs secteurs d’activité associés. Ils s’intéressent surtout aux services tels que l’automatisation et les pipelines CI/CD qui les aident à itérer plus rapidement sur les fonctionnalités mises à jour ; ces services sont généralement déployés « plus près » de l’application, par exemple dans un environnement Kubernetes.

  Ces équipes s'appuient sur des produits NGINX tels que NGINX Plus , NGINX App Protect , NGINX Ingress Controller et NGINX Service Mesh pour l'équilibrage de charge et la mise en forme du trafic des applications distribuées basées sur des microservices hébergées dans plusieurs environnements, y compris les clusters Kubernetes. Les cas d’utilisation incluent la terminaison TLS, le routage basé sur l’hôte, la réécriture d’URI, l’authentification JWT, la persistance de session, la limitation du débit, la vérification de l’état, la sécurité (avec NGINX App Protect comme WAF intégré) et bien d’autres.

NetOps et DevOps dans les environnements Kubernetes

Les préoccupations différentes des équipes NetOps et DevOps se reflètent dans les rôles qu’elles jouent dans les environnements Kubernetes et les outils qu’elles utilisent pour les remplir. Au risque de trop simplifier, nous pouvons dire que les équipes NetOps s’intéressent principalement à l’infrastructure et aux fonctionnalités réseau en dehors du cluster Kubernetes et les équipes DevOps à ces fonctionnalités à l’intérieur du cluster.

Pour diriger le trafic vers les clusters Kubernetes, les équipes NetOps peuvent utiliser BIG-IP comme équilibreur de charge externe qui prend en charge les capacités et la gamme de technologies de réseau superposées qu’elles connaissent déjà. Cependant, BIG-IP n’a aucun moyen de suivre à lui seul les modifications apportées à l’ensemble des pods au sein du cluster Kubernetes (par exemple, les modifications apportées au nombre de pods ou à leurs adresses IP). Pour contourner cette contrainte, F5 Container Ingress Services (CIS) est déployé en tant qu'opérateur à l'intérieur du cluster. CIS surveille les modifications apportées à l'ensemble des pods et modifie automatiquement les adresses dans le pool d'équilibrage de charge du système BIG-IP en conséquence. Il recherche également la création de nouvelles ressources d’entrée, de route et personnalisées et met à jour la configuration BIG-IP en conséquence.

Bien que vous puissiez utiliser la combinaison de BIG-IP avec CIS pour équilibrer la charge du trafic directement vers les pods d'application , dans la pratique, NGINX Ingress Controller est la solution idéale pour découvrir et suivre les modifications dynamiques des applications sur les pods et les charges de travail qui représentent un grand nombre de services, par exemple lors de la mise à l'échelle horizontale de vos pods d'application pour répondre aux niveaux de demande changeants.

Un autre avantage du déploiement de NGINX Ingress Controller est qu’il transfère le contrôle de l’équilibrage de la charge des applications aux équipes DevOps qui sont en charge des applications elles-mêmes. Son plan de contrôle hautes performances et sa conception centrée sur DevOps le rendent particulièrement efficace pour prendre en charge les cas d'utilisation DevOps en évolution rapide, tels que les reconfigurations sur place et les mises à jour continues, sur les services Kubernetes dans plusieurs espaces de noms. NGINX Ingress Controller utilise l'API Kubernetes native pour découvrir les pods à mesure qu'ils sont mis à l'échelle.

Comment fonctionnent ensemble BIG-IP et NGINX Ingress Controller

Comme vous le savez peut-être, BIG‑IP et NGINX Ingress Controller ont été conçus à l’origine par deux sociétés distinctes (respectivement F5 et NGINX). Depuis que F5 a acquis NGINX, les clients nous ont dit que l’amélioration de l’interopérabilité entre les deux outils simplifierait la gestion de leur infrastructure. En réponse, nous avons développé une nouvelle ressource Kubernetes que nous appelons IngressLink.

La ressource IngressLink est une amélioration simple qui utilise une définition de ressource personnalisée Kubernetes (CRD) pour « lier » NGINX Ingress Controller et BIG‑IP. En termes simples, cela permet au CIS de « dire » à BIG-IP chaque fois que l’ensemble des pods NGINX Ingress Controller a changé. Grâce à ces informations, BIG-IP peut adapter de manière agile ses politiques d’équilibrage de charge correspondantes.

Avec BIG-IP déployé pour équilibrer la charge sur les clusters Kubernetes et NGINX Ingress Controller gérant le trafic entrant-sortant, le flux de trafic ressemble à ceci :

1. BIG-IP dirige le trafic externe vers les instances NGINX Ingress Controller.
2. NGINX Ingress Controller distribue le trafic aux services appropriés au sein du cluster.
3. Étant donné que NGINX Ingress Controller est exceptionnellement efficace, un ensemble stable d’instances peut gérer des modifications fréquentes et importantes apportées à l’ensemble des pods d’application. Mais lorsque votre contrôleur d'entrée NGINX doit évoluer horizontalement vers le haut ou vers le bas (pour gérer les pics et les baisses de trafic), CIS informe BIG-IP des changements (via la ressource IngressLink), permettant à BIG-IP de s'adapter rapidement aux changements.

Commencer

Pour plus de détails sur le fonctionnement de la ressource IngressLink, y compris un guide de déploiement, visitez F5 CloudDocs .

Commencez par demander votre essai gratuit de 30 jours de NGINX Ingress Controller avec NGINX App Protect WAF et DoS. Si vous n'êtes pas encore un utilisateur BIG‑IP, sélectionnez sur F5.com la version d'essai qui convient le mieux à votre équipe.