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 fournir un accès externe à vos services Kubernetes, vous créez une ressource Ingress pour définir les règles de connectivité, notamment le chemin URI, le nom du service de sauvegarde et d'autres informations. Cependant, à elle seule, la ressource Ingress ne fait rien. Vous devez déployer et configurer une application de contrôleur Ingress (à l’aide de l’API Kubernetes) pour implémenter les règles définies 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.

Lorsqu’il est temps de sélectionner un contrôleur Ingress, il peut être tentant de commencer par une liste de fonctionnalités, mais vous risquez de vous retrouver avec un contrôleur Ingress doté de fonctionnalités fantastiques mais qui ne répond pas aux besoins de votre entreprise. Assurez-vous plutôt d’explorer deux éléments qui ont un impact sur le bon fonctionnement du contrôleur Ingress pour votre équipe et vos applications : les cas d’utilisation (quels problèmes il résoudra) et les ressources (comment vous allez le « payer »). Nous aborderons ces deux sujets dans le reste 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 il n’y a aucune raison de se contenter d’un « poney à un seul tour » : la plupart des contrôleurs Ingress peuvent faire plus que gérer le trafic. En utilisant le contrôleur Ingress pour résoudre plusieurs problèmes, non seulement vous réduisez la taille et la complexité de votre pile, mais vous pouvez également décharger les exigences non fonctionnelles des applications vers le contrôleur Ingress. Examinons quatre cas d’utilisation de contrôleur Ingress non traditionnels qui peuvent vous aider à rendre vos déploiements Kubernetes plus sécurisés, agiles et évolutifs tout en optimisant l’utilisation de vos ressources.

Suivi et visibilité

Le manque de visibilité sur le cluster Kubernetes est l’un des plus grands défis dans les environnements de production, contribuant aux difficultés de dépannage et de résilience. Étant donné que les contrôleurs Ingress fonctionnent à la périphérie de vos clusters Kubernetes et touchent chaque élément du trafic, ils sont bien placés pour fournir des données qui peuvent vous aider à résoudre (et même à éviter) deux problèmes courants : les applications lentes 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 qu’un contrôleur Ingress peut servir de pare-feu d’application Web (WAF), mais plutôt que le WAF peut être consolidé avec le contrôleur Ingress. Bien qu'un WAF puisse être déployé à de nombreux endroits en dehors et dans Kubernetes, pour la plupart des organisations, l'emplacement le plus efficace et le plus efficient se trouve dans le même pod que le contrôleur Ingress. Ce cas d’utilisation est parfait lorsque les politiques de sécurité sont sous la direction de SecOps ou DevSecOps et lorsqu’une approche fine, par service ou par URI, est nécessaire. Cela signifie que vous pouvez utiliser l'API Kubernetes pour définir des politiques et les associer à des services. De plus, la fonctionnalité de contrôle d’accès basé sur les rôles (RBAC) du contrôleur Ingress peut permettre à SecOps d’appliquer des politiques par écouteur tandis que les utilisateurs DevOps définissent des politiques par ressource Ingress.

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

Chaque contrôleur Ingress a un coût… même ceux qui sont gratuits et open source (vous avez peut-être entendu l’expression « gratuit comme un chiot »). Certains coûts peuvent être affectés à des montants prévisibles en dollars sous forme de postes budgétaires, tandis que d'autres dépendent du temps que votre équipe doit consacrer à gérer les conséquences du contrôleur Ingress que vous choisissez (complexité accrue, manque de portabilité, etc.). Examinons les coûts – en termes de temps et d’argent – à prendre en compte lors de la budgétisation d’un contrôleur Ingress : temps et argent.

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 les organisations expérimentent Kubernetes pour la première fois, elles ne prévoient souvent pas un budget important pour les outils ou le support. Si vous disposez des ressources humaines nécessaires pour réellement prendre en charge un contrôleur Ingress qui a besoin d’une « assistance » plus poussée, alors aucun budget monétaire n’est acceptable… au début. Mais à mesure que votre investissement dans Kubernetes augmente, vous risquez de vous retrouver limité par les fonctionnalités de l'outil ou de vouloir consacrer votre équipe à d'autres priorités. C'est alors que la balance penche en faveur du paiement d'un outil plus simple à utiliser , plus stable, doté de fonctionnalités et d'un support d'entreprise.

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.
• Mise à l’échelle de Kubernetes ? Choisissez une licence par cluster.
  Il est presque impossible de prédire dans quelle mesure et à quelle fréquence vous devrez augmenter ou diminuer les ressources Kubernetes (explosion et effondrement). La tarification par instance oblige votre équipe à imposer des seuils arbitraires pour rester dans les limites des licences. Avec les licences par cluster, vous n’avez pas besoin de suivre les conteneurs Ingress individuels et, selon le fournisseur (comme NGINX), le bursting peut être inclus sans frais supplémentaires.
• 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 .