Vitesse et échelle : F5 BIG-IP comme contrôle d'entrée pour Kubernetes
Il y a autant de confusion que de chaos dans le monde des conteneurs. Chaque jour semble apporter une nouvelle capacité ou un nouveau composant au monde des environnements d’orchestration de conteneurs. C’est nécessaire, car l’utilisation des conteneurs est encore en cours de maturation, car elle s’étend au-delà de l’expérimental pour devenir existentielle.
La vitesse et l’évolutivité sont parmi les deux principaux moteurs des déploiements de conteneurs. Le premier concerne autant le développement que la livraison, et donc l’accent est mis sur l’échelle. Mais il ne s’agit pas uniquement de l’échelle du protocole standard, nous parlons également de l’échelle de l’application .
La distinction est importante. Les conteneurs ont été élus comme étant les plus susceptibles de contenir des microservices, et l'une des règles cardinales des microservices est la communication via API uniquement. Une API basée sur HTTP – et non TCP – et qui nécessite donc une solution plus intelligente pour évoluer.
La plupart des environnements d’orchestration de conteneurs sont livrés « prêts à l’emploi » avec des proxys capables d’évoluer à l’échelle. Cela signifie un simple équilibrage de charge (POLB) au niveau de la couche TCP. Les adresses IP et les ports sont la lingua franca de ces proxys. Bien qu'ils fonctionnent bien dans un environnement où les services sont différenciés en fonction d'une combinaison adresse IP/port, ils ne fonctionnent pas aussi bien pour les applications (services) qui sont différenciées par les caractéristiques de la couche HTTP, comme la version de l'API, l'URI ou le nom de l'hôte. Il s'agit de constructions de couche d'application (HTTP) qui nécessitent des proxys plus intelligents pour acheminer et évoluer à la vitesse souhaitée. Ces constructions doivent être prises en considération dès la réception d'une demande d'une entité côté client, ce que la plupart des solutions à l'échelle vanille pour les conteneurs ne peuvent pas fournir.
En réponse à ce besoin naît la notion de contrôle Ingress*. Le contrôle d'entrée est essentiellement un routage d'application ou HTTP ou une commutation de couche 7 ou une commutation de contenu ou tout autre nom parmi la douzaine de noms que cette capacité a connus depuis le début du siècle. Le contrôle d'entrée suppose une différenciation des services au niveau de la couche d'application (HTTP) et agit en conséquence lors de la prise de décisions de routage et de mise à l'échelle dans l'environnement du conteneur.
Mais vous ne pouvez pas simplement placer un F5 BIG-IP devant un environnement de conteneur et l'appeler contrôle d'entrée. C’est parce qu’un contrôleur Ingress doit également être intégré à l’environnement d’orchestration du conteneur pour atteindre l’évolutivité et la vitesse souhaitées. Pour ce faire, vous avez besoin de quelque chose qui vit dans l’environnement du conteneur et qui parle nativement l’orchestration des conteneurs et BIG-IP.
C'est ce que fait le contrôleur BIG-IP pour Kubernetes . Il s'agit d'un conteneur Docker qui s'exécute dans un pod Kubernetes et vous permet d'utiliser un BIG-IP comme contrôleur d'entrée Kubernetes. Cela signifie qu'il peut lire la ressource Kubernetes Ingress et configurer automatiquement BIG-IP avec les objets appropriés pour garantir que les requêtes sont mises à l'échelle en fonction des constructions de couche d'application souhaitées.
Avant la disponibilité de ce contrôleur, les utilisateurs avaient tendance à utiliser BIG-IP pour « pulvériser » le trafic sur une deuxième couche de proxys exécutés dans l’environnement d’orchestration des conteneurs. Ces proxys fournissaient un contrôle d'entrée. Il existe quelques bonnes raisons d'arrêter de faire cela, notamment le casse-tête récursif que représente l'exécution de votre service de disponibilité à l'intérieur de l'élément pour lequel il fournit la disponibilité.
D’autres bonnes raisons incluent :
- Activation de l'atténuation des attaques DDoS
- Profitez d'un pare-feu d'application Web pour protéger les API et les applications
- Prend en charge les clients IPv6 pour utiliser les applications conteneurisées IPv4
- Déchargez TLS vers BIG-IP et recryptez avec des certificats auto-signés
- Utilisez les options d’accélération des applications pour améliorer les performances
Quelle que soit la raison, la réalité est que vous pouvez utiliser un BIG-IP comme contrôleur d’entrée pour Kubernetes. Vous n’avez pas besoin de deux niveaux différents pour évoluer. L’élimination de ce deuxième niveau d’échelle améliorera la vitesse (de livraison et de déploiement) et simplifiera les déploiements tout en fournissant une plate-forme sur laquelle vous pouvez activer une grande variété de services avancés pour la sécurité, la vitesse et l’évolutivité.
Vous pouvez en savoir plus sur le contrôleur BIG-IP pour Kubernetes ici , ou l'obtenir à partir du hub Docker, ici ou simplement l'extraire directement :
docker pull f5networks/k8s-bigip-ctlr
Échelle allumée.
* Oui, le « I » majuscule est important, car il le distingue du terme réseau traditionnel « ingress » qui fait simplement référence à « l'accès à l'environnement » alors que « Ingress » est utilisé pour faire référence au « routage HTTP ». Oui, nous avons tendance à rendre les choses plus difficiles qu’elles ne devraient l’être, mais tel est le monde dans lequel les développeurs mettent en œuvre des structures de réseau et redéfinissent bien plus que la simple manière dont les applications sont livrées.