Utilisation de F5 BIG-IP pour éliminer les niveaux lors de la mise à l'échelle d'applications dans des conteneurs

Ou est-ce des « larmes » de frustration ? ¯\_(ツ)_/¯ C’est peut-être les deux.

Il existe une relation entre les architectures réseau et applicative. Nous aimons généralement parler de la manière dont les changements et les évolutions des architectures d’application impactent le réseau, tant en termes de solutions que d’architecture. Mais l’inverse est également vrai : l’architecture et le comportement du réseau peuvent avoir un impact assez spectaculaire sur les applications et leur architecture.

En effet, l’une des raisons pour lesquelles nous assistons à la décomposition des monolithes en de nombreux microservices aujourd’hui plutôt qu’à l’époque des années SOA est le réseau. Ou pour être plus précis, à cause de la vitesse du réseau. À l’époque de SOA, il y avait des limitations imposées par la nature du réseau (et les lois de la physique) qui rendaient impossible la composition d’une seule réponse à partir de plus de trois ou quatre services. D'accord, ce n'est pas impossible, mais indésirable en raison de la latence engendrée par chaque appel.

Aujourd’hui, nous disposons de réseaux plus rapides et plus volumineux, ainsi que d’une puissance de calcul considérablement plus rapide qui rend cette décomposition possible. La nature des conteneurs, souvent associés à des microservices comme le café avec des beignets, rend la tâche encore plus facile. Étant donné que « le réseau » entre deux services qui doivent communiquer est souvent une construction virtuelle (les paquets ne quittent jamais réellement le serveur hôte et ne subissent donc pas la latence encourue pour être « mis sur le fil »), le nombre de services qui peuvent être invoqués pour répondre à une seule requête est bien plus élevé que ce que nous pourrions raisonnablement atteindre à l’époque de SOA.

Cela ne signifie pas pour autant que nous devons ignorer le nombre de connexions et de sauts que nous devons parcourir pour répondre à une demande ou l’impact de l’architecture sur les performances de l’application. Car même si le calcul est plus rapide et les tuyaux plus gros, la surcharge opérationnelle reste un problème auquel nous devons faire face. Une chose qui entrave encore la performance. L’un des moyens les plus simples de gérer les frais généraux opérationnels (et d’améliorer les performances) est de réduire la complexité en éliminant les niveaux (inutiles) d’une architecture.

Réduire la complexité des environnements de conteneurs

La plupart des déploiements de conteneurs vont utiliser un certain type d’équilibreur de charge à l’intérieur du cluster pour gérer l’échelle des microservices/applications à l’intérieur de l’environnement de conteneur. C’est parce qu’ils sont souvent chargés d’effectuer le routage L7 des API (c’est-à-dire le contrôle d’entrée) et que les constructions d’équilibrage de charge natives sont basées sur iptables, qui bien sûr ne parle pas HTTP, le langage du routage L7. Il y a donc un ensemble d’équilibreurs de charge L7 à l’intérieur du conteneur de cluster.

Désormais, la plupart des déploiements nécessiteront également un équilibrage de charge en dehors du cluster pour acheminer le trafic externe vers l’équilibreur de charge approprié à l’intérieur du cluster. Pour ce faire, ils utilisent un équilibrage de charge simple pour distribuer les requêtes au bon équilibreur de charge à l’intérieur.

Nous appellerons l'équilibreur de charge extérieur à BIG-IP et celui à l'intérieur du cluster lb interne . Parce que c'est mon blog, voilà pourquoi.

Le problème est que le nombre d’instances lb internes fluctue (parfois de manière spectaculaire). Chaque fois qu'il y a un changement, le BIG-IP doit le savoir. Traditionnellement, il s’agissait d’une opération manuelle, obligeant le propriétaire de BIG-IP à sortir et à modifier le pool à la main. C'est frustrant pour le développement et DevOps, et fastidieux pour NetOps. En d’autres termes, personne ne veut procéder de cette façon.

C'est pourquoi des solutions comme le F5 Container Connector existent. F5 Container Connector est un service natif de conteneur qui s'intègre à l'orchestrateur de conteneur et observe l'environnement. Lorsqu'un changement impacte un lb interne, il déclenche un processus de mise à jour de BIG-IP . Cela signifie qu'à mesure que la demande augmente et diminue, le BIG-IP est automatiquement mis à jour et capable de distribuer de manière appropriée les demandes à un lb interne actif et sain. Aucune modification manuelle nécessaire.

Cette architecture de mise à l’échelle à deux niveaux présente l’avantage de fournir un emplacement entrant pratique (le BIG-IP) auquel SSL/TLS peut être terminé, offrant ainsi des améliorations de performances mesurables. Bon.

Mais pourquoi s’arrêter là ? BIG-IP est capable de fournir un routage L7 . Si vous utilisez les services de F5 Container Connector, vous pouvez réaliser des gains de performances supplémentaires (et réduire les frais opérationnels) en éliminant complètement le lb interne . Vraiment. BIG-IP peut agir comme contrôleur d'entrée pour Kubernetes et Red Hat OpenShift.

En déplaçant la responsabilité d'entrée vers BIG-IP, vous éliminez un niveau d'échelle entier (le lb interne), ce qui améliore immédiatement les performances. Étant donné que le lb externe est un F5 BIG-IP , vous pouvez déployer davantage de services d'application axés sur la sécurité, comme un WAF avancé avec défense contre les robots au point de contact plutôt qu'à l'intérieur du cluster de conteneurs (ou pas du tout). 

Clans de Clash of Ops

À mesure que les conteneurs sont de plus en plus utilisés en production (et ils le seront), une collaboration accrue entre DevOps et NetOps deviendra nécessaire afin de mettre en œuvre ces types d'améliorations et de garantir l'évolutivité, la vitesse et la sécurité des applications. Après tout, il ne s’agit pas seulement d’appuyer sur des boutons et de créer des pipelines en libre-service. L'architecture est un composant essentiel qui devra être conçu avec la contribution de DevOps et de NetOps, de peur d'ignorer les opportunités d'améliorer des éléments tels que les performances des applications.

Parce que la performance des applications est un sport d’équipe. Il est impacté par le code (AppDev), par la plateforme sur laquelle le code est déployé (DevOps), par l'architecture réseau et par les services applicatifs utilisés pour sécuriser et faire évoluer l'application (NetOps). L’utilisation de l’optimisation architecturale en éliminant les niveaux lorsque cela est possible est une bonne idée sur le plan opérationnel et commercial. Mais cela nécessite la participation de tous les joueurs de l’équipe.

Alors commandez une pizza et une bière, réunissez DevOps et NetOps et commencez à discuter. Découvrez si vous aussi pouvez améliorer les performances des applications en supprimant les niveaux inutiles dans votre environnement de conteneur.