Lors du lancement d'un cluster Kubernetes pour une application spécifique, vous devez comprendre ce que l'application elle-même, l'entreprise et les développeurs représentent pour cette ressource. Avec ces informations, vous pouvez commencer à prendre une décision architecturale et, en particulier, choisir un contrôleur Ingress spécifique, dont il existe déjà un grand nombre aujourd'hui. Afin d'avoir une idée de base des options disponibles sans avoir à parcourir de nombreux articles / documentations, etc., nous avons préparé cet aperçu, y compris les principaux contrôleurs Ingress (prêts pour la production).
Nous espérons que cela aidera les collègues à choisir une solution architecturale - au moins, cela deviendra un point de départ pour obtenir des informations plus détaillées et des expériences pratiques. Auparavant, nous avons étudié d'autres documents similaires sur le net et, curieusement, nous n'avons pas trouvé un seul examen plus ou moins complet et, surtout, structuré. Alors comblons cette lacune !
critères
En principe, pour faire une comparaison et obtenir un résultat utile, vous devez non seulement comprendre le domaine, mais également disposer d'une liste spécifique de critères qui définiront le vecteur de recherche. Sans prétendre analyser tous les cas possibles d'utilisation d'Ingress / Kubernetes, nous avons essayé de mettre en évidence les exigences les plus générales pour les contrôleurs - soyez prêt que dans tous les cas, vous devrez étudier toutes vos spécificités et particularités séparément.
Mais je vais commencer par les caractéristiques qui sont devenues si familières qu'elles sont implémentées dans toutes les solutions et ne sont pas prises en compte :
- découverte dynamique de services (service discovery) ;
- résiliation SSL ;
- travailler avec des websockets.
Passons maintenant aux points de comparaison :
Protocoles pris en charge
Un des critères de sélection fondamentaux. Votre logiciel peut ne pas fonctionner sur HTTP standard, ou il peut nécessiter de travailler sur plusieurs protocoles à la fois. Si votre cas n'est pas standard, assurez-vous de prendre ce facteur en compte afin de ne pas avoir à reconfigurer le cluster ultérieurement. Pour tous les contrôleurs, la liste des protocoles pris en charge varie.
le logiciel au coeur
Il existe plusieurs variantes d'applications sur lesquelles le contrôleur est basé. Les plus populaires sont nginx, traefik, haproxy, envoyé. Dans le cas général, cela peut ne pas avoir beaucoup d'effet sur 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 potentielles de ce qui se trouve « sous le capot ».
Routage du trafic
Sur la base de quoi est-il possible de prendre une décision concernant la direction du trafic vers un service particulier ? Il s'agit généralement de l'hôte et du chemin, mais il existe d'autres possibilités.
Espace de noms dans un cluster
Espace de noms (espace de noms) - la possibilité de diviser logiquement les ressources dans Kubernetes (par exemple, sur scène, en production, etc.). Il existe des contrôleurs d'entrée qui doivent être installés séparément dans chaque espace de noms (et ils peuvent ensuite diriger le trafic seulement aux gousses de cet espace). Et il y a ceux (et leur nette majorité) qui fonctionnent globalement pour l'ensemble du cluster - en eux, le trafic est dirigé vers n'importe quel pod du cluster, quel que soit l'espace de noms.
Échantillons pour les amonts
Comment le trafic est-il dirigé vers des instances saines de l'application, des services ? Il existe des options avec des vérifications actives et passives, des tentatives, des disjoncteurs (Pour plus de détails, voir, par exemple, ), propres implémentations de bilans de santé (contrôles de santé personnalisés), etc. Un paramètre très important si vous avez des exigences élevées en matière de disponibilité et de suppression rapide des services défaillants de l'équilibrage.
Algorithmes d'équilibrage
Il existe de nombreuses options : du traditionnel à l'exotisme , ainsi que des fonctionnalités individuelles telles que .
Authentification
Quels schémas d'autorisation le contrôleur prend-il en charge ? Basic, digest, oauth, external-auth - je pense que ces options devraient être familières. Il s'agit d'un critère important s'il existe de nombreuses boucles de développement (et/ou simplement privées) auxquelles on accède via Ingress.
Répartition du trafic
Le contrôleur prend-il en charge des mécanismes de distribution de trafic couramment utilisés tels que les déploiements canaris (canary), les tests A / B, la mise en miroir du trafic (mirroring / shadowing) ? C'est un sujet vraiment délicat pour les applications qui nécessitent une gestion précise et précise du trafic pour des tests productifs, le débogage des bogues du produit hors ligne (ou avec une perte minimale), l'analyse du trafic, etc.
Abonnement payant
Existe-t-il une option payante pour la manette, avec des fonctionnalités avancées et/ou un support technique ?
Interface utilisateur graphique (Web UI)
Existe-t-il une interface graphique pour gérer la configuration du contrôleur ? Principalement pour la "maniabilité" et/ou pour ceux qui ont besoin d'apporter quelques modifications à la configuration d'Ingress'a, mais travailler avec des modèles "bruts" n'est pas pratique. Cela peut être utile si les développeurs souhaitent effectuer des expériences avec le trafic à la volée.
Validation JWT
La présence d'une validation intégrée des jetons Web JSON pour l'autorisation et la validation de l'utilisateur à l'application finale.
Possibilités de personnalisation de la configuration
Extensibilité des modèles dans le sens d'avoir des mécanismes qui vous permettent d'ajouter vos propres directives, drapeaux, etc. aux modèles de configuration standard.
Mécanismes de protection DDOS de base
Algorithmes de limite de débit simples ou options de filtrage de trafic plus complexes basées sur des adresses, des listes blanches, des pays, etc.
Demander un suivi
La possibilité de surveiller, de suivre et de déboguer les requêtes des entrées vers des services/pods spécifiques, et idéalement entre les services/pods également.
WAF
support .
Contrôleurs
La liste des contrôleurs a été constituée sur la base и . Nous avons exclu certains d'entre eux de la revue en raison de leur spécificité ou de leur faible prévalence (stade précoce de développement). Le reste est discuté ci-dessous. Commençons par une description générale des solutions et poursuivons par un tableau récapitulatif.
Entrée depuis Kubernetes
Site Web:
Licence : Apache 2.0
Il s'agit du contrôleur officiel de Kubernetes et il est développé par la communauté. De toute évidence, d'après son nom, il est basé sur nginx et est complété par un ensemble différent de plugins Lua utilisés pour implémenter des fonctionnalités supplémentaires. En raison de la popularité de nginx lui-même et des modifications minimes qu'il apporte lorsqu'il est utilisé comme contrôleur, cette option peut être la plus simple et la plus facile à configurer pour l'ingénieur moyen (avec une expérience Web).
Entrée par NGINX Inc.
Site Web:
Licence : Apache 2.0
Le produit officiel des développeurs nginx. A une version payante basée sur . L'idée principale est un haut niveau de stabilité, une rétrocompatibilité constante, l'absence de tout module superflu et la vitesse accrue déclarée (par rapport au contrôleur officiel), obtenue grâce au rejet de Lua.
La version gratuite est considérablement réduite, y compris même par rapport au contrôleur officiel (en raison de l'absence des mêmes modules Lua). Dans le même temps, le payant dispose d'une fonctionnalité supplémentaire assez large : métriques en temps réel, validation JWT, bilans de santé actifs, et plus encore. Un avantage important par rapport à NGINX Ingress est la prise en charge complète du trafic TCP/UDP (et dans la version communautaire aussi !). Moins - fonctionnalité de distribution du trafic, qui, cependant, "a la plus haute priorité pour les développeurs", mais prend du temps à mettre en œuvre.
Entrée de Kong
Site Web:
Licence : Apache 2.0
Produit développé par Kong Inc. en deux versions : commerciale et gratuite. Basé sur nginx, qui a été étendu avec un grand nombre de modules Lua.
Initialement, il était axé sur le traitement et le routage des requêtes API, c'est-à-dire en tant que passerelle API, mais pour le moment, il est devenu un contrôleur Ingress à part entière. Principaux avantages: de nombreux modules supplémentaires (y compris ceux de développeurs tiers) faciles à installer et à configurer et à l'aide desquels un large éventail de fonctionnalités supplémentaires est implémenté. Cependant, les fonctions intégrées offrent déjà de nombreuses possibilités. La configuration des tâches est effectuée à l'aide des ressources CRD.
Une caractéristique importante du produit - travailler dans le même contour (au lieu d'espaces de noms croisés) est un sujet controversé : pour certains, cela semblera être un inconvénient (vous devez produire des entités pour chaque contour), et pour quelqu'un, c'est une fonctionnalité ( bоUn niveau d'isolement plus élevé, comme si un contrôleur est cassé, alors le problème est limité au circuit seul).
Traefik
Site Web:
Licence : MIT
Un proxy créé à l'origine pour fonctionner avec le routage des demandes pour les microservices et leur environnement dynamique. D'où de nombreuses fonctionnalités utiles : mise à jour de la configuration sans redémarrage du tout, prise en charge d'un grand nombre de méthodes d'équilibrage, interface Web, transfert de métriques, prise en charge de divers protocoles, API REST, versions canary, et bien plus encore. Une autre fonctionnalité intéressante est la prise en charge des certificats Let's Encrypt prêts à l'emploi. L'inconvénient est que pour organiser la haute disponibilité (HA), le contrôleur devra installer et connecter son propre stockage KV.
HAProxy
Site Web:
Licence : Apache 2.0
HAProxy est connu depuis longtemps comme un proxy et un équilibreur de trafic. Dans le cadre d'un cluster Kubernetes, il propose une mise à jour de configuration "soft" (sans perte de trafic), une découverte de service basée sur le DNS, une configuration dynamique à l'aide d'API. Il peut être intéressant de personnaliser complètement le modèle de configuration en remplaçant le CM, ainsi que la possibilité d'y utiliser les fonctions de la bibliothèque Sprig. En général, l'accent principal de la solution est mis sur la haute vitesse, son optimisation et son efficacité dans les ressources consommées. L'avantage du contrôleur est la prise en charge d'un nombre record de méthodes d'équilibrage différentes.
voyageur
Site Web:
Licence : Apache 2.0
Basé sur le contrôleur HAproxy, qui se positionne comme une solution universelle prenant en charge un large éventail de fonctionnalités sur un grand nombre de fournisseurs. Une opportunité est offerte pour équilibrer le trafic sur L7 et L4, et l'équilibrage du trafic TCP L4 dans son ensemble peut être appelé l'une des caractéristiques clés de la solution.
Contour
Site Web:
Licence : Apache 2.0
Cette solution n'est pas uniquement basée sur Envoy : elle a été développée par conjointement avec les auteurs de cette procuration populaire. Une fonctionnalité importante est la possibilité de séparer le contrôle des ressources Ingress à l'aide des ressources IngressRoute CRD. Pour les organisations ayant de nombreuses équipes de développement utilisant le même cluster, cela permet de maximiser la sécurité du travail avec le trafic dans les boucles voisines et de les protéger contre les erreurs lors de la modification des ressources Ingress.
Il offre également un ensemble étendu de méthodes d'équilibrage (il y a la mise en miroir des demandes, la répétition automatique, la limitation du débit des demandes, et bien plus encore), une surveillance détaillée du flux de trafic et des échecs. Peut-être que pour quelqu'un ce sera un inconvénient important le manque de support pour les sessions collantes (bien que le travail ).
Entrée Istio
Site Web:
Licence : Apache 2.0
Une solution complète de maillage de services qui n'est pas seulement un contrôleur d'entrée qui gère le trafic entrant de l'extérieur, mais contrôle également tout le trafic au sein du cluster. Sous le capot, Envoy est utilisé comme proxy side-car pour chaque service. En substance, il s'agit d'une grande moissonneuse-batteuse qui "peut tout faire", et son idée principale est une gérabilité, une extensibilité, une sécurité et une transparence maximales. Avec lui, vous pouvez affiner le routage du trafic, l'autorisation d'accès entre les services, l'équilibrage, la surveillance, les versions Canary, et bien plus encore. En savoir plus sur Istio dans la série d'articles "».
Ambassadeur
Site Web:
Licence : Apache 2.0
Une autre solution basée sur Envoy. Il a des versions gratuites et commerciales. Il se positionne comme "entièrement natif de Kubernetes", ce qui apporte les avantages correspondants (intégration étroite avec les méthodes et entités du cluster K8s).
tableau de comparaison
Ainsi, le point culminant de l'article est cet immense tableau :
Il est cliquable pour une vue plus rapprochée, et est également disponible au format .
Récapituler
Le but de cet article est de fournir une compréhension plus complète (mais en aucun cas exhaustive !) du choix à faire dans votre cas particulier. Comme d'habitude, chaque contrôleur a ses avantages et ses inconvénients...
L'Ingress classique de Kubernetes est bon pour sa disponibilité et son efficacité, suffisamment riche en fonctionnalités - dans le cas général, il devrait être "assez pour les yeux". Cependant, s'il y a des exigences accrues en matière de stabilité, de niveau de fonctionnalités et de développement, vous devez faire attention à Ingress avec NGINX Plus et un abonnement payant. Kong possède l'ensemble de plug-ins le plus riche (et, par conséquent, les opportunités qu'ils offrent), et dans la version payante, il y en a encore plus. Il a de nombreuses possibilités de fonctionner comme une passerelle API, une configuration dynamique basée sur les ressources CRD, ainsi que des services Kubernetes de base.
Avec des exigences accrues en matière de méthodes d'équilibrage et d'autorisation, jetez un œil à Traefik et HAProxy. Ce sont des projets Open Source, éprouvés au fil des années, très stables et en plein développement. Contour est sorti depuis quelques années maintenant, mais il semble encore trop jeune et n'a que des fonctionnalités de base ajoutées en plus d'Envoy. S'il existe des exigences pour la présence / l'intégration de WAF devant l'application, vous devez faire attention au même Ingress de Kubernetes ou HAProxy.
Et les plus riches en termes de fonctionnalités sont les produits construits sur Envoy, en particulier Istio. Cela semble être une solution complète qui "peut tout faire", ce qui signifie cependant également un seuil d'entrée pour la configuration / le lancement / l'administration nettement plus élevé que les autres solutions.
Nous avons choisi et utilisons toujours Ingress de Kubernetes comme contrôleur standard, qui couvre 80 à 90 % des besoins. Il est assez fiable, facile à configurer et à étendre. En général, en l'absence d'exigences spécifiques, il convient à la plupart des clusters / applications. Parmi les mêmes produits universels et relativement simples, Traefik et HAProxy peuvent être recommandés.
PS
A lire aussi sur notre blog :
- "Retour aux microservices avec Istio" : , , ;
- «";
- «».
Source: habr.com