À propos du pilotage des services

Présentation

Le pilotage des services GKE vous permet de contrôler la manière dont le trafic réseau circule dans votre cluster GKE. Vous pouvez définir des règles pour orienter des types spécifiques de trafic vers les fonctions réseau déployées dans votre cluster. Le pilotage des services GKE est semblable au routage basé sur des règles, qui permet d'ignorer le chemin normal du trafic réseau.

Terminologie et concepts

Cette page utilise les concepts suivants :

Fonction de service (SF)

Une fonction de service est un composant logiciel qui fonctionne sur les paquets de données reçus. Une couche Service peut fonctionner sur n'importe quelle couche du modèle OSI à partir de la couche 2 (couche de liaison de données).

Les fonctions de service peuvent être classées comme suit :

  • Pare-feux pour la sécurité
  • Proxys pour contrôler les accès
  • Accélération du WAN pour améliorer la vitesse
  • Inspection approfondie des paquets (DPI) pour analyser du contenu
  • Interception légale (LI) pour la surveillance et l'enquête
  • Traduction d'adresses réseau (NAT) pour les adresses IP privées et publiques
  • HTTP pour l'enrichissement des en-têtes
  • Équilibreurs de charge pour répartir efficacement le trafic

Les autres termes associés aux fonctions de service sont les suivants :

  • Appareils de conteneurs
  • Appareils virtuels
  • Fonctions réseau virtualisées (NFV)
  • Fonctions réseau conteneurisées (CNF)
  • Fonctions réseau cloud natives (CNF)

Dans le pilotage des services, un objet Service représente une fonction de service (SF).

Chaîne de fonctions de service (SFC)

Une chaîne de fonctions de service (SFC) est une série de fonctions de service, telles que des pare-feux, des proxys ou des équilibreurs de charge associés, qui permettent de traiter le trafic réseau dans un ordre spécifique. Cette chaîne agit comme un pipeline, où chaque fonction de service effectue une tâche particulière sur le trafic avant de la transmettre à la fonction suivante.

La chaîne de fonctions de service est également dénommée Service Chain (SC).

Dans le pilotage des services, l'objet ServiceFunctionChain représente une chaîne de fonctions de service (SFC).

Une fonction de service fonctionne indépendamment de toute chaîne de fonctions de service. La fonction de service ignore généralement de quelles les chaînes de fonctions de service elle fait partie.

Pilotage des services

Le pilotage des services achemine les paquets vers la fonction de service sélectionnée de manière complètement transparente pour la source et la destination. Ce concept est parfois appelé "routage basé sur des règles", "redirection du trafic" ou "transfert de fonction de service". Le pilotage des services effectue un routage transparent à l'aide de l'encapsulation Geneve + NSH (voirRFC 8926, RFC 8300, Geneve + NSH IETF Draft).

Voici quelques-unes des caractéristiques importantes du pilotage des services :

  • Équilibrage de charge sur les pods backend d'une fonction de service : les fonctions de service s'exécutent souvent sur plusieurs pods à des fins d'évolutivité et de fiabilité. Le pilotage des services répartit équitablement le trafic réseau entrant entre ces pods afin d'éviter la surcharge d'un seul pod.
  • Compatibilité avec l'affinité de flux à cinq tuples (tous les sauts intermédiaires doivent être stables pour un flux donné) : un flux à cinq tuples permet d'identifier un flux de trafic réseau spécifique en fonction de la l'adresse IP source, le port source, l'adresse IP de destination, le port de destination et le protocole. Le pilotage des services garantit que tous les paquets d'un même flux sont systématiquement dirigés vers le même ensemble de fonctions de service (sauts).
  • Activation d'un chemin de données de retour symétrique : un chemin de données de retour symétrique signifie que le trafic de réponse suit le même chemin vers la source que le trafic de requête d'origine. Le pilotage des services assure cette symétrie, ce qui est important pour certains protocoles réseau et applications.

Pour tout trafic réseau donné dirigé vers le service, les pods de fonction de service intermédiaires gèrent tous les paquets de ce trafic réseau particulier, ce qui garantit des sauts intermédiaires cohérents et une route prévisible. Les mêmes pods de fonction de service reçoivent le trafic retour pour garantir un flux de trafic symétrique. Si le trafic d'origine est envoyé à une destination dans le même cluster, le trafic retour trouve automatiquement un chemin de retour via la même chaîne de service. Si le trafic d'origine se trouve en dehors du cluster, la fonction de service finale de la chaîne attire le trafic vers elle-même à l'aide de la traduction d'adresse réseau source (SNAT) ou d'un proxy, qui sert d'intermédiaire.

Cas d'utilisation

Le pilotage des services GKE intègre le routage basé sur des règles dans vos clusters. Cela permet les principaux cas d'utilisation suivants :

Services de sécurité autogérés :

Les organisations peuvent construire leur propre infrastructure de sécurité à l'aide de fonctions réseau conteneurisées, telles que les pare-feux virtuels (vFW), les pare-feux virtuels nouvelle génération (vNG-FW) et les systèmes virtuels de détection des intrusions (vIDS). Le pilotage des services garantit que le trafic est acheminé via ces CNF avant d'atteindre sa destination prévue, fournissant ainsi une couche de protection et de contrôle.

Fournisseurs de sécurité gérés (MSP) :

Les fournisseurs de sécurité gérés peuvent utiliser le pilotage des services GKE pour acheminer votre trafic via leurs chaînes de services de sécurité basées sur le cloud. Cela leur permet de proposer des solutions de sécurité complètes, y compris des passerelles Web sécurisées (SWG), SASE (Secure Access Service Edge) et des fonctionnalités SD-WAN (Software-Defined Wide Area Network).

Télécommunications et réseaux 5G :

Le pilotage des services gère les flux de trafic pour diverses fonctions réseau au sein des infrastructures de télécommunications et 5G. Vous pouvez orchestrer des routeurs virtuels (vRouters), des contrôleurs virtuels de session en périphérie (vSBC) et des fonctions réseau 5G principales pour garantir une gestion efficace du trafic, un équilibrage de charge et l'application de règles de sécurité ou de qualité de service spécifiques.

Fonctionnement du pilotage des services

Cette section décrit le fonctionnement des différents composants du pilotage des services.

Fonction de service

  1. Identifie le flux de trafic réseau : le pilotage des services GKE identifie chaque connexion réseau à l'aide d'un ID de flux unique, un hachage à cinq tuples de l'adresse IP source, du port source et de l'adresse IP de destination, du port de destination et du protocole du paquet.

  2. Assure l'affinité de flux : le pilotage des services garantit l'affinité de flux en dirigeant tous les paquets ayant le même ID de flux vers le même chemin d'accès aux fonctions de service (SF).

  3. Modifie les paquets pour créer de nouveaux flux : si une fonction de service modifie l'un des champs à cinq tuples d'un paquet. Par exemple, la modification de l'adresse IP source par NAT crée un flux.

  4. Sélection du trafic pour les nouveaux flux : le processus de sélection du trafic évalue le nouveau flux pour déterminer son chemin dans le Service Functions restant, en prenant potentiellement une route différente du flux d'origine.

  5. Gère les proxys et les NAT comme deux flux : le trafic via des proxys ou des NAT est considéré comme deux flux distincts, la source vers le proxy/NAT et le proxy/NAT vers la destination. Le pilotage des services ne garantit pas le même chemin pour ces deux flux.

  6. Valide l'adresse source : les SF sont toujours soumises à la validation de l'adresse source, même pour le trafic non dirigé par le pilotage des services. Si une fonction de service génère un nouveau flux avec une adresse IP source non concordante, ces paquets sont supprimés à moins d'être explicitement autorisés.

  7. Maintien de la transparence d'encapsulation : le pilotage des services utilise l'encapsulation Geneve pour le trafic entre SF, mais les pods de la fonction de service eux-mêmes ne le savent pas. Les paquets sont déchiffrés avant d'entrer dans le pod, ce qui simplifie le développement des fonctions de service.

Connexions existantes

Lorsque vous créez un TrafficSelector, le pilotage des service l'applique automatiquement à toutes les connexions existantes qui correspondent aux critères du sélecteur. Il redirige les paquets de ces connexions vers les fonctions de service appropriées. La fonction de service elle-même est responsable de la gestion de ces connexions en transit. Une approche courante consiste à supprimer les paquets et à s'appuyer sur le client pour initier une nouvelle connexion, qui s'intègre ensuite parfaitement à la chaîne de services depuis le début.

Cycle de vie des ressources

Les ressources TrafficSelector et ServiceFunctionChain sont supprimées immédiatement après avoir été marquées pour suppression. Aucun webhook ou finaliseur n'empêche ou ne retarde la suppression des ressources.

Trafic pods vers service

Le pilotage des services effectue la sélection du trafic après la résolution de l'adresse IP virtuelle du service. Le trafic dirigé vers un service à l'aide de son adresse ClusterIP peut être sélectionné pour le pilotage des services si l'adresse IP du pod de destination appartient au CIDR spécifié dans le champ .egress.to.ipBlock une fois l'adresse IP virtuelle résolue.

Application de NetworkPolicy

Le pilotage des services ne contourne pas NetworkPolicy. Les règles de sortie au niveau du pod source et les règles d'entrée au niveau du pod de destination s'appliquent toujours au trafic sélectionné pour le pilotage des services. Cependant, il n'est pas soumis à l'application de NetworkPolicy en entrée ou en sortie d'une fonction de service. En effet, les règles d'entrée ou de sortie de NetworkPolicy sont bien définies pour les pods sources et de destination, mais pas pour les redirecteurs de paquets.

Avantages

L'adoption du pilotage des services GKE, associée à la transition vers les technologies cloud natives, présente les avantages suivants :

  • Offre Marketplace : les tiers peuvent proposer leur produit en conteneur sur Google Cloud Marketplace et utiliser les API de direction de service. Ils peuvent fournir un guide de déploiement basé sur l'API intégrée Kubernetes fournie et gérée par GKE.
  • Précision de Kubernetes : vous pouvez contrôler le trafic au sein de votre cluster Kubernetes. Vous pouvez classer le trafic que vous souhaitez piloter. Vous pouvez sélectionner les charges de travail pour lesquelles vous souhaitez appliquer le pilotage des services de manière sélective.
  • Bidirectionnel : le pilotage des services GKE est bidirectionnel par nature. Cela signifie que pour un flux donné, le chemin de retour est symétrique par rapport au chemin de transfert. Ce point est important lorsque les fonctions de service (SF) sont déployées en tant que groupe d'instances dupliquées. Assurez-vous que le même flux passe par le même ensemble d'instances répliquées afin de conserver l'état.
  • Compatibilité multiréseau : la majorité des fonctions de service nécessitent plusieurs interfaces de pod pour séparer le plan de données du plan de contrôle et de gestion. Certaines fonctions de service possèdent plusieurs interfaces dans leur architecture. Le pilotage des services GKE inclut l'intégration au multiréseau sur les pods. Il permet à un utilisateur de créer un pilotage de services sur un réseau de pods spécifique.
  • Diffusion de paquets bruts à l'application : le pilotage des services GKE encapsule le paquet d'origine et le transmet directement au pod. De cette façon, vous n'avez pas à effectuer de déchiffrement et votre application peut agir directement sur le paquet d'origine.

Étape suivante