Traffic Director vous aide à exécuter des microservices dans un maillage de services mondial. Le réseau maillé gère la mise en réseau de vos microservices afin que vous puissiez écrire du code d'application qui n'a pas besoin de connaître les complexités du réseau sous-jacent. Cette séparation de la logique d'application de la logique réseau vous permet d'améliorer votre vitesse de développement, d'augmenter la disponibilité des services et d'instaurer des pratiques DevOps modernes pour votre organisation.
Votre maillage de services comprend vos applications, un plan de données compatible xDS v2 (généralement le proxy Open Source Envoy) et Traffic Director comme plan de contrôle du réseau maillé.
Ce document récapitule les fonctionnalités disponibles dans Traffic Director.
Plan de contrôle entièrement géré pour le maillage de services
Traffic Director est un service de plan de contrôle géré et hautement disponible qui s'exécute dans Google Cloud. Vous n'avez pas besoin d'installer ni de mettre à jour votre plan de contrôle. Vous disposez donc d'un composant de moins à gérer dans votre infrastructure de maillage de services.
Plates-formes permettant d'exécuter des services de réseau maillé
Vous pouvez exécuter des applications sur les plates-formes suivantes et les adopter dans un maillage de services mondial configuré par Traffic Director.
| Fonctionnalité | Compatible |
|---|---|
| Machines virtuelles (VM) Compute Engine | ✔ |
| Instances de conteneur Google Kubernetes Engine | ✔ |
| Instances de conteneur Kubernetes sur Compute Engine | ✔ |
Gestion des services
Les services d'un réseau maillé configuré par Traffic Director bénéficient de la détection de services, de l'autoscaling des backends et de l'enregistrement automatique des points de terminaison :
Lorsqu'une application dans votre réseau maillé souhaite communiquer avec une autre application, elle peut appeler ce service par son nom. C'est ce que nous appelons la détection de services.
Ces services s'appuient sur des instances qui exécutent le code de votre application. Ces instances évoluent de manière dynamique en fonction de vos besoins.
Les nouvelles instances créées ou supprimées doivent être associées à votre service. C'est ce que nous appelons l'enregistrement des points de terminaison.
| Fonctionnalité | Compatible |
|---|---|
| Déploiement automatisé de proxys side-car pour les VM Compute Engine | ✔ |
| Détection de services basée sur le nom d'hôte | ✔ |
| Autoscaling d'instance basé sur l'utilisation du processeur | ✔ |
| Autoscaling d'instance basé sur la capacité de charge/diffusion du trafic (VM Compute Engine dans les MIG uniquement) | ✔ |
| Autoréparation d'instances basée sur des vérifications d'état configurables | ✔ |
| Enregistrement automatique des points de terminaison pour les instances de VM Compute Engine | ✔ |
| Enregistrement automatique des points de terminaison pour les instances/pods de conteneurs GKE | ✔ |
| API permettant d'ajouter ou de supprimer par programmation des points de terminaison | ✔ |
Points de terminaison pour le trafic de votre plan de données
Les microservices utilisent le plan de données pour accéder aux services de votre réseau maillé, ainsi qu'à l'extérieur de celui-ci. Traffic Director vous permet de séparer la logique d'application de la logique réseau, de sorte que votre application se limite à envoyer des requêtes au plan de données (par exemple, le proxy side-car s'exécutant avec l'application). Le plan de données se charge d'envoyer ces requêtes au point de terminaison approprié.
Dans le tableau ci-dessous, les applications décrites comme faisant partie du réseau maillé sont celles qui communiquent avec d'autres services à l'aide du plan de données géré par Traffic Director. Ces applications peuvent envoyer du trafic vers des services intégrés, ainsi que des services en dehors du réseau maillé.
| Fonctionnalité | Compatible |
|---|---|
| Applications basées sur une VM dans le réseau maillé | ✔ |
| Applications basées sur des conteneurs dans le réseau maillé | ✔ |
| Applications basées sur une VM en dehors du réseau maillé | ✔ |
| Applications basées sur des conteneurs en dehors du réseau maillé | ✔ |
Topologies de plans de données
Dans le modèle de maillage de services, vos applications communiquent à l'aide d'un plan de données. Ce plan de données se compose souvent de proxys side-car déployés avec vos applications. Traffic Director est extrêmement flexible et accepte les topologies de plan de données qui répondent aux besoins de votre réseau de services.
| Fonctionnalité | Compatible |
|---|---|
| Proxy side-car s'exécutant à côté des applications | ✔ |
| Services gRPC sans proxy | ✔ |
| Proxy intermédiaires entre deux applications dans un réseau maillé | ✔ |
| Proxys de périphérie à la limite de votre réseau maillé | ✔ |
| Réseau maillé couvrant plusieurs clusters GKE et/ou VM Compute Engine dans plusieurs régions | ✔ |
Configuration programmatique basée sur l'API
Toute la configuration est prête à l'emploi et exposée via l'API REST et le tableau de bord, ce qui vous permet d'automatiser les modifications au sein d'équipes importantes et de les gérer de façon programmatique.
| Fonctionnalité | Compatible |
|---|---|
| API REST | ✔ |
| Google Cloud Console | ✔ |
Interface de ligne de commande gcloud |
✔ |
| Deployment Manager | ✔ |
| Compatibilité avec Terraform | ✔ |
Protocoles de requête
Les applications peuvent utiliser les protocoles de requête suivants lorsqu'elles communiquent à l'aide du plan de données configuré par Traffic Director.
| Fonctionnalité | Compatible |
|---|---|
| HTTP | ✔ |
| HTTP/2 | ✔ |
| gRPC | ✔ |
Routage et gestion du trafic
Traffic Director est compatible avec les règles de gestion avancée du trafic que vous pouvez utiliser pour orienter, répartir et configurer le trafic lorsqu'il transite par votre plan de données. Notez que la plupart des options de gestion avancée du trafic ne sont pas activées pour Traffic Director avec des services gRPC sans proxy.
| Fonctionnalité | Compatible avec le proxy Envoy | Compatible avec gRPC sans proxy |
|---|---|---|
| Routage des requêtes HTTP/de couche 7 basé sur la correspondance de suffixe/préfixe/complète/expression régulière sur : | ||
| • Nom d'hôte | ✔ | ✔ 1.30.0 ou ultérieure |
| • Chemin d'accès | ✔ | ✔ 1.31.0 ou ultérieure |
| • En-têtes | ✔ | ✔ 1.31.0 ou ultérieure |
| • Méthode | ✔ | ND |
| • Cookies | ✔ | ✔ 1.31.0 ou ultérieure |
| • Paramètres de requête | ✔ | ND |
| Injection de pannes | ✔ | |
| Délais avant expiration configurables | ✔ | |
| Tentatives | ✔ | |
| Redirections | ✔ | ND |
| Réécritures de l'URI | ✔ | |
| Transformations d'en-tête de requête/réponse | ✔ | |
| Répartition du trafic | ✔ | |
| Mise en miroir du trafic | ✔ | |
| Détection des anomalies | ✔ |
Équilibrage de charge
Vous pouvez configurer des algorithmes et des méthodes d'équilibrage de charge avancés pour équilibrer la charge au niveau du service, du groupe backend (groupes d'instances ou de points de terminaison du réseau) et du backend ou du point de terminaison. Pour en savoir plus, consultez la page Présentation des services backend.
| Fonctionnalité | Compatible avec le proxy Envoy | Compatible avec gRPC sans proxy |
|---|---|---|
| Sélection de services basée sur la répartition du trafic en fonction d'une pondération | ✔ | |
| Sélection du backend (groupe d'instances ou groupe de points de terminaison du réseau) en fonction de la région (préférez la région la plus proche avec une capacité de backend opérationnelle) | ✔ | ✔ 1.30.0 ou ultérieure |
| Sélection du backend à l'aide du mode d'équilibrage basé sur le taux (requêtes par seconde) | ✔ | ✔ 1.30.0 ou ultérieure |
| Sélection du backend en fonction du mode d'équilibrage basé sur l'utilisation (VM dans les groupes d'instances Compute Engine uniquement) | ✔ | ✔ 1.30.0 ou ultérieure |
| Capacité maximale configurable par backend (Compute Engine et GKE uniquement) | ✔ | ✔ 1.30.0 ou ultérieure |
| Ruptures de circuit | ✔ | |
Sélection du backend en fonction de règles d'équilibrage de charge configurables* :
|
✔ | Round robin (à tour de rôle) uniquement |
* Pour en savoir plus, consultez la page localityLbPolicy.
Basculement
Les charges de travail d'entreprise reposent généralement sur des déploiements à haute disponibilité pour garantir la disponibilité des services. Traffic Director accepte ces types de déploiements en activant la redondance multizone/multirégionale.
| Fonctionnalité | Compatible |
|---|---|
| Basculement automatique vers une autre zone de la même région dont la capacité de backend est opérationnelle | ✔ |
| Basculement automatique vers la région la plus proche avec une capacité de backend opérationnelle | ✔ |
Vérifications d'état
Vérification d'état centralisée pour déterminer l'état du backend. Pour plus d'informations, consultez la page Présentation des vérifications d'état.
| Fonctionnalité | Compatible |
|---|---|
| Vérifications de l'état gRPC | ✔ |
| Vérifications d'état HTTP | ✔ |
| Vérifications d'état HTTPS | ✔ |
| Vérifications d'état HTTP/2 | ✔ |
| Vérifications d'état TCP | ✔ |
Vérifications d'état configurables :
|
✔ |
| Chemin de requête configurable (HTTP, HTTPS, HTTP/2) | ✔ |
| Chaîne ou chemin de requête configurable (TCP ou SSL) | ✔ |
| Chaîne de réponse attendue configurable | ✔ |
Observabilité
Les outils d'observabilité fournissent des informations de surveillance, de débogage et de performances pour vous aider à comprendre votre maillage de services. Les fonctionnalités suivantes sont fournies prêtes à l'emploi ou configurées dans votre plan de données. Votre code d'application ne nécessite aucune action particulière pour générer ces données d'observabilité.
Le tableau de bord d'état du service est disponible avec les services gRPC sans proxy, mais vous ne pouvez pas configurer les fonctionnalités de journalisation et de traçage du plan de données. Traffic Director ne permet pas deconfigurer les fonctionnalités de journalisation et de traçage d'une application gRPC. Pour les activer, vous devez suivre les instructions fournies dans les sections de dépannage ou les guides gRPC disponibles sur les sites Open Source. Par exemple, vous pouvez utiliser Opencensus pour activer la collecte de métriques et le traçage dans vos services gRPC sans proxy.
| Fonctionnalité | Compatible avec les proxys | Compatible avec les services gRPC sans proxy |
|---|---|---|
| Tableau de bord de l'état du service | ✔ | ✔ |
| Journalisation du plan de données | ✔ | |
| Traçage du plan de données | ✔ |
Affinité de session
Les communications client-serveur impliquent souvent plusieurs requêtes successives. Dans ce cas, il est utile d'acheminer les requêtes client successives vers le même backend ou le même serveur. Traffic Director fournit des options configurables permettant, autant que possible, d'envoyer les requêtes d'un client donné au même backend, à condition que le backend soit opérationnel et dispose de la capacité requise. Pour en savoir plus, consultez la page Présentation des services backend.
| Fonctionnalité | Compatible avec les proxys | Compatible avec les services gRPC sans proxy |
|---|---|---|
| Adresse IP du client | ✔ | |
| Cookie HTTP | ✔ | |
| En-tête HTTP | ✔ | |
| Cookies générés (définit le cookie du client à la première requête) | ✔ |
Topologies de réseaux
Traffic Director est compatible avec les topologies de réseaux Google Cloud courantes.
| Fonctionnalité | Compatible |
|---|---|
| Réseau unique dans un projet Google Cloud | ✔ |
| VPC partagé (réseau unique partagé entre plusieurs projets Google Cloud) | ✔ |
Consultez la section Limites pour obtenir une explication détaillée de la compatibilité du VPC partagé avec Traffic Director.
Conformité
Traffic Director est conforme aux normes suivantes.
| Certification de conformité | |
|---|---|
| HIPAA | ✔ |
| ISO 27001, ISO 27017, ISO 27018 | ✔ |
| SOC1, SOC2, SOC3 | ✔ |
| PCI DSS | ✔ |