Rédacteur – Ce billet fait partie d’ une série en 10 parties :
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.
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) :
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.
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.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.
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 :
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.
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 :
À 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.
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.
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.
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.
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 :
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.
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 :
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 .
« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."