Guide pour choisir un contrôleur d'entrée, partie 1 : Identifiez vos besoins

Rédacteur – Ce billet fait partie d’ une série en 10 parties :

1. Réduisez la complexité avec Kubernetes de niveau production
2. Comment améliorer la résilience dans Kubernetes grâce à la gestion avancée du trafic
3. Comment améliorer la visibilité dans Kubernetes
4. Six façons de sécuriser Kubernetes à l'aide d'outils de gestion du trafic
5. Guide pour choisir un contrôleur d'entrée, partie 1 : Identifiez vos besoins (ce post)
6. Guide pour choisir un contrôleur d'entrée, partie 2 : Risques et pérennité
7. Guide pour choisir un contrôleur d'entrée, partie 3 : Open Source contre Par défaut vs. Commercial
8. Guide pour choisir un contrôleur d'entrée, partie 4 : Options du contrôleur d'entrée NGINX
9. Comment choisir un maillage de services
10. Test des performances des contrôleurs d'entrée NGINX dans un environnement cloud Kubernetes dynamique

Vous pouvez également télécharger l’ensemble complet des blogs sous forme d’eBook gratuit – Taking Kubernetes from Test to Production .

Lorsque les organisations commencent à expérimenter Kubernetes, elles ne réfléchissent souvent pas beaucoup au choix du contrôleur Ingress . Ils pourraient penser que tous les contrôleurs Ingress sont identiques et que, dans l’intérêt d’une mise en service rapide, il est plus simple de s’en tenir au contrôleur Ingress par défaut pour le framework Kubernetes qu’ils ont choisi. Et il est vrai que presque tous les contrôleurs Ingress conviennent parfaitement aux environnements de test ou de production à faible volume. Mais à mesure que vous évoluez, votre choix de contrôleur Ingress devient plus important. C'est parce que les contrôleurs Ingress peuvent fournir bien plus que la fonctionnalité de base consistant à déplacer votre trafic du point A au point B.

De la gestion avancée du trafic à la visibilité en passant par la sécurité intégrée, un contrôleur Ingress peut être l’un des outils les plus puissants de votre pile Kubernetes. En fait, chez F5 NGINX, nous considérons qu’il s’agit de la base de tout déploiement Kubernetes de niveau production . Mais de nombreux développeurs et équipes Platform Ops ne réalisent pas toute la puissance d'un contrôleur Ingress, ni les conséquences du choix d'un contrôleur qui ne peut pas évoluer. Le choix d'un contrôleur Ingress qui n'est pas évolutif ou qui ne protège pas les environnements complexes peut vous empêcher de sortir Kubernetes des tests et de le mettre en production. Dans cette série de blogs, nous visons à vous renseigner sur les bases des contrôleurs Ingress et à vous expliquer comment faire un choix judicieux qui offre les fonctionnalités et la sécurité dont vous avez besoin, aujourd'hui et demain.

Qu'est-ce qu'un contrôleur d'entrée ?

Un contrôleur Ingress est un équilibreur de charge spécialisé qui gère le trafic de couche 4 et 7 entrant dans les clusters Kubernetes, et potentiellement le trafic qui en sort. Pour que nous soyons tous sur la même longueur d'onde, voici les termes que nous utilisons chez NGINX (et ils sont en grande partie les mêmes dans l'ensemble du secteur) :

• Trafic entrant – Trafic entrant dans un cluster Kubernetes
• Trafic sortant – Trafic sortant d’un cluster Kubernetes
• Trafic nord-sud – Trafic entrant et sortant d’un cluster Kubernetes (également appelé trafic entrant-sortant )
• Trafic est-ouest – Trafic circulant entre les services au sein d’un cluster Kubernetes (également appelé trafic de service à service )
• Service mesh – Un outil de gestion du trafic pour acheminer et sécuriser le trafic de service à service

Pourquoi avez-vous besoin d’un contrôleur d’entrée ?

