Lors du déploiement d'un cluster Kubernetes pour une application spécifique, il est essentiel de comprendre les exigences que cette application, le business et les développeurs ont vis-à-vis de cette ressource. Avec cette information, on peut commencer à prendre des décisions architecturales, et en particulier, choisir un contrôleur Ingress précis, car il en existe aujourd'hui un grand nombre. Pour donner une idée de base des options disponibles sans avoir à étudier une multitude d'articles/documentations, nous avons préparé cet aperçu, incluant les principaux contrôleurs Ingress (prêts pour la production).
Nous espérons qu'il aidera nos collègues dans le choix de solutions architecturales — du moins, qu'il servira de point de départ pour obtenir des informations plus détaillées et pour des expérimentations pratiques. Au préalable, nous avons étudié d'autres documents similaires en ligne et, contre toute attente, nous n'avons trouvé aucun aperçu complet, et surtout, structuré. Comblons donc cette lacune !
Critères
Pour effectuer une comparaison et obtenir un résultat utile, il est nécessaire de comprendre non seulement le domaine thématique, mais aussi de disposer d'une liste concrète de critères qui orienteront l'étude. Sans prétendre à une analyse de tous les cas d'utilisation possibles d'Ingress/Kubernetes, nous avons essayé de mettre en avant les exigences les plus générales pour les contrôleurs — soyez prêts à ce que toutes vos spécificités et détails devront tout de même être examinés séparément.
Mais je commencerai par les caractéristiques qui sont devenues si familières qu'elles sont intégrées dans toutes les solutions et ne sont pas considérées :
- découverte dynamique des services (service discovery);
- terminaison SSL;
- travail avec les websockets.
Maintenant — sur les points de comparaison :
Protocoles supportés
Un des critères fondamentaux lors du choix. Votre logiciel peut ne pas fonctionner selon le standard HTTP ou nécessiter l'utilisation simultanée de plusieurs protocoles. Si votre cas est atypique, tenez compte de ce facteur pour éviter de devoir reconfigurer le cluster par la suite. La liste des protocoles pris en charge varie d'un contrôleur à l'autre.
Logiciel sous-jacent
Il existe plusieurs options d'applications sur lesquelles est basée le contrôleur. Les plus populaires sont nginx, traefik, haproxy, envoy. En général, cela peut ne pas trop influencer la façon dont le trafic est reçu et transmis, mais il est toujours utile de connaître les nuances et les caractéristiques de ce qui est « sous le capot ».
Routage du trafic
Sur quoi peut-on se baser pour décider de la direction du trafic vers un service donné ? En général, ce sont l'hôte et le chemin, mais il existe aussi des possibilités supplémentaires.
Espace de noms au sein du cluster
L'espace de noms (namespace) est une possibilité de diviser logiquement les ressources dans Kubernetes (par exemple, en stage, production, etc.). Certains Ingress-contrôleurs doivent être installés séparément dans chaque namespace (et pouvoir diriger le trafic vers les pods de cet espace). D'autres (et c'est clairement la majorité) fonctionnent de manière globale sur l'ensemble du cluster — le trafic y est dirigé vers n'importe quel pod du cluster, indépendamment de l'espace de noms. uniquement pour les pods de cet espace).
Sondes pour les upstreams
Comment s'assure-t-on que le trafic est dirigé vers des instances saines de l'application ou des services ? Il existe des options avec des vérifications actives et passives, des réessais (retries), des disjoncteurs (pour en savoir plus, voir par exemple, ), des mises en œuvre personnalisées de vérifications d'état (custom health checks), etc. C'est un paramètre très important si vous avez des exigences élevées en matière de disponibilité et de sortie rapide des services défaillants de l'équilibrage.
Algorithmes d'équilibrage
Il existe de nombreuses options : des plus traditionnelles aux plus exotiques comme , ainsi que des possibilités individuelles comme .
Authentification
Quelles schémas d'autorisation le contrôleur prend-il en charge ? Basic, digest, oauth, external-auth — je pense que ces options devraient vous être familières. C'est un critère important si plusieurs environnements sont utilisés pour les développeurs (et/ou simplement fermés), accessibles via Ingress.
Répartition du trafic
Le contrôleur prend-il en charge des mécanismes souvent utilisés pour la répartition du trafic, tels que les déploiements canari (canary), les tests A/B, le mirroring du trafic (mirroring/shadowing) ? C'est un véritable sujet problématique pour les applications qui nécessitent une gestion précise et soigneuse du trafic pour des tests en production, un débogage d'erreurs produit sans impact (ou avec des pertes minimales), une analyse du trafic, etc.
Abonnement payant
Existe-t-il une version payante du contrôleur, avec des fonctionnalités avancées et/ou un support technique ?
Interface graphique (Web UI)
Y a-t-il une interface graphique pour gérer la configuration du contrôleur ? Principalement pour « praticité » et/ou pour ceux qui doivent apporter des modifications à la configuration de l'Ingress, mais il est peu pratique de travailler avec des « modèles bruts ». Cela peut être utile si les développeurs souhaitent expérimenter en temps réel avec le trafic.
Validation JWT
Présence d'une vérification intégrée des JSON web tokens pour l'autorisation et la validation des utilisateurs d'applications finales.
Options de personnalisation de la configuration
Extensibilité des modèles en termes de mécanismes permettant d'ajouter des directives, des flags, etc. aux modèles de configuration standard.
Mécanismes de protection de base contre les DDOS
Algorithmes simples de limitation de débit ou des variantes plus complexes de filtrage de trafic basées sur des adresses, des listes blanches, des pays, etc.
Traçage des requêtes
Capacités de surveillance, de suivi et de débogage des requêtes de l'Ingress vers des services/pods spécifiques, et idéalement — entre services/pods également.
WAF
Support .
Contrôleurs Ingress
La liste des contrôleurs a été établie sur la base de et . Certains d'entre eux ont été exclus de l'examen en raison de leur spécificité ou de leur faible diffusion (stade précoce de développement). Les restants sont examinés ci-dessous. Commençons par une description générale des solutions et poursuivons avec un tableau récapitulatif.
Ingress de Kubernetes
Site :
Licence : Apache 2.0
C'est le contrôleur officiel pour Kubernetes, développé par la communauté. Comme le nom l'indique, il est basé sur nginx et enrichi d'un ensemble varié de plugins Lua utilisés pour mettre en œuvre des fonctionnalités supplémentaires. Grâce à la popularité de nginx lui-même et à des modifications minimales lors de son utilisation comme contrôleur, cette option peut être la plus simple et la plus compréhensible à configurer pour un ingénieur moyen (avec une expérience en web).
Ingress de NGINX Inc
Site :
Licence : Apache 2.0
Produit officiel des développeurs de nginx. Il existe une version payante basée sur . L'idée principale est un niveau élevé de stabilité, une compatibilité descendante constante, l'absence de modules tiers et une vitesse accrue revendiquée (par rapport au contrôleur officiel), obtenue grâce à l'abandon de Lua.
La version gratuite est considérablement limitée, même par rapport au contrôleur officiel (en raison de l'absence des modules Lua). La version payante dispose d'une fonctionnalité additionnelle assez large : métriques en temps réel, validation JWT, vérifications de santé actives, et plus encore. Un avantage important par rapport à NGINX Ingress est le support complet du trafic TCP/UDP (même dans la version communautaire !). Inconvénient - fonctionnalités de distribution du trafic, ce qui, cependant, « a la priorité maximale pour les développeurs », mais nécessite du temps pour la mise en œuvre.
Kong Ingress
Site :
Licence : Apache 2.0
Produit développé par Kong Inc. en deux versions : commerciale et gratuite. Basé sur nginx, ses capacités sont étendues par un grand nombre de modules Lua.
Initialement destiné à traiter et router les requêtes API, c'est-à-dire en tant que passerelle API, il est devenu un contrôleur Ingress à part entière. Les principaux avantages : de nombreux modules additionnels (y compris ceux de développeurs tiers) qui sont faciles à installer et à configurer, offrant ainsi un large éventail de fonctionnalités supplémentaires. Cependant, les fonctions intégrées proposent déjà de nombreuses possibilités. La configuration se fait à l'aide des ressources CRD.
Une caractéristique importante du produit est que le fonctionnement dans un seul contour (au lieu d'une approche inter-namespace) est un sujet discuté : certains le considèrent comme un inconvénient (il faut créer des entités pour chaque contour), tandis que pour d'autres, c'est une fonctionnalité (un)deniveau d'isolation supérieur, car si un contrôleur est défaillant, le problème est limité à un seul contour).
Traefik
Site :
Licence : MIT
Un proxy initialement conçu pour la gestion de la répartition des requêtes dans les microservices et leur environnement dynamique. D'où de nombreuses fonctionnalités utiles : mise à jour de configuration sans redémarrage, support d'un grand nombre de méthodes d'équilibrage, interface web, transfert de métriques, support de différents protocoles, API REST, déploiements canary, et bien plus encore. Une caractéristique agréable est également la prise en charge des certificats Let's Encrypt dès l'installation. Le désavantage est que pour organiser une haute disponibilité (HA), le contrôleur nécessite l'installation et la connexion d'un stockage KV propre.
HAProxy
Site :
Licence : Apache 2.0
HAProxy est bien connu en tant que proxy et équilibreur de charge. Dans le cadre d'un cluster Kubernetes, il propose une mise à jour « douce » de la configuration (sans perte de trafic), la découverte de services basée sur DNS, et une configuration dynamique via API. La personnalisation complète des modèles de configuration via le remplacement du ConfigMap (CM) et les fonctionnalités de la bibliothèque Sprig peuvent être des atouts attrayants. Globalement, la solution met l'accent sur la haute vitesse de fonctionnement, son optimisation et son efficacité dans la consommation des ressources. L'avantage du contrôleur est le support d'un nombre record de méthodes d'équilibrage différentes.
Voyager
Site :
Licence : Apache 2.0
Un contrôleur basé sur HAProxy, positionné comme une solution polyvalente, offrant de larges possibilités avec un grand nombre de fournisseurs. Il propose la répartition de trafic au niveau L7 et L4, et la répartition de trafic TCP L4 peut être considérée comme l'une des fonctionnalités clés de la solution.
Contour
Site :
Licence : Apache 2.0
Cette solution ne repose pas seulement sur Envoy : elle a été développée en collaboration avec les auteurs de ce proxy populaire. Une caractéristique importante est la possibilité de séparer la gestion des ressources Ingress à travers des ressources CRD IngressRoute. Pour les organisations avec de nombreuses équipes de développement utilisant un même cluster, cela aide à sécuriser au maximum le travail avec le trafic dans des contours voisins et à les protéger des erreurs lors des modifications des ressources Ingress.
Un ensemble complet de méthodes d'équilibrage est également proposé (avec la mise en miroir des requêtes, les répétitions automatiques, les limites de rate pour les requêtes, et bien plus), ainsi qu'une surveillance détaillée du trafic et des pannes. L'absence de support pour les sessions persistantes pourrait être un inconvénient majeur pour certains. ).
Istio Ingress
Site :
Licence : Apache 2.0
Une solution de service mesh complète, qui n'est pas seulement un contrôleur d'ingress gérant le trafic entrant, mais contrôle également tout le trafic au sein du cluster. « Sous le capot », Envoy est utilisé comme proxy sidecar pour chaque service. Essentiellement, c'est un grand outil polyvalent qui « peut tout faire », et son idée principale est une gestion maximale, une évolutivité, une sécurité et une transparence accrues. Avec Istio, vous pouvez affiner la configuration de la routage du trafic, l'autorisation d'accès entre services, l'équilibrage, la surveillance, les déploiements canari, et bien plus encore. Pour en savoir plus sur Istio, consultez la série d'articles «».
Ambassador
Site :
Licence : Apache 2.0
Une autre solution basée sur Envoy. Elle dispose de versions gratuites et commerciales. Elle se positionne comme « entièrement native de Kubernetes », ce qui apporte des avantages correspondants (intégration étroite avec les méthodes et entités du cluster K8s).
Tableau comparatif
Ainsi, le point culminant de l'article est ce grand tableau :
Il est cliquable pour un examen plus détaillé, et est également disponible au format .
Faisons le point
L'objectif de cet article est de fournir une compréhension plus complète (mais pas exhaustive !) du choix à faire dans votre cas particulier. Comme souvent, chaque contrôleur a ses avantages et ses inconvénients...
L'Ingress classique de Kubernetes se distingue par sa disponibilité et sa fiabilité, avec des fonctionnalités assez riches — en général, il devrait « suffire largement ». Cependant, pour des exigences accrues en matière de stabilité, de fonctionnalités et de développement, il est conseillé de se tourner vers l'Ingress avec NGINX Plus et un abonnement payant. Kong dispose d'un ensemble très riche de plugins (et, par conséquent, des capacités qu'ils offrent), en particulier dans la version payante où il y en a même plus. Il offre de vastes possibilités en tant que passerelle API, avec une configuration dynamique basée sur des ressources CRD, ainsi que des services de base de Kubernetes.
Pour des exigences accrues en matière de répartition de charge et de méthodes d'autorisation, jetez un œil à Traefik et HAProxy. Ce sont des projets Open Source, éprouvés au fil des ans, très stables et en développement actif. Contour existe depuis quelques années, mais semble toujours trop jeune et ne dispose que de fonctionnalités de base, ajoutées par-dessus Envoy. En cas d'exigences concernant la présence/intégration d'un WAF devant l'application, il convient de se tourner vers l'Ingress de Kubernetes ou HAProxy.
Les produits les plus riches en fonctionnalités sont ceux basés sur Envoy, en particulier Istio. Il représente une solution complète capable de « tout faire », ce qui signifie cependant un seuil d'entrée considérablement plus élevé en matière de configuration/lancement/administration que d'autres solutions.
Nous avons choisi comme contrôleur standard l'Ingress de Kubernetes, qui couvre 80 à 90 % des besoins. Il est tout à fait fiable, facilement configurable et extensible. En général, en l'absence de besoins spécifiques, il devrait convenir à la plupart des clusters/applications. Parmi d'autres produits similaires universels et relativement simples, on peut recommander Traefik et HAProxy.
P.S.
Lisez aussi dans notre blog :
- « Retour aux microservices avec Istio » : , , ;
- «»;
- «».
Source : habr.com
