Guide pour choisir un contrôleur Ingress, partie 1 : identifiez vos besoins

Jenn GileResponsable du marketing produit, NGINX

Éditeur – Cet article fait partie d’une série en 10 volets :

1. Réduisez la complexité grâce à Kubernetes prêt pour la production
2. Comment améliorer la résilience dans Kubernetes grâce à une 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 Ingress, 1re partie : identifiez vos besoins (cet article)
6. Guide pour choisir un contrôleur Ingress, 2e partie : risques et pérennisation
7. Guide pour choisir un contrôleur Ingress, 3e partie : open source, par défaut ou commercial
8. Guide pour choisir un contrôleur Ingress, 4e partie : les options de contrôleur Ingress NGINX
9. Comment choisir un maillage de services
10. Tests de performance des contrôleurs Ingress NGINX dans un environnement cloud Kubernetes dynamique

Vous pouvez également télécharger l’intégralité de cette série d’articles sous la forme d’un e-book gratuit : « Faire passer Kubernetes des tests à la production ».

Lorsque les entreprises commencent à expérimenter Kubernetes, elles ne réfléchissent souvent pas beaucoup au choix du contrôleur Ingress. Elles peuvent penser que tous les contrôleurs Ingress se valent et que, pour être rapidement opérationnelles, le plus simple est de conserver le contrôleur Ingress par défaut du framework Kubernetes qu’elles ont choisi. Et il est vrai que pratiquement n’importe quel contrôleur Ingress convient aux environnements de test ou de production à faible trafic. Mais à mesure que vous montez en charge, le choix du contrôleur Ingress devient plus important. En effet, les contrôleurs Ingress peuvent offrir bien plus que la fonctionnalité de base consistant à acheminer votre trafic du point A au point B.

De la gestion avancée du trafic à l’observabilité, 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. Chez F5 NGINX, nous le considérons d’ailleurs comme le socle de tout déploiement Kubernetes adapté à la production. Pourtant, de nombreux développeurs et membres des équipes Platform Ops ne mesurent pas toute la puissance d’un contrôleur Ingress, ni les conséquences du choix d’une solution incapable de monter en charge. Choisir un contrôleur Ingress qui évolue mal ou ne protège pas les environnements complexes peut vous empêcher de faire passer Kubernetes de la phase de test à la production. Dans cette série d’articles de blog, nous souhaitons vous présenter les principes fondamentaux des contrôleurs Ingress et vous aider à faire un choix éclairé afin de bénéficier des fonctionnalités et de la sécurité dont vous avez besoin, aujourd’hui comme demain.

Qu’est-ce qu’un contrôleur Ingress ?

Un contrôleur Ingress est un équilibreur de charge spécialisé qui gère le trafic de couches 4 et 7 entrant dans les clusters Kubernetes, et éventuellement le trafic qui en sort. Afin que nous parlions tous le même langage, voici les termes que nous utilisons chez NGINX (ils sont globalement identiques dans l’ensemble du secteur) :

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

Pourquoi avez-vous besoin d’un contrôleur Ingress ?

Par défaut, les applications exécutées dans des 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 la manière dont 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 afin de définir les règles de connectivité, notamment le chemin d’URI, le nom du service backend et d’autres informations. Toutefois, la ressource Ingress ne fait rien à elle seule. Vous devez déployer et configurer une application de contrôleur Ingress (à l’aide de l’API Kubernetes) pour appliquer les règles définies dans les ressources Ingress.

À quoi sert un contrôleur Ingress ?

• Accepte le trafic provenant de l’extérieur de l’environnement Kubernetes, peut éventuellement le modifier (le façonner) et le distribue aux pods exécutés au sein de l’environnement. Le contrôleur Ingress remplace le modèle de distribution du trafic par défaut de kube-proxy traffic distribution model, et vous offre ainsi des contrôles supplémentaires similaires à ceux proposés par les contrôleurs de mise à disposition d’applications (ADC) et les proxys inverses dans les environnements non Kubernetes.
• Surveille les différents pods d’un service, garantissant ainsi un routage intelligent et empêchant les requêtes de finir dans un « trou noir ».
• Met en œuvre des règles de trafic sortant afin de renforcer la sécurité grâce au protocole TLS mutuel (mTLS) ou de limiter le trafic sortant de certains pods à des services externes spécifiques.

Au moment de choisir un contrôleur Ingress, il peut être tentant de commencer par dresser une liste de fonctionnalités. Vous risquez toutefois de vous retrouver avec un contrôleur Ingress doté de fonctionnalités exceptionnelles, mais qui ne répond pas aux besoins de votre entreprise. Veillez plutôt à examiner deux éléments qui détermineront dans quelle mesure le contrôleur Ingress conviendra à votre équipe et à vos applications : les cas d’usage (les problèmes qu’il résoudra) et les ressources (la manière dont vous allez le « financer »). Nous aborderons ces deux sujets dans la suite de cet article.

Quels problèmes souhaitez-vous résoudre avec le contrôleur Ingress ?

