Vitesse, évolutivité et sécurité : F5 connecte désormais les conteneurs dans Kubernetes

Conteneurs. Ce n’est pas une mode, ni une phase. Leur taux d’adoption est en fait assez accéléré par rapport à son prédécesseur, la virtualisation. En moins de deux ans, nous constatons déjà un intérêt pour le déploiement de services d'application dans des conteneurs , ce qui indique généralement des applications déjà en production qui ont besoin d'évolutivité, de sécurité et de rapidité pour répondre aux attentes élevées de l'expérience applicative d'aujourd'hui.

Il est intéressant de noter que les conteneurs évoluent au même rythme que leurs cadres de gestion et d’orchestration. La virtualisation n’a pas eu lieu, mais elle a précédé le cloud, qui a agi comme une fonction forçant d’autres technologies agiles à adopter les API et les modèles qui ont permis l’automatisation et l’orchestration du cloud à être appliquées à l’infrastructure virtuelle. Aujourd’hui, les conteneurs et la virtualisation (qui peuvent sans doute être considérés comme des technologies sœurs) sont généralement déployés avec un cadre d’orchestration qui coordonne le provisionnement, la mise à l’échelle et même le routage du trafic vers et depuis d’autres applications et services (trafic est-ouest).

Bien que dans les limites des domaines de ces cadres, ces mécanismes fonctionnent parfaitement pour fournir une échelle et un routage localisés, la réalité est que ces applications et services font partie d'une vue plus large ; une vue qui inclut une « application » plus complète qui nécessite une interaction avec les utilisateurs (trafic nord-sud). Une enquête menée fin 2016 par Portworx a révélé que la deuxième charge de travail la plus populaire prévue pour la conteneurisation était les « front-ends Web » avec 48 % des répondants.

Cela garantit presque qu’il existe un service en amont (ou un appareil, si vous préférez) offrant une évolutivité, une sécurité et une vitesse entre les utilisateurs et « l’application » composée de services déployés dans un environnement conteneurisé.

Cela signifie invariablement qu’il doit y avoir une coordination entre le cadre d’orchestration du conteneur et ce périphérique/service en amont.

Entrez les connecteurs de conteneur F5. Lorsque nous avons annoncé pour la première fois Container Connectors, nous mettions la touche finale à notre support Mesos. Aujourd’hui, nous sommes ravis de publier également la prise en charge de Kubernetes .

Connecteur de conteneur F5

Le connecteur de conteneur F5 fournit l'intégration nécessaire pour combler le dernier kilomètre interne entre le point où le trafic nord-sud se transforme en trafic est-ouest. C'est là que le BIG-IP en amont (d'où se trouve Kubernetes) transmet les requêtes au proxy local approprié (qui peut être notre propre proxy de services d'application ou, dans le cas de Kubernetes, Kube-Proxy , par exemple) ou au pod à traiter.

Ensuite, il attend une réponse et exécute ses propres tâches assignées, telles que le nettoyage des données (pour éviter les fuites de données), l'optimisation de l'image (pour améliorer les performances) et la renvoie à l'utilisateur.

Le composant clé est le connecteur de conteneur, qui réside dans un cluster Kubernetes et s'abonne aux événements comme les autres composants. Lorsqu'il détecte un événement approprié, il configure ou modifie dynamiquement une configuration existante sur la configuration en amont (BIG-IP) avec les détails appropriés. Il peut s'agir d'une augmentation en ajoutant de nouveaux membres à un cluster/pool, ou d'une réduction en les retirant à nouveau.

L’aspect le plus important est qu’il est intégré et se produit automatiquement, ce qui signifie une application cohérente des politiques de sécurité à l’entrée/sortie nord-sud sans compliquer davantage l’environnement conteneurisé. Il encourage également l’utilisation de SSL/TLS pour sécuriser le trafic des applications (et des API) avec les utilisateurs en fournissant un point unique pour gérer et maintenir les certificats. Cela permet également de préserver l’environnement conteneurisé de toute complexité opérationnelle supplémentaire, une plainte courante lorsque des conteneurs et leurs architectures d’applications associées sont introduits.

Les connecteurs de conteneurs F5 offrent la possibilité de provisionner et de gérer automatiquement les services d'application requis pour les applications conteneurisées dans un environnement de production, sans nécessiter de refontes massives de l'environnement qui existait déjà en développement et en test (vous avez testé, n'est-ce pas ?). Il prend en charge la notion de déploiements sans friction et préserve la notion de portabilité si importante pour les applications conteneurisées aujourd'hui.

F5 s'engage à garantir que les services de livraison et de sécurité dont les applications ont besoin sont disponibles dans tout type d'environnement, qu'il s'agisse de conteneurs ou de machines virtuelles, dans n'importe quel cloud ou dans un environnement traditionnel. Mais nous nous engageons également à rendre ces services aussi simples et indolores à provisionner et à gérer que possible, ce qui signifie des solutions qui s’adaptent à tous les types d’architectures.

Pour prendre en charge les chaînes d'outils DevOps, nous avons rendu les connecteurs de conteneurs et notre version de kube-proxy disponibles gratuitement sur https://hub.docker.com/r/f5networks/ et une version open source de notre contrôleur Kubernetes peut être récupérée à partir de notre référentiel git sur https://github.com/F5Networks/k8s-bigip-ctlr