Par défaut, les applications exécutées dans les pods Kubernetes (conteneurs) ne sont pas accessibles depuis le réseau externe, mais uniquement depuis d'autres pods au sein du cluster Kubernetes. Kubernetes dispose d’un objet de configuration intégré pour l’équilibrage de charge HTTP, appelé Ingress , qui définit comment les entités extérieures à un cluster Kubernetes peuvent se connecter aux pods représentés par un ou plusieurs services Kubernetes.

Lorsque vous devez permettre un accès externe à vos services Kubernetes, vous créez une ressource Ingress pour définir les règles de connexion, notamment le chemin URI, le nom du service support et d’autres détails. Cependant, la ressource Ingress ne fonctionne pas sans autre intervention. Vous devez déployer et configurer une application contrôleur Ingress (via l’API Kubernetes) pour appliquer les règles spécifiées dans les ressources Ingress.

Que fait un contrôleur d’entrée ?

• Accepte le trafic provenant de l'extérieur de l'environnement Kubernetes, le modifie (façonne) potentiellement et le distribue aux pods exécutés à l'intérieur de l'environnement. Le contrôleur Ingress remplace le modèle de distribution du trafic Kube-Proxy par défaut, vous offrant des contrôles supplémentaires comme ceux fournis par les contrôleurs de distribution d'applications (ADC) et les proxys inverses dans les environnements non Kubernetes.
• Surveille les pods individuels d'un service, garantissant un routage intelligent et empêchant les requêtes d'être « bloquées ».
• Implémente des règles de sortie pour améliorer la sécurité avec TLS mutuel (mTLS) ou limiter le trafic sortant de certains pods vers des services externes spécifiques.

Quand vient le moment de choisir un contrôleur Ingress, vous pouvez être tenté de partir d’une liste de fonctionnalités, mais vous risqueriez d’adopter un contrôleur Ingress riche en fonctions sans qu’il réponde vraiment aux besoins de votre entreprise. Prenez plutôt le temps d’étudier deux aspects qui déterminent son efficacité pour votre équipe et vos applications : les cas d’utilisation (les défis qu’il doit résoudre) et les ressources allouées (comment vous allez le financer). Nous développerons ces deux points dans la suite de ce blog.

Quels problèmes souhaitez-vous que le contrôleur d’entrée résolve ?

Le cas d'utilisation principal d'un contrôleur Ingress est la gestion du trafic. Vous souhaitez donc probablement que le contrôleur Ingress gère un ou plusieurs de ces cas d'utilisation courants :

• Équilibrage de charge (HTTP2, HTTP/HTTPS, terminaison SSL/TLS, TCP/UDP, WebSocket, gRPC)
• Contrôle du trafic (limitation du débit, coupure de circuit, contrôles de santé actifs)
• Répartition du trafic (routage de débogage, tests A/B, déploiements Canary, déploiements bleu-vert)

Mais vous n’êtes pas obligé de vous limiter à un seul rôle : la plupart des contrôleurs Ingress offrent bien plus que la gestion du trafic. En sollicitant le contrôleur Ingress pour résoudre plusieurs défis, vous réduisez la taille et la complexité de votre infrastructure, tout en déchargeant les exigences non fonctionnelles des applications vers le contrôleur Ingress. Découvrons quatre usages innovants des contrôleurs Ingress qui renforcent la sécurité, la souplesse et la scalabilité de vos déploiements Kubernetes, tout en optimisant l’usage de vos ressources.

Suivi et visibilité

L'absence de visibilité sur le cluster Kubernetes constitue un des principaux défis en environnement de production, rendant le dépannage et la résilience plus difficiles. Puisque les contrôleurs Ingress se situent à la périphérie de vos clusters Kubernetes et traitent chaque segment de trafic, ils sont idéalement placés pour fournir des informations qui vous aideront à résoudre, voire à prévenir, deux problèmes fréquents : la lenteur des applications et l'épuisement des ressources dans le cluster ou la plateforme Kubernetes. Pour que le contrôleur Ingress améliore la visibilité, il doit :

• Fournissez des mesures en temps réel afin de pouvoir diagnostiquer ce qui se passe « en ce moment »
• Être capable d'exporter des métriques vers des outils de visibilité populaires, comme Prometheus et Grafana, qui tracent des valeurs au fil du temps pour vous aider à prévoir les pics de trafic et d'autres tendances

Passerelle API

À moins que vous ne cherchiez à effectuer une manipulation de requête-réponse dans Kubernetes, il est très probable que le contrôleur Ingress puisse également servir de passerelle API. En fonction de son ensemble de fonctionnalités, un contrôleur Ingress peut être en mesure de fournir des fonctions de passerelle API de base, notamment la terminaison TLS, l’authentification client, la limitation du débit, le contrôle d’accès précis et le routage des requêtes aux couches 4 à 7.

Authentification et authentification unique

Le déchargement de l’authentification des informations de connexion de vos services Kubernetes vers votre contrôleur Ingress peut résoudre deux problèmes.

• Permettez aux utilisateurs de se connecter à plusieurs applications avec un seul ensemble d’informations d’identification en implémentant l’authentification unique (SSO) avec OpenID Connect (OIDC).
• Éliminez le besoin d’intégrer une fonctionnalité d’authentification dans chaque application, permettant à vos développeurs de se concentrer sur la logique métier de leurs applications.

Intégration du pare-feu d'application Web

Ce n’est pas que le contrôleur Ingress fasse office de pare-feu applicatif (WAF), mais plutôt que vous puissiez intégrer le WAF directement avec le contrôleur Ingress. Même si un WAF peut être déployé à divers endroits, à l’intérieur ou à l’extérieur de Kubernetes, pour la majorité des organisations, le choix le plus efficace reste de l’installer dans le même pod que le contrôleur Ingress. Ce scénario convient parfaitement lorsque SecOps ou DevSecOps pilotent les politiques de sécurité et qu’une approche fine, au niveau de chaque service ou URI, s’impose. Ainsi, vous pouvez utiliser l’API Kubernetes pour définir vos politiques et les associer aux services concernés. De plus, le contrôle d’accès basé sur les rôles (RBAC) offert par le contrôleur Ingress permet à SecOps d’appliquer les politiques à chaque écouteur, tandis que DevOps configure des politiques par ressource Ingress.

Comment allez-vous approvisionner le contrôleur d'entrée ?

Chaque contrôleur Ingress entraîne un coût… même les gratuits et logiciels libres (vous avez peut-être entendu l'expression « gratuit comme un chiot »). Certains coûts se traduisent par des montants précis dans votre budget, d’autres dépendent du temps que votre équipe devra consacrer pour gérer les conséquences liées à votre choix de contrôleur Ingress (complexité accrue, manque de portabilité, et plus encore). Examinons les coûts – en temps et en argent – que vous devez considérer pour budgéter un contrôleur Ingress.

Budgétisation des coûts liés au temps

La budgétisation des effectifs peut s’avérer bien plus difficile que celle des postes à coûts fixes, en particulier lorsque vous essayez de financer un projet dans un espace inconnu. Vous devez poser des questions telles que :

• Qui configurera et administrera le contrôleur Ingress ? Cela fait-il partie de leur travail à temps plein (par exemple, en tant que membres de votre équipe Platform Ops) ou l’assument-ils comme une responsabilité supplémentaire (en tant que développeurs) ?
• Pouvez-vous consacrer du temps à vos employés pour qu’ils suivent une formation formelle ? Ou l’outil doit-il être suffisamment simple pour être appris rapidement et facilement sur le terrain ?
• Êtes-vous prêt à ce que vos employés modifient le système chaque fois qu’une nouvelle fonctionnalité est nécessaire ou à consacrer beaucoup de temps au dépannage en cas de problème ? Ou avez-vous besoin qu’ils apportent une autre valeur commerciale ?

Remarque sur la propriété des outils Kubernetes

Nous avons observé une tendance dans l’industrie vers la consolidation des outils et de la propriété sous le domaine des équipes NetOps. Bien que cela puisse contribuer grandement à simplifier votre pile et à améliorer la sécurité, nous préconisons une duplication réfléchie des outils en fonction des objectifs de l'équipe . Il est logique que l'équipe NetOps gère les outils de périmètre (comme les équilibreurs de charge externes), car ils se concentrent sur la plate-forme plus large, mais les équipes DevOps se soucient surtout des services déployés à proximité du code de l'application et ont besoin de plus d'agilité et d'un contrôle plus précis que ceux qu'elles obtiennent avec les outils NetOps. Les outils Kubernetes, y compris le contrôleur Ingress, ont les meilleures chances de succès lorsqu'ils sont sélectionnés par DevOps. Cela ne veut pas dire que vous devez accorder aux développeurs une totale liberté de choix en matière d’outils ! Une standardisation brutale des outils au sein de Kubernetes reste une bonne pratique.

Budgétisation des coûts d'investissement

Lorsque vous débutez avec Kubernetes, vous ne prévoyez souvent pas beaucoup de budget pour les outils ou le support. Si vous avez les ressources humaines nécessaires pour accompagner pleinement un contrôleur Ingress qui demande un suivi accru, un budget financier limité suffit… au départ. Mais à mesure que votre investissement dans Kubernetes grandit, vous pouvez constater des contraintes sur les fonctionnalités de l’outil, ou vouloir que votre équipe se concentre sur d’autres priorités. C’est à ce moment que vous préférez investir dans un outil plus simple d’utilisation, plus stable, offrant des fonctionnalités d’entreprise et un support dédié.

Lorsque vous êtes prêt à payer pour un contrôleur Ingress, sachez que le modèle de licence est important. Sur la base des modèles de tarification traditionnels en dehors de Kubernetes, la tarification des contrôleurs Ingress est souvent « par instance » ou « par proxy Ingress ». Bien qu'il existe des cas d'utilisation où cela a encore du sens dans Kubernetes, l'octroi d'une licence pour un contrôleur Ingress sur une base « par cluster » signifie plutôt que vous payez en fonction de la location de l'application plutôt que du « nombre de proxys ».

Voici nos recommandations pour différents scénarios :

• Vous débutez avec Kubernetes ? Choisissez une licence par cluster.
  Lorsque vous n’avez aucune expérience avec Kubernetes, il est très difficile de prédire avec précision le nombre d’instances de contrôleur Ingress dont vous avez besoin. Si vous êtes obligé de choisir un certain nombre d'instances, vous risquez de les sous-estimer – ce qui rendrait difficile la réalisation de vos objectifs – ou de les surestimer et de gaspiller des dollars qui seraient mieux dépensés sur d'autres parties du projet Kubernetes. Négocier un prix fixe relativement bas pour un « petit cluster » augmente vos chances de succès.
• Vous faites évoluer Kubernetes ? Optez pour un contrat de licence par cluster.
  Il est pratiquement impossible d'anticiper la quantité et la fréquence des besoins en ressources Kubernetes, que ce soit en montée ou en descente. La tarification à l'instance vous oblige à fixer des seuils arbitraires pour respecter les limites du contrat de licence. Avec un contrat par cluster, vous n’avez pas à suivre chaque conteneur Ingress individuellement, et selon le fournisseur (comme NGINX), les pics peuvent être inclus sans coût supplémentaire.
• Déploiements avancés ou statiques ? Choisissez une licence par instance.
  Si vous maîtrisez suffisamment Kubernetes pour savoir exactement comment vous allez utiliser le contrôleur Ingress, que vous prévoyez d’utiliser un petit nombre de proxys Ingress par cluster et que vous n’avez pas besoin de services groupés pouvant accompagner l’outil, la tarification par instance peut être un excellent choix.

Prochaines étapes : Tolérance au risque et préparation à l’avenir

Maintenant que vous avez une idée de vos besoins, l'étape suivante consiste à décider en équipe de votre tolérance aux risques qu'un contrôleur Ingress pourrait introduire et à déterminer comment vous aurez besoin du contrôleur Ingress pour évoluer à mesure que vous développez votre déploiement Kubernetes. Nous abordons ces sujets dans la deuxième partie .