Présentation du taggage DSCP de la qualité de service

La qualité de service (QoS) gère le trafic réseau et assure les performances des applications critiques en contrôlant des facteurs tels que la bande passante, la latence et la perte de paquets. Cette technologie donne la priorité à certains types de trafic réseau par rapport à d'autres lorsque les ressources réseau sont limitées ou saturées. Vous pouvez utiliser le tag DSCP (Differentiated Services Code Point) pour hiérarchiser le trafic sur les réseaux IP modernes.

Pour savoir comment utiliser le tag DSCP, consultez Configurer le tag DSCP.

Fonctionnement du tag EgressDSCP

La qualité de service (QoS) gère le trafic réseau pour garantir que les applications critiques fonctionnent dans des situations de faible bande passante. Le tag EgressDSCP vous permet de taguer des paquets avec une valeur DSCP dans l'en-tête IP afin de communiquer le niveau de priorité aux appareils réseau en aval.

Charges de travail compatibles

Le tag EgressDSCP permet de hiérarchiser le trafic pour les charges de travail Google Distributed Cloud suivantes :

  • Charges de travail de conteneur : pods et services Kubernetes exécutés sur le cluster.
  • Machines virtuelles (VM) : charges de travail de VM exécutées via l'environnement d'exécution de VM, à condition qu'elles soient connectées au réseau par défaut.

Types de ressources pour le tag DSCP

Distributed Cloud utilise des ressources personnalisées spécifiques pour gérer les tags DSCP. Vous définissez la priorité de vos paquets à l'aide des objets suivants :

  • EgressDSCP: ressource personnalisée qui définit la valeur DSCP spécifique à insérer dans l'en-tête IP des paquets de trafic sélectionnés. Cet objet accepte une valeur entière comprise entre 0 et 63.
  • TrafficSelector: ressource personnalisée qui sélectionne précisément les flux de trafic réseau. Cette ressource accepte un entier de priorité compris entre 0 et 65535, avec une valeur par défaut de 1000. L'objet TrafficSelector fait référence à un objet EgressDSCP pour appliquer une action spécifique au trafic identifié. Même lorsque vous utilisez un TrafficSelector à portée d'espace de noms, vous devez inclure un sélecteur d'espace de noms pour identifier explicitement l'espace de noms des pods qui lancent le trafic ciblé.

Résolution de conflits

Lorsque plusieurs ressources TrafficSelector s'appliquent au même sujet, le système utilise une hiérarchie spécifique pour déterminer la priorité. Le système résout les conflits en suivant les principes suivants dans l'ordre :

  1. Priorité : le système applique le TrafficSelector avec la valeur de priorité numérique la plus faible.
  2. Spécificité de la plage CIDR : si les règles partagent la même priorité, le système applique la règle avec la limite CIDR la plus spécifique (la correspondance de préfixe la plus longue).
  3. Spécificité du port : si les règles partagent la même priorité et la même plage CIDR, le système applique la règle avec le port le plus spécifique.

Si une règle CIDR plus spécifique a une priorité numérique plus élevée (précédence inférieure), le système applique la règle plus large et ignore la règle plus spécifique.

Exemple d'ombrage

Prenons l'exemple des deux règles TrafficSelector suivantes appliquées à la même destination :

  • Règle A : priorité 100, CIDR de destination 192.168.1.0/24, marque DSCP 40.
  • Règle B : priorité 200, CIDR de destination 192.168.1.15/32, marque DSCP 46.

Même si la règle B spécifie un CIDR de destination plus précis (192.168.1.15/32), le système donne la priorité à la règle A, car sa valeur de priorité numérique est inférieure (100). Par conséquent, le système ignore la règle B et applique le tag DSCP 40 à tout le trafic sortant dirigé vers 192.168.1.15.

Limites

La fonctionnalité de tag DSCP inclut plusieurs contraintes pour son implémentation actuelle :

  • Trafic de sortie externe : vous ne pouvez taguer que le trafic nord-sud qui quitte le cluster, comme le trafic sortant initié par les charges de travail et le trafic de retour des services Kubernetes vers les clients externes.
  • Aucune application interne : bien que le système tague le trafic intracluster, Kubernetes n'applique pas les règles de QoS en interne en fonction de ces tags.
  • Marquage uniquement : le système ne tague que les en-têtes IP. Vous devez configurer votre infrastructure réseau physique en amont pour gérer l'application réelle de la QoS.
  • Protocoles compatibles : vous ne pouvez taguer que le trafic IPv4.
  • Services compatibles : vous ne pouvez taguer que le trafic des services LoadBalancer et NodePort.
  • Réseaux de machines virtuelles : vous ne pouvez taguer que les charges de travail de VM connectées au réseau par défaut.
  • Activation de la fonctionnalité : vous devez activer la fonctionnalité en ajoutant l' preview.baremetal.cluster.gke.io/traffic-selector: "enable" annotation à la ressource de cluster.
  • Valeurs par défaut du chemin de retour : pour le trafic de chemin de retour, la valeur DSCP est définie par défaut sur 0, sauf si elle est configurée explicitement.

Points à noter concernant la sécurité

Les utilisateurs non autorisés peuvent marquer le trafic non essentiel avec des valeurs DSCP élevées, ce qui perturbe les services critiques dans l'ensemble du cluster.

Pour atténuer les risques de sécurité, limitez l'accès à l'aide du contrôle des accès basé sur les rôles (RBAC) de Kubernetes :

  • Contrôles à l'échelle du cluster : limitez l'autorisation de créer ou de modifier des ressources EgressDSCP à portée de cluster aux administrateurs de cluster de confiance.
  • Contrôles d'espace de noms : gérez les ressources TrafficSelector par espace de noms afin que les utilisateurs ne puissent affecter que leurs charges de travail spécifiques.

Étape suivante