Consul est excellent lorsqu'il fonctionne, mais soyons réalistes : l'utiliser en production signifie généralement que c'est vous qui gardez les clusters etcd, qui déboguez les erreurs de potins à 2 heures du matin et qui écrivez un énième module Terraform juste pour ajouter un nouvel environnement.
La plupart des équipes d'aujourd'hui ne veulent pas d'un autre système distribué pour fonctionner. Elles veulent une découverte de services, un maillage et une configuration qui fonctionnent, sans avoir besoin d'un doctorat en systèmes distribués ou d'une équipe dédiée à la plateforme. Bonne nouvelle : le paysage a complètement changé au cours des deux dernières années. Un certain nombre d'entreprises ont finalement construit ce que tout le monde voulait : des remplacements directs (ou des approches carrément meilleures) qui gèrent les parties difficiles pour vous.
Vous trouverez ci-dessous les alternatives que les équipes en pleine évolution adoptent en ce moment même. Pas de projets académiques, pas d'ambiance de “bricolage” - juste des choses qui vous permettent de revenir à la création de produits.
1. AppFirst
AppFirst adopte un angle différent en supprimant entièrement la majeure partie du code d'infrastructure. Les développeurs décrivent ce dont leur application a besoin - CPU, mémoire, type de base de données, règles de mise en réseau - et la plateforme fournit les ressources cloud réelles sur AWS, Azure ou GCP sans avoir à remettre des fichiers Terraform ou YAML. Elle génère automatiquement des VPC sécurisés, des sous-réseaux, des groupes de sécurité et des crochets d'observabilité.
L'objectif est de permettre aux ingénieurs de gérer eux-mêmes les déploiements de bout en bout, tout en restant conformes et en réduisant les coûts. Les options comprennent l'hébergement SaaS du plan de contrôle ou des installations auto-hébergées, et elles fonctionnent de la même manière quel que soit le fournisseur de cloud sous-jacent.
Faits marquants
- Approvisionnement déclaratif centré sur les applications
- Réseau sécurisé généré automatiquement
- Journalisation et alerte intégrées
- Ventilation des coûts par application et environnement
- Plan de contrôle SaaS ou auto-hébergé
Pour
- Pas de maintenance de Terraform
- Une configuration cohérente dans tous les nuages
- Environnements instantanés pour les branches de fonctionnalités
- Observabilité incluse par défaut
Cons
- Verrouillage dans leur couche d'abstraction
- Moins de visibilité sur les ressources brutes du nuage
- Il est encore tôt par rapport aux outils matures de l'IaC
- Dépendance à l'égard du fournisseur pour les changements
Informations sur le contact
- Site web : www.appfirst.dev
2. etcd
etcd est un magasin distribué de clés et de valeurs conçu pour conserver les données critiques dans les environnements en grappe. Les ingénieurs l'utilisent lorsqu'ils ont besoin de quelque chose de fortement cohérent qui peut survivre à des divisions de réseau et à des pannes de machine sans perdre de données. Il utilise l'algorithme de consensus Raft sous le capot et expose une API HTTP simple, de sorte que les gens interagissent avec lui en utilisant des outils comme curl.
Le projet reste volontairement assez minimal : clés hiérarchiques, surveillance des modifications, TTL optionnels et support SSL couvrent la plupart des cas d'utilisation. Beaucoup de grands systèmes s'appuient encore sur lui comme magasin d'appui pour les tâches de coordination.
Faits marquants
- API HTTP simple et conviviale (curl)
- Structure hiérarchique de type répertoire pour les clés
- Watch API réagit aux changements de valeur
- Consensus sur les radeaux pour la distribution
- TTLs optionnels sur les touches
- Prise en charge des certificats clients SSL
Pour
- Un modèle de cohérence solide comme le roc
- Empreinte très légère
- Testé en production depuis des années
- Facile à intégrer dans d'autres systèmes
Cons
- Pas de fonctions intégrées de découverte de services ou de maillage
- Nécessite une gestion manuelle de la grappe
- Options de contrôle d'accès limitées
- Les performances chutent fortement si la grappe devient malsaine
Informations sur le contact
- Site web : etcd.io
- Twitter : x.com/etcdio
3. Apache ZooKeeper
Apache ZooKeeper a commencé comme un service de coordination qui gère les parties désordonnées des applications distribuées - la configuration, le nommage, l'élection d'un leader, les verrous et l'appartenance à un groupe. Il est déployé sous la forme d'une petite grappe de serveurs qui conservent les données en mémoire et les écrivent sur disque pour en assurer la pérennité. Les clients se connectent et utilisent les bibliothèques Java ou C pour obtenir ce dont ils ont besoin.
La plupart des configurations le traitent comme un utilitaire central plutôt que comme quelque chose que les développeurs touchent tous les jours. Une fois qu'il fonctionne, les applications se contentent de lire et de surveiller les znodes pour détecter les changements. Le projet existe depuis toujours et reçoit toujours des mises à jour régulières de la part de la communauté Apache.
Faits marquants
- Arbre de données en mémoire avec écritures persistantes
- De solides garanties de cohérence
- Mécanisme de surveillance pour les notifications de changement
- Prise en charge intégrée des verrous et de l'élection du chef de file
- Bibliothèques client Java et C
Pour
- Extrêmement stable après des années d'utilisation en production
- Modèle de données simple sur lequel il est facile de raisonner
- Bonne documentation et bons exemples
- Convient bien aux charges de coordination petites à moyennes
Cons
- Les opérations se compliquent avec la croissance des clusters
- Pas de prise en charge native de plusieurs centres de données
- Mémoire lourde pour les grands ensembles de données
- Les connexions des clients peuvent surcharger les petites grappes
Informations sur le contact
- Site web : zookeeper.apache.org
4. Istio
Istio fonctionne comme une couche de maillage de services qui gère le routage du trafic, la surveillance et la protection dans les configurations avec des microservices ou des applications distribuées. Les ingénieurs le déploient aux côtés de Kubernetes pour insérer des proxys qui gèrent la communication entre les services, en s'appuyant sur des détails comme Envoy pour un contrôle plus approfondi au niveau de l'application. Le système s'étend sur des clusters ou même des nuages différents en reliant les charges de travail par des politiques cohérentes, et il tire parti d'un écosystème ouvert où les gens contribuent à des extensions ou les regroupent dans des paquets plus faciles.
Les opérateurs ont le choix entre gérer l'ensemble eux-mêmes, utiliser des installations rapides sur Kubernetes, ou le confier à des services gérés par des fournisseurs. Cette flexibilité est due à sa conception en tant que projet diplômé de la CNCF, lancé en 2016 par quelques grands acteurs, qui le maintient lié au monde cloud-native plus large, comme Kubernetes lui-même. En pratique, il se superpose sans forcer les applications à modifier leur code.
Faits marquants
- Gestion du trafic basée sur un proxy avec prise en charge d'Envoy
- mTLS pour l'authentification et le cryptage des services
- Télémétrie intégrée pour le suivi des performances
- Mise en œuvre de politiques dans le cadre d'installations multi-clusters
- Tunnel de confiance zéro au niveau 4
- Extensible grâce à l'intégration de la communauté
Pour
- S'adapte naturellement aux environnements Kubernetes
- Couvre la sécurité et l'observabilité dès le départ
- Gérer l'hybride ou le multi-cloud sans trop de remaniement
- Un écosystème ouvert pour des ajustements personnalisés
Cons
- L'installation implique de relier plusieurs composants entre eux
- L'utilisation des ressources s'intensifie avec les fonctionnalités de la couche 7
- Le débogage des proxies peut s'avérer délicat dans les grandes mailles
- S'appuie sur de solides connaissances en matière de Kubernetes.
Informations sur le contact
- Site web : istio.io
- LinkedIn : www.linkedin.com/company/istio
- Twitter : x.com/IstioMesh
5. Linkerd
Linkerd s'insère dans Kubernetes comme un maillage de services légers, injectant de minuscules proxies pour envelopper les appels de service avec le chiffrement et la collecte de métriques. L'ensemble fonctionne en code Rust, ce qui lui permet de rester sécurisé et rapide sans les écueils habituels tels que les fuites de mémoire. Les utilisateurs l'ajoutent de manière incrémentale, en commençant par le plan de contrôle et en déployant des éléments du plan de données en fonction des besoins, et il s'accroche aux ressources du cluster par le biais d'objets personnalisés sans se noyer dans des fichiers de configuration.
Une fois activé, il applique automatiquement TLS mutuel pour le trafic interne et recueille des statistiques de latence ou d'erreur immédiatement, sans configuration supplémentaire. Cette approche lui confère un caractère natif dans Kubernetes, et en tant qu'effort open-source diplômé de la CNCF, il s'appuie sur une base de contributeurs solide tout en évitant le gonflement qui fait trébucher les mailles plus lourdes.
Faits marquants
- Proxies ultralégers construits en rouille pour un faible coût de fonctionnement
- Sécurité automatique mTLS et zéro-configuration
- Mesures instantanées des demandes et des temps de latence
- Équilibrage de la charge avec tentatives et délais d'attente
- Déploiement incrémental sur Kubernetes
- Outils de diagnostic pour un dépannage rapide
Pour
- Commence à petite échelle et s'adapte sans problème
- Sécurisé dès la conception grâce à Rust
- Visibilité claire et rapide
- Facile à superposer sur des clusters existants
Cons
- Kubernetes uniquement, pas de prise en charge des machines virtuelles
- Moins d'options de routage avancées que les concurrents
- Les outils communautaires sont à la traîne par rapport aux grands projets
- Les déploiements bleu-vert ont besoin de quelques ajustements YAML
Informations sur le contact
- Site web : linkerd.io
- LinkedIn : www.linkedin.com/company/linkerd
- Twitter : x.com/linkerd/
6. VMware NSX
VMware NSX virtualise la mise en réseau dans les clouds privés, en éloignant la pile du matériel physique pour la rendre programmable et automatisée. Dans les configurations distribuées, il ajoute une micro-segmentation pour isoler les charges de travail et un chiffrement pour verrouiller les flux, le tout géré à partir d'une console qui s'étend sur les sites ou les clouds. Les administrateurs l'utilisent dans VMware Cloud Foundation pour créer des clouds privés virtuels avec des quotas et des règles, ce qui accélère le provisionnement sans intervention constante.
L'outil est lié à Kubernetes pour le trafic des conteneurs, ajoutant l'observabilité et la mise en réseau native qui fonctionne bien avec vSphere. Le déploiement s'inscrit dans l'écosystème VCF, où les API et les schémas directeurs automatisent les politiques de sécurité dans les environnements hybrides, mais il ne s'agit pas d'un produit isolé.
Faits marquants
- Micro-segmentation pour l'isolation de la charge de travail
- Politique centralisée pour les installations multisites
- Mise en réseau de conteneurs Kubernetes natifs
- Chiffrement et contrôles fédérés
- Approvisionnement par API pour les VPC
- Observabilité intégrée du trafic
Pour
- Simplification de la sécurité dans les nuages virtualisés
- Automatisation des opérations multi-locataires
- Intégration étroite avec la pile VMware
- Bonne gestion des politiques de reprise après sinistre
Cons
- Enfermé dans des environnements VMware
- Courbe plus prononcée à l'extérieur du VCF
- Pas d'option autonome pour les tests rapides
- L'observabilité se concentre davantage sur les infrastructures que sur les applications
Informations sur le contact
- Site web : www.vmware.com
- LinkedIn : www.linkedin.com/company/vmware
- Facebook : www.facebook.com/vmware
- Twitter : x.com/vmware
7. F5
F5 Aspen Mesh s'appuie sur Istio pour gérer le trafic des microservices dans les réseaux de niveau fournisseur, en acheminant les paquets avec des politiques et en injectant de la visibilité au niveau du service. Il prend en charge le passage des anciennes fonctions virtuelles aux fonctions natives du cloud dans les configurations 5G, en utilisant l'IP à double pile pour la compatibilité et des outils tels que les gestionnaires de certificats pour gérer les identités à travers les clusters. Les opérateurs le déploient sur des nuages sur site, privés ou hybrides, en isolant les locataires ou en reliant plusieurs sites pour le basculement.
Un composant appelé Packet Inspector capture les détails du trafic par utilisateur ou par service, facilitant les contrôles de conformité ou les traces de facturation sans exposer la topologie complète. En tant qu'extension d'Istio, il hérite de la logique de base du maillage, mais ajoute des caractéristiques propres aux télécommunications, telles que des vues au niveau de l'abonné.
Faits marquants
- Contrôle du trafic et application de la loi basés sur Istio
- Prise en charge de la double pile IPv4/IPv6
- Visibilité par locataire et dissimulation de la topologie
- Gestion des certificats avec FQDN et SPIFFE
- Multi-cluster pour une haute disponibilité
- Capture de paquets pour le dépannage
Pour
- Facilite la migration des microservices de la 4G vers la 5G
- La traçabilité de la conformité est une priorité
- Isolation des locataires multi-cloud
- Configurations de sécurité robustes par défaut
Cons
- Destiné aux prestataires de services, moins général
- Dépend de la complexité d'Istio
- Les outils de visibilité ajoutent des couches supplémentaires à l'apprentissage
- Des caractéristiques de transition adaptées à des secteurs spécifiques
Informations sur le contact
- Site web : www.f5.com
- Téléphone : 1-888-882-7535
- Courriel : F5TechnologyAllianceProgram@f5.com
- Adresse : 801 5th Ave Seattle, WA 98104
- LinkedIn : www.linkedin.com/company/f5
- Facebook : www.facebook.com/f5incorporated
- Twitter : x.com/f5
- Instagram : www.instagram.com/f5.global
8. Tigera
Tigera se concentre sur la sécurité et l'observabilité du réseau adaptées aux clusters Kubernetes, en s'appuyant sur son rôle de mainteneur de Calico Open Source. La plateforme utilise eBPF pour un réseau haute performance, ainsi que des passerelles d'entrée et de sortie pour normaliser le flux de trafic. Les politiques permettent des contrôles fins tels que la limitation des connexions sortantes par IP, domaines ou CIDR, tout en prenant en charge la microsegmentation pour isoler les espaces de noms et les charges de travail. Dans les scénarios multi-clusters, Cluster Mesh gère la connectivité et la découverte sans tirer dans un maillage de service complet, et un tableau de bord central applique des règles uniformes à travers les différentes saveurs Kubernetes.
Les choix de déploiement vont du logiciel libre Calico pour la sécurité de base au modèle SaaS de Calico Cloud pour l'observabilité dans des clusters uniques, en passant par le modèle auto-hébergé Calico Enterprise pour une gestion plus large. Les outils d'observabilité cartographient les topologies de réseau, suivent les liens de charge de travail et obtiennent des mesures de trafic pour le débogage, avec des extras tels que des tableaux de bord d'événements et des intégrations SIEM pour gérer les incidents. Tout est conçu pour que les choses restent cohérentes dans les configurations à forte densité de conteneurs.
Faits marquants
- Mise en réseau basée sur l'eBPF pour la performance
- Passerelles d'entrée et de sortie pour le contrôle du trafic
- Politiques de réseau avec restrictions d'IP et de domaine
- Cluster Mesh pour la découverte de plusieurs clusters
- Vues de la topologie et mesures du trafic
- Application centralisée des politiques sur l'ensemble des distributions
Pour
- Forte intégration native de Kubernetes
- Un noyau ouvert pour des extensions personnalisées
- Gestion des grappes multiples sans couches supplémentaires
- Visibilité détaillée des flux du réseau
Cons
- Liens étroits avec l'écosystème Calico
- Les contrôles d'évacuation doivent être soigneusement réglés
- Les options SaaS limitent l'autogestion
- L'accent est mis sur la sécurité plutôt que sur la profondeur du routage
Informations sur le contact
- Site web : www.tigera.io
- Téléphone : +1 415-612-9546
- Courriel : contact@tigera.io
- Adresse : 2890 Zanker Rd Suite 205 San Jose, CA 95134
- LinkedIn : www.linkedin.com/company/tigera
- Twitter : x.com/tigeraio
9. Envoy Proxy
Envoy Proxy sert de proxy de service et de périphérie construit en C++ pour les applications natives du cloud, et a commencé sa vie chez Lyft pour résoudre les problèmes de mise en réseau dans les microservices. Il agit comme un plan de données universel dans les maillages de services, s'asseyant à côté des applications pour gérer le trafic sans se lier à des langages ou des cadres spécifiques, et sa conception hors processus maintient l'utilisation de la mémoire à un niveau bas. Lorsque le trafic passe par une configuration Envoy, il lisse l'observabilité de l'ensemble, ce qui simplifie la détection des problèmes dans les services distribués enchevêtrés.
Le proxy brille par sa gestion intégrée de HTTP/2 et de gRPC, par son proxysage transparent à partir de HTTP/1.1, ainsi que par des astuces d'équilibrage de charge telles que les tentatives, les ruptures de circuit, les limites de taux et le routage sensible aux zones. La configuration s'effectue dynamiquement via les API, et il permet d'approfondir les statistiques du trafic L7, les traces distribuées, et même des aperçus spécifiques au protocole dans des éléments tels que les fils de MongoDB ou de DynamoDB.
Faits marquants
- Serveur hors processus à faible encombrement
- Prise en charge des proxy HTTP/2 et gRPC
- Réessais, coupure de circuit et limitation de débit
- API dynamiques pour les changements de configuration
- L7 Trafic et traçabilité de l'observabilité
- Surveillance des bases de données au niveau du protocole
Pour
- Indépendant de la plate-forme pour les environnements mixtes
- Haute performance dans les grandes mailles
- Facile à intégrer dans les proxys existants
- Des mesures cohérentes pour tous les services
Cons
- Nécessite des enveloppes de maille pour une coordination complète
- La base C++ signifie des reconstructions pour des ajustements
- L'observabilité nécessite une agrégation externe
- L'installation s'appuie sur YAML pour les règles complexes
Informations sur le contact
- Site web : www.envoyproxy.io
10. Kuma
Kuma fonctionne comme un plan de contrôle open-source superposé à Envoy, gérant la connectivité des services à travers Kubernetes, les VM et les mélanges hybrides. Il regroupe des politiques pour le trafic L4 et L7 afin de couvrir la sécurité, la découverte, le routage et la fiabilité, avec un support natif pour les passerelles d'entrée et les liens multizones qui couvrent les nuages ou les clusters. La configuration permet plusieurs maillages dans un cluster, réduisant ainsi les plans de contrôle séparés, et inclut des CRD pour la gestion native de Kubernetes.
La mise en service implique des commandes CLI rapides pour démarrer le plan de contrôle, puis une interface graphique s'ouvre via le port-forward pour les visuels, soutenue par les API REST et l'outil kumactl. Les politiques s'appliquent avec un minimum d'agitation, intégrant les proxies Envoy sans nécessiter d'expertise approfondie, et il évolue horizontalement en mode autonome ou zoné pour garder les opérations simples.
Faits marquants
- Politiques basées sur les envois pour le trafic L4/L7
- Prise en charge de maillages multiples dans des grappes uniques
- Passerelles de découverte et d'entrée natives
- GUI, CLI et REST pour la gestion
- Connectivité multizone à travers les nuages
- Mise à l'échelle horizontale dans les configurations hybrides
Pour
- Fonctionne de manière homogène sur les K8 et les VM
- Déploiement rapide d'une politique sans configuration fastidieuse
- L'interface graphique intégrée facilite la visualisation des clusters
- Réduction de la dispersion des plans de contrôle
Cons
- La dépendance à l'égard d'Envoy alourdit la charge de travail du proxy
- La configuration des zones doit être effectuée en amont pour les zones multiples
- Le transfert de port de l'interface graphique limite l'accès à distance
- Le comptage des politiques reste axé sur les politiques
Informations sur le contact
- Site web : kuma.io
- Twitter : x.com/KumaMesh
11. Solo.io
Solo.io propose Gloo Gateway et Gloo Mesh pour gérer la connectivité cloud, la passerelle gérant les API et le trafic AI tandis que le réseau prend en charge l'orchestration des services. Ces éléments connectent les services dans les configurations Kubernetes, en intégrant la sécurité et l'observabilité pour suivre et contrôler les flux sans trop compliquer la pile. Gloo Mesh se connecte à Istio pour les tâches de maillage, et la passerelle adopte des approches ambiantes pour alléger les ressources dans les architectures distribuées.
Les outils se concentrent sur la sécurisation des transferts entre les charges de travail, avec des contrôles pour le routage et la surveillance qui s'adaptent aux modèles " cloud-native ". Le déploiement se fait dans des environnements de conteneurs, en intégrant Istio si nécessaire pour des fonctions de maillage plus approfondies, mais en gardant le cœur simple pour les liens avec l'API ou les services internes.
Faits marquants
- Passerelle API et IA pour l'entrée du trafic
- Maillage intégré à Istio pour les services
- Contrôles de sécurité et d'observabilité
- Maillage ambiant pour réduire les ressources
- Connectivité axée sur Kubernetes
- Routage et surveillance des charges de travail
Pour
- Mélange de la passerelle et du maillage en une seule vue
- Les options ambiantes facilitent la mise à l'échelle
- En lien avec les utilisateurs d'Istio
- Couvre l'API jusqu'aux flux internes
Cons
- Fiabilité d'Istio pour un maillage complet
- La passerelle est orientée vers le trafic périphérique
- L'ambiance mûrit encore par endroits
- L'observabilité nécessite le chaînage des outils
Informations sur le contact
- Site web : www.solo.io
- LinkedIn : www.linkedin.com/company/solo.io
- Twitter : x.com/soloio_inc
12. HAProxy
HAProxy a commencé comme un équilibreur de charge open-source rapide et alimente toujours une grande partie du trafic Internet dans son édition communautaire. La version entreprise ajoute des modules supplémentaires pour le WAF, la détection des robots et la gestion centralisée via Fusion, tout en conservant le même moteur de base qui gère TCP, HTTP et QUIC. Les opérateurs la placent devant les niveaux web ou les passerelles API lorsqu'ils ont besoin d'une latence inférieure à la milliseconde et d'un contrôle étroit des connexions.
Les déploiements vont des simples dépôts binaires aux contrôleurs d'entrée Kubernetes, avec le niveau payant ajoutant des choses comme le basculement actif-actif et le support officiel. Il reste populaire parce que la syntaxe de configuration est simple et que les performances sont rarement décevantes.
Faits marquants
- Équilibrage de la charge TCP et HTTP avec les listes de contrôle d'accès (ACL)
- WAF d'entreprise et modules complémentaires de gestion des robots
- Support QUIC et HTTP/3
- Tableau de bord de fusion pour le contrôle multi-instances
- Contrôles de santé et mise en file d'attente des connexions
Pour
- Extrêmement rapide et peu gourmand en mémoire
- Syntaxe de configuration que la plupart des opérateurs connaissent déjà
- L'édition communautaire couvre la plupart des besoins
- Option d'ingress Kubernetes solide
Cons
- Les fonctionnalités d'entreprise bloquées derrière un mur payant
- Les règles du WAF sont moins étendues que celles des outils dédiés
- Le plan de contrôle de Fusion ajoute une nouvelle pièce
- Pas de découverte de services intégrée
Informations sur le contact
- Site web : www.haproxy.com
- Téléphone : +1 (844) 222-4340
- Adresse : 1001 Watertown St Suite 201B Newton MA 02465 États-Unis
- LinkedIn : www.linkedin.com/company/haproxy-technologies
- Facebook : www.facebook.com/haproxy.technologies
- Twitter : x.com/haproxy
13. Matière grise
Greymatter superpose un plan de contrôle agentique aux charges de travail pour gérer les connexions de confiance zéro et les maillages de services. Il automatise l'application des politiques, le cryptage et les cycles de vie des mandataires dans les nuages ou à la périphérie, en s'appuyant sur l'observabilité des flux de trafic et des journaux d'audit. Les opérateurs définissent des règles que le système applique sans modifications manuelles, en gérant lui-même les certificats et les passerelles.
La plateforme fonctionne sur des distributions Kubernetes ou des clouds nus tels qu'AWS et Azure, prenant en charge les endroits déconnectés ou hautement sécurisés. L'intégration avec les outils SIEM permet d'acheminer les événements de sécurité vers l'extérieur, et elle s'intègre dans les pipelines pour les vérifications code-to-deploy. Les personnes travaillant dans des domaines réglementés l'utilisent pour maintenir les connexions verrouillées tout en déplaçant les services.
Faits marquants
- Politique autonome et cryptage
- Proxy et passerelles autogérés
- Observabilité et audits à l'échelle de la flotte
- Connectivité multi-cloud et en périphérie
- Automatisation du Cert pour les charges de travail NPE
- Crochets CI/CD pour DevSecOps
Pour
- Réduction des opérations manuelles de maillage grâce à l'automatisation
- S'adapte aux installations hybrides sans retouche
- Les pistes d'audit alimentent les outils existants
- Gestion des environnements déconnectés
Cons
- Liens avec Kubernetes pour des fonctionnalités complètes
- L'approfondissement de la politique nécessite une planification en amont
- L'observabilité tire parti des intégrations
- La couche d'agent ajoute une légère surcharge
Informations sur le contact
- Site web : greymatter.io
- Adresse : 4201 Wilson Blvd, 3rd Floor Arlington, VA 22203
- Facebook : www.facebook.com/greymatterio
- Twitter : x.com/greymatterio
- Instagram : www.linkedin.com/company/greymatterio
14. Maille Kong
Kong Mesh se configure comme un maillage de services qui s'étend sur les clusters Kubernetes et les machines virtuelles, injectant des proxies pour gérer la façon dont les services se parlent entre eux. Les opérateurs le configurent pour les règles de trafic, les contrôles d'identité et la surveillance de la santé directement à partir du plan de contrôle, qui peut s'asseoir sur Konnect pour une vue hébergée ou fonctionner de manière autonome sur l'infrastructure existante. La configuration permet de diviser les charges de travail en zones ou en locataires, ce qui permet de maintenir des politiques uniformes sans scripts personnalisés.
En pratique, il superpose la découverte et mTLS à tout ce dont les applications ont besoin, qu'elles soient conteneurisées ou qu'elles s'exécutent en mode " bare metal ". Cela signifie que les développeurs se concentrent sur le code tandis que le maillage gère le reroutage en cas de défaillance ou la répartition des charges. L'interface graphique de Konnect rassemble tout dans un tableau de bord, mais les utilisateurs peuvent s'en tenir à l'interface CLI ou à YAML si c'est ce qu'ils préfèrent.
Faits marquants
- mTLS et découverte de services intégrés
- Gestion du trafic avec les serveurs mandataires (sidecar proxies)
- Prise en charge de plusieurs zones et de plusieurs locataires
- S'exécute sur Kubernetes ou sur des machines virtuelles.
- L'interface graphique de Konnect pour des vues centralisées
- Contrôles d'accès et métriques d'entreprise
Pour
- S'adapte sans problème aux environnements hybrides
- Cohérence des politiques d'une zone à l'autre
- Pas besoin d'outils de découverte distincts
- L'interface graphique réduit les recherches en ligne de commande
Cons
- L'injection de proxy ajoute une certaine latence
- Le câblage multizone nécessite une configuration initiale
- S'appuie sur Konnect pour l'hébergement complet
- Les bits d'entreprise nécessitent une licence
Informations sur le contact
- Site web : developer.konghq.com
- LinkedIn : www.linkedin.com/company/konghq
- Twitter : x.com/kong
Conclusion
En fin de compte, l'abandon de Consul se résume généralement à une question : voulez-vous continuer à utiliser un énième système distribué, ou voulez-vous enfin quelque chose qui arrête de vous voler vos week-ends ?
Les options disponibles aujourd'hui sont très variées. Ce qu'elles ont en commun, c'est qu'aucune d'entre elles ne vous oblige à devenir un expert Raft juste pour déployer une fonctionnalité.
Choisissez celui qui correspond au désordre que vous essayez de fuir. Si la plus grande douleur est de garder etcd et les pannes de potins, penchez-vous vers les proxies plus légers ou les plans de contrôle gérés. Si vous êtes déjà plongé dans Kubernetes et que vous voulez juste mTLS et l'observabilité sans le drame, la foule de mesh vous couvre. Et si vous êtes honnêtement fatigué d'écrire le moindre code d'infrastructure, il existe maintenant des plateformes qui vous déchargeront de ce fardeau.
Quel que soit votre choix, l'ère du “nous devons utiliser Consul parce que c'est ce que nous avons toujours fait” est révolue. Envoyez du code, dormez la nuit, laissez quelqu'un d'autre s'occuper de la découverte des services pour une fois. Vous l'avez bien mérité.