Le principal cas d’usage d’un contrôleur Ingress est la gestion du trafic. Vous souhaitez donc probablement que le contrôleur Ingress prenne en charge un ou plusieurs des cas d’usage courants suivants :

• Équilibrage de charge (HTTP2, HTTP/HTTPS, terminaison SSL/TLS, TCP/UDP, WebSocket, gRPC)
• Contrôle du trafic (limitation du débit, disjonction, contrôles d’intégrité 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 outil qui ne sait faire qu’une seule chose : la plupart des contrôleurs Ingress peuvent faire bien plus que gérer le trafic. En utilisant le contrôleur Ingress pour résoudre plusieurs problèmes, vous réduisez non seulement la taille et la complexité de votre pile, mais vous pouvez également transférer les exigences non fonctionnelles des applications vers le contrôleur Ingress. Examinons quatre cas d’usage non conventionnels des contrôleurs Ingress qui peuvent contribuer à rendre vos déploiements Kubernetes plus sécurisés, agiles et évolutifs, tout en optimisant l’utilisation de vos ressources.

Surveillance et visibilité

Le manque de visibilité sur le cluster Kubernetes constitue l’un des principaux défis dans les environnements de production, car il complique le dépannage et nuit à la résilience. Comme les contrôleurs Ingress fonctionnent à la périphérie de vos clusters Kubernetes et traitent l’intégralité du trafic, ils sont idéalement placés pour fournir des données qui peuvent vous aider à diagnostiquer (voire à éviter) deux problèmes courants : la lenteur des applications et l’épuisement des ressources du cluster ou de la plateforme Kubernetes. Pour améliorer la visibilité, un contrôleur Ingress doit :

• Fournir des métriques en temps réel afin de pouvoir diagnostiquer ce qui se passe « à l’instant présent »
• Permettre l’exportation des métriques vers des outils d’observabilité courants, tels que Prometheus et Grafana, qui représentent les valeurs dans le temps afin de vous aider à anticiper les pics de trafic et d’autres tendances

Passerelle API

À moins que vous ne cherchiez à manipuler les requêtes et les réponses dans Kubernetes, il est fort probable que le contrôleur Ingress puisse également faire office de passerelle API. Selon les fonctionnalités dont il dispose, un contrôleur Ingress peut être en mesure d’assurer les fonctions essentielles d’une passerelle API, notamment la terminaison TLS, l’authentification des clients, la limitation du débit, le contrôle d’accès granulaire et le routage des requêtes des couches 4 à 7.

Authentification et authentification unique

Déléguer l’authentification des identifiants de connexion de vos services Kubernetes à votre contrôleur Ingress permet de résoudre deux problèmes.

• Permettez aux utilisateurs de se connecter à plusieurs applications avec un seul jeu d’identifiants en mettant en œuvre l’authentification unique (SSO) avec OpenID Connect (OIDC).
• Éliminez la nécessité de développer des fonctionnalités d’authentification dans chaque application, afin que vos développeurs puissent se concentrer sur la logique métier de leurs applications.

Intégration d’un pare-feu applicatif web

Il ne s’agit pas pour un contrôleur Ingress de faire office de pare-feu d’applications web (WAF), mais plutôt d’intégrer le WAF au contrôleur Ingress. Bien qu’un WAF puisse être déployé à de nombreux endroits, à l’extérieur comme à l’intérieur de Kubernetes, l’emplacement le plus efficace pour la plupart des organisations se trouve dans le même pod que le contrôleur Ingress. Ce cas d’usage est idéal lorsque les politiques de sécurité sont gérées par les équipes SecOps ou DevSecOps et qu’une approche granulaire, par service ou par URI, est nécessaire. Vous pouvez ainsi utiliser l’API Kubernetes pour définir des politiques et les associer à des services. En outre, la fonctionnalité de contrôle d’accès basé sur les rôles (RBAC) du contrôleur Ingress permet aux équipes SecOps d’appliquer des politiques par écouteur, tandis que les utilisateurs DevOps définissent des politiques pour chaque ressource Ingress.

Comment allez-vous allouer des ressources au contrôleur Ingress ?

Chaque contrôleur Ingress a un coût… même ceux qui sont gratuits et open source (vous avez peut-être déjà entendu l’expression « gratuit comme un chiot »). Certains coûts peuvent être chiffrés de manière prévisible et inscrits comme postes dans votre budget, tandis que d’autres dépendent du temps que votre équipe doit consacrer à gérer les conséquences du choix de votre contrôleur Ingress (complexité accrue, manque de portabilité, etc.). Examinons les coûts, en temps comme en argent, à prendre en compte lors de l’établissement du budget d’un contrôleur Ingress.

Budgétiser le coût du temps

Établir un budget pour les effectifs peut s’avérer bien plus complexe que pour des postes à coûts fixes, surtout lorsqu’il faut affecter des ressources à un projet dans un domaine que l’on connaît mal. Il convient alors de se poser des questions telles que :

• Qui configurera et administrera le contrôleur Ingress ? Cela fait-il partie de ses fonctions à temps plein (par exemple, en tant que membre de votre équipe chargée des opérations de plateforme) ou s’agit-il d’une responsabilité supplémentaire (en tant que développeur) ?
• Pouvez-vous dégager du temps pour permettre aux employés de suivre une formation formelle ? Ou l’outil doit-il être suffisamment simple pour être pris en main rapidement et facilement dans le cadre de leur travail ?
• Êtes-vous prêt à laisser vos employés bricoler l’outil chaque fois qu’une nouvelle fonctionnalité est nécessaire, ou passer beaucoup de temps à résoudre les problèmes lorsqu’ils surviennent ? Ou avez-vous besoin qu’ils se consacrent à d’autres activités créatrices de valeur pour l’entreprise ?

Remarque sur la responsabilité des outils Kubernetes

Nous avons observé dans le secteur une tendance à regrouper les outils et leur gestion sous la responsabilité des équipes NetOps. Bien que cela puisse grandement contribuer à simplifier votre environnement technologique et à renforcer la sécurité, nous préconisons une duplication réfléchie des outils en fonction des objectifs des équipes. Il est logique de confier aux équipes NetOps la gestion des outils périmétriques (comme les répartiteurs de charge externes), car elles se concentrent sur la plateforme dans son ensemble. En revanche, les équipes DevOps s’intéressent avant tout aux services déployés au plus près du code applicatif et ont besoin de davantage d’agilité et d’un contrôle plus précis que ne leur offrent les outils NetOps. Les outils Kubernetes, notamment le contrôleur Ingress, ont les meilleures chances de réussir lorsqu’ils sont choisis par les équipes DevOps. Cela ne signifie pas pour autant qu’il faille laisser aux développeurs une liberté totale dans le choix des outils ! Une standardisation stricte des outils au sein de Kubernetes reste une bonne pratique.

Budgétisation des dépenses d’investissement

Lorsque les entreprises commencent à expérimenter Kubernetes, elles prévoient souvent peu de budget pour les outils ou l’assistance. Si vous disposez des ressources humaines nécessaires pour assurer pleinement la gestion d’un contrôleur Ingress qui demande davantage d’accompagnement, vous pouvez vous passer de budget financier… dans un premier temps. Mais à mesure que vos investissements dans Kubernetes augmentent, vous risquez de vous retrouver limité par les fonctionnalités de l’outil ou de vouloir affecter votre équipe à d’autres priorités. C’est alors que la balance penche en faveur d’un outil payant, plus facile à utiliser et plus stable, doté de fonctionnalités destinées aux entreprises et assorti d’une assistance.

Lorsque vous êtes prêt à investir dans un contrôleur Ingress, gardez à l’esprit que le modèle de licence est important. Inspirée des modèles tarifaires traditionnels utilisés en dehors de Kubernetes, la tarification des contrôleurs Ingress est souvent établie « par instance » ou « par proxy Ingress ». Bien que cette approche puisse encore être pertinente pour certains cas d’usage dans Kubernetes, une licence de contrôleur Ingress facturée « par cluster » signifie que vous payez en fonction de l’hébergement des applications plutôt que du « nombre de proxys ».

Voici nos recommandations pour différents scénarios :

• Vous débutez avec Kubernetes ? Optez pour une licence par cluster.
  Lorsque vous manquez d’expérience avec Kubernetes, il est très difficile de prévoir avec précision le nombre d’instances de contrôleur Ingress dont vous avez besoin. Si vous devez choisir un nombre d’instances, vous risquez de le sous-estimer — ce qui compliquera l’atteinte de vos objectifs — ou de le surestimer et de gaspiller des fonds qui seraient mieux investis dans d’autres aspects du projet Kubernetes. Négocier un prix fixe relativement bas pour un « petit cluster » augmente vos chances de réussite.
• Vous faites évoluer Kubernetes à grande échelle ? Optez pour une licence par cluster.
  Il est presque impossible de prévoir dans quelle mesure et à quelle fréquence vous devrez augmenter ou réduire les ressources Kubernetes (expansion et contraction). La tarification par instance oblige votre équipe à définir des seuils arbitraires pour respecter les limites imposées par les licences. Avec une licence par cluster, vous n’avez pas à assurer le suivi de chaque conteneur Ingress et, selon le fournisseur (comme NGINX), l’expansion peut être incluse sans frais supplémentaires.
• Déploiements avancés ou statiques ? Optez pour 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 besoin d’aucun des services groupés éventuellement fournis avec l’outil, la tarification par instance peut être un excellent choix.

Prochaines étapes : tolérance au risque et pérennisation

Maintenant que vous avez une bonne compréhension de vos besoins, l’étape suivante consiste à déterminer en équipe votre niveau de tolérance face aux risques qu’un contrôleur Ingress pourrait introduire, ainsi que la manière dont celui-ci devra évoluer à mesure que votre déploiement Kubernetes prendra de l’ampleur. Nous abordons ces sujets dans la partie 2.

À propos de l’auteur

Jenn GileResponsable du marketing produit, NGINX

Autres articles de Jenn Gile