Lorsque vous démarrez un cluster Kubernetes pour une application spécifique, vous devez comprendre les exigences que l'application elle-même, l'entreprise et les développeurs imposent à cette ressource. Si vous disposez de ces informations, vous pouvez commencer à prendre une décision architecturale et, en particulier, à sélectionner 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 à étudier de nombreux articles / documentation, etc., nous avons préparé cette revue en y incluant 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, ce sera le point de départ d'informations plus détaillées et d'expériences pratiques. Auparavant, nous avons étudié d'autres documents similaires sur le réseau et, curieusement, nous n'avons trouvé aucune revue plus ou moins complète et, surtout, structurée. Alors, comblez cette lacune!
Critères
Afin de faire une comparaison de principe et d'obtenir un résultat utile, vous devez comprendre non seulement le domaine, mais également avoir une liste spécifique de critères qui détermineront 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 - préparez-vous à devoir étudier toutes vos spécificités et détails dans tous les cas séparément.
Mais je vais commencer par les caractéristiques qui sont devenues si familières qu'elles sont mises en œuvre dans toutes les décisions et ne sont pas prises en compte:
- découverte dynamique de services (découverte de services);
- Terminaison SSL;
- travailler avec des websockets.
Maintenant sur les points de comparaison:
Protocoles pris en charge
L'un des critères fondamentaux de sélection. 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 en compte ce facteur afin de ne pas avoir à reconfigurer le cluster ultérieurement. Pour tous les contrôleurs, la liste des protocoles pris en charge varie.
Basé sur logiciel
Il existe plusieurs options d'application 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 affecter 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 est «sous le capot».
Acheminement du trafic
Sur la base de quoi pouvons-nous décider de la direction du trafic vers un service particulier? Il s'agit généralement de l'hôte et du chemin, mais il existe des fonctionnalités supplémentaires.
Espace de noms de cluster
Espace de noms (espace de noms) - la capacité de diviser logiquement les ressources dans Kubernetes (par exemple, sur scène, production, etc.). Il existe des contrôleurs Ingress qui doivent être définis séparément dans chaque espace de noms (et il ne peut
alors diriger
que le trafic vers les pods de cet espace). Et il y en a (et leur écrasante majorité) qui fonctionnent globalement sur 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 l'amont
Comment le trafic est-il dirigé vers des instances saines de l'application, des services? Il existe des options avec des contrôles actifs et passifs, des tentatives, des disjoncteurs
(pour plus de détails, voyez-les, par exemple, dans l' article sur Istio ) , des implémentations de contrôle de santé personnalisées, etc. Un paramètre très important si vous avez des exigences élevées en matière d'accessibilité et de retrait en temps opportun des services défaillants de la balance.
Algorithmes d'équilibrage
Il existe de nombreuses options: des
tourniquets traditionnels aux
tournois exotiques comme les
cookies rdp , ainsi que certaines fonctionnalités comme
les sessions persistantes .
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. C'est un critère important si vous utilisez un grand nombre de circuits pour les développeurs (et / ou simplement fermés) accessibles via Ingress.
Répartition du trafic
Le contrôleur prend-il en charge les mécanismes couramment utilisés pour la distribution du trafic tels que les déploiements canaries, les tests A / B, la mise en miroir du trafic (mise en miroir / observation)? 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 erreurs de produit hors combat (ou avec des pertes minimales), l'analyse du trafic, etc.
Abonnement payant
Existe-t-il une option payante pour le contrôleur, avec des fonctionnalités avancées et / ou un support technique?
Interface utilisateur graphique (Web UI)
Existe-t-il une interface graphique pour contrôler la configuration du contrôleur? Fondamentalement, pour la «maniabilité» et / ou pour ceux qui ont besoin d'apporter des modifications à la configuration d'Ingress, mais travailler avec des modèles «bruts» n'est pas pratique. Cela peut être utile si les développeurs souhaitent réaliser des expériences avec le trafic à la volée.
Validation JWT
La présence d'une vérification JSON intégrée des jetons Web pour l'autorisation et la validation par l'utilisateur de l'application finale.
Fonctionnalités de personnalisation de la configuration
Extensibilité des modèles dans le sens d'avoir des mécanismes pour ajouter leurs 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 plus sophistiquées pour filtrer le trafic en fonction des adresses, des listes blanches, des pays, etc.
Demande de trace
Possibilités d'observation, de suivi et de débogage des demandes d'Ingresss vers des services / pods spécifiques, et idéalement, entre services / pods également.
WAF
Prise en charge du
pare-feu d'application .
Contrôleurs d'entrée
La liste des contrôleurs était basée sur la
documentation officielle de Kubernetes et
ce tableau . 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). Les autres sont discutés ci-dessous. Nous commençons par une description générale des solutions et continuons avec le tableau croisé dynamique.
Ingress par Kubernetes
Site Web: github.com/kubernetes/ingress-nginxLicence: Apache 2.0Il s'agit du contrôleur officiel de Kubernetes, qui est développé par la communauté. Évidemment, d'après le 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 de ses modifications minimes lorsqu'il est utilisé comme contrôleur, cette option peut être l'ingénieur moyen de configuration le plus simple et le plus compréhensible (avec une expérience dans le Web).
Entrée par NGINX Inc
Site Web: github.com/nginxinc/kubernetes-ingressLicence: Apache 2.0Le produit officiel des développeurs nginx. Il a une version payante basée sur
NGINX Plus . L'idée principale est un haut niveau de stabilité, une compatibilité ascendante constante, l'absence de modules étrangers et l'augmentation de vitesse déclarée (par rapport au contrôleur officiel) obtenue en raison du rejet de Lua.
La version gratuite a été considérablement réduite, y compris même par rapport au contrôleur officiel (en raison de l'absence des mêmes modules Lua). Payé en même temps a une fonctionnalité supplémentaire assez large: métriques en temps réel, validation JWT, contrôles d'intégrité actifs, etc. Un avantage important par rapport à NGINX Ingress est la prise en charge complète du trafic TCP / UDP (et également dans la version communautaire!). L'inconvénient est le
manque de fonctionnalités pour la distribution du trafic, qui, cependant, «a la plus haute priorité pour les développeurs», mais il faut du temps pour le mettre en œuvre.
Kong Ingress
Site Web: github.com/Kong/kubernetes-ingress-controllerLicence: Apache 2.0Produit développé par Kong Inc. en deux versions: commerciale et gratuite. Il est basé sur nginx, dont les capacités sont étendues par un grand nombre de modules sur Lua.
Initialement, il était axé sur le traitement et le routage des demandes d'API, c'est-à-dire comme la 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 de développeurs tiers) faciles à installer et à configurer et avec lesquels une large gamme de fonctionnalités supplémentaires est implémentée. Cependant, les fonctionnalités intégrées offrent déjà de nombreuses fonctionnalités. La configuration du travail est effectuée à l'aide des ressources CRD.
Une caractéristique importante du produit - travailler dans le même circuit (au lieu d'un espace croisé) est un sujet controversé: pour certains, cela semblera un inconvénient (vous devez produire des entités pour chaque circuit), et pour quelqu'un, c'est une fonctionnalité (
un niveau d'isolement plus élevé, car si un contrôleur est cassé, le problème est limité à un seul circuit).
Traefik
Site Web: github.com/containous/traefikLicence: MITUn proxy créé à l'origine pour fonctionner avec le routage des demandes de microservices et leur environnement dynamique. Par conséquent, de nombreuses fonctionnalités utiles: mise à jour complète de la configuration sans redémarrage, prise en charge d'un grand nombre de méthodes d'équilibrage, interface Web, mesures de transfert, prise en charge de divers protocoles, API REST, versions canaries et bien plus encore. Une fonctionnalité intéressante est également la prise en charge des certificats Let's Encrypt prêts à l'emploi. L'inconvénient est que pour l'organisation de la haute disponibilité (HA), le contrôleur devra installer et connecter son propre stockage KV.
HAProxy
Site Web: github.com/jcmoraisjr/haproxy-ingressLicence: Apache 2.0HAProxy est connu depuis longtemps comme proxy et équilibreur de trafic. Dans le cadre du cluster Kubernetes, il propose une mise à jour de configuration «soft» (sans perte de trafic), une découverte de service basée sur DNS, une configuration dynamique à l'aide de l'API. La personnalisation complète du modèle de configuration en remplaçant le CM'a, ainsi que la possibilité d'utiliser les fonctions de la bibliothèque Sprig, peuvent devenir intéressantes. En général, l'objectif principal de la solution est la haute vitesse, son optimisme 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.
Voyager
Site Web: github.com/appscode/voyagerLicence: Apache 2.0Contrôleur basé sur HAproxy, qui se positionne comme une solution universelle qui prend en charge de larges capacités sur un grand nombre de fournisseurs. L'opportunité est proposée pour équilibrer le trafic sur L7 et L4, et l'équilibrage du trafic TCP L4 dans son ensemble peut être appelé l'une des principales caractéristiques de la solution.
Contour
Site Web: github.com/heptio/contourLicence: Apache 2.0Envoy n'a pas seulement jeté les bases de cette solution: elle a été développée
conjointement avec les auteurs de ce proxy populaire. Une caractéristique importante est la possibilité de fractionner la gestion des ressources Ingress à l'aide des ressources CRD IngressRoute. Pour les organisations avec de nombreuses équipes de développement utilisant un seul cluster, cela permet de maximiser la sécurité du trafic dans les circuits voisins et de les protéger contre les erreurs lors du changement des ressources Ingress.
Il propose également un ensemble étendu de méthodes d'équilibrage (il existe une mise en miroir des demandes, des tentatives automatiques, une restriction du taux de demandes, etc.), une surveillance détaillée du flux de trafic et des défaillances. Pour certains, ce sera peut-être un inconvénient majeur du manque de support pour les sessions persistantes (bien que le travail soit
déjà en cours ).
Entrée Isstio
Site Web: istio.io/docs/tasks/traffic-management/ingressLicence: Apache 2.0Une solution complète de maillage de service, qui est non seulement un contrôleur Ingress qui contrôle 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 canaries et bien plus encore. En savoir plus sur Istio dans la série d'articles
Retour aux microservices avec Istio .
Ambassadeur
Site Web: github.com/datawire/ambassadorLicence: Apache 2.0Une autre solution basée sur Envoy. A une version gratuite et commerciale. Il se positionne comme «totalement natif de Kubernetes», ce qui apporte des 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 cette immense table:
Il est cliquable pour un affichage plus détaillé et est également disponible au format
Google Sheets .
Pour résumer
Le but de l'article est de fournir une compréhension plus complète (cependant, absolument pas exhaustive!) De quel choix faire dans votre cas particulier. Comme d'habitude, chaque contrôleur a ses propres avantages et inconvénients ...
Le classique Kubernetes Ingress est bon pour son accessibilité et sa providence, assez riche en capacités - en général, il devrait être "assez pour les yeux". Cependant, s'il existe des exigences accrues en matière de stabilité, de niveau de fonctionnalités et de développement, il convient de prêter attention à Ingress avec NGINX Plus et à un abonnement payant. Kong a un riche ensemble de plugins (et, par conséquent, les capacités fournies par eux), et dans la version payante, il y en a encore plus. Il a de nombreuses opportunités de fonctionner comme une passerelle API, de configurer dynamiquement en fonction des ressources CRD, ainsi que des services Kubernetes de base.
Avec des exigences accrues pour les méthodes d'équilibrage et 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 il semble encore trop jeune et n'a que des fonctionnalités de base ajoutées à Envoy. S'il y a des exigences pour la présence / l'intégration de WAF avant l'application, vous devez faire attention au même Ingress de Kubernetes ou HAProxy.
Et les plus riches en fonctionnalités sont des produits construits sur la base d'Envoy, en particulier Istio. Il semble que ce soit une solution complexe qui «puisse tout faire», ce qui signifie cependant également un seuil nettement plus élevé pour entrer dans la configuration / lancement / administration que les autres solutions.
Nous avons choisi et utilisons toujours Kubernetes Ingress, qui couvre 80 à 90% des besoins, comme contrôleur standard. Il est assez fiable, facile à configurer, à étendre. Dans le cas général, en l'absence d'exigences spécifiques, il convient à la plupart des clusters / applications. Parmi les mêmes produits polyvalents et relativement simples, Traefik et HAProxy peuvent être recommandés.
PS
Lisez aussi dans notre blog: