Conception d'un réseau d'applications à haute disponibilité

Comportement d'équilibrage de la charge

Lorsqu'un routeur envoie une requête à une instance de service, la méthode d'équilibrage de la charge dépend de la configuration du cluster de l'hôte Kubernetes. La charge est équilibrée entre les pods pour les points d'extrémité du cluster ou entre les adresses IP pour les points d'extrémité externes.

Le facteur principal est le proxy du réseau Kubernetes kube-proxy. Vous pouvez configurer kube-proxy dans plusieurs modes, chacun offrant des fonctionnalités et des caractéristiques de performance différentes. () ne peut pas contrôler le kube-proxy mode, donc réfléchissez bien à l'effet du kube-proxy mode sur le comportement d'équilibrage de charge dont votre système a besoin.

Voici quelques modes courants de kube-proxy et leurs effets sur l'équilibrage de la charge :

• iptables - L'instance de service est sélectionnée de manière statistiquement aléatoire à l'aide des règles du site iptables .
• ipvs - L'instance de service est sélectionnée par défaut à l'aide de l'algorithme round-robin, mais d'autres options sont disponibles. Ce mode est également appelé mode serveur virtuel IP (IPVS).

Ces effets sur l'équilibrage de la charge sont également pertinents pour les alternatives à kube-proxy dans certaines interfaces de réseau de conteneurs (CNI).

Routage sur des réseaux d'application à trajets multiples

Les réseaux d'applications peuvent s'étendre sur plusieurs sites, nuages et grappes. Souvent, plusieurs chemins et routeurs sont mis en place pour la redondance du réseau. Le trafic peut emprunter tout ou partie de ces chemins. Il est important de comprendre les facteurs qui influencent le chemin emprunté par une connexion entre le routeur local et le routeur distant.

Dans , l'itinéraire est déterminé lorsque l'application cliente établit une connexion TCP. La décision concernant le chemin d'acheminement est statique : elle est prise une seule fois et ne change pas jusqu'à ce que le client interrompe la connexion, qu'un lien de routeur tombe en panne ou que le service devienne inaccessible. Ce comportement fonctionne bien lorsque des routeurs ou des instances de service deviennent indisponibles, car lorsque la connexion est interrompue, le client peut se reconnecter en cas de défaillance du réseau grâce à des chemins d'accès redondants.

Toutefois, ce comportement empêche également les demandes de revenir au meilleur itinéraire lorsque les routeurs ou les instances de service sont rétablis. Pour revenir en arrière, les applications clientes doivent fermer et recréer leurs connexions de service. Ce comportement dépend de l'application, il est donc important de prendre en compte la logique de relance de votre application dans ces scénarios.

Coût du lien dans le routage

De nombreux réseaux d'applications utilisent plusieurs chemins de routage à travers le réseau afin de garantir une connectivité hautement disponible entre les applications. n'utilise qu'une seule route par connexion client. sélectionne généralement l'itinéraire dont le coût de liaison est le plus bas.

Le coût de la liaison est une mesure arbitraire du coût associé à l'envoi de données sur une liaison réseau spécifique. Il aide les routeurs à déterminer le chemin le plus efficace pour transmettre les demandes aux services. Le coût de la liaison peut être basé sur différents facteurs, tels que la largeur de bande, le délai ou la fiabilité de la liaison. En attribuant un coût à chaque lien, vous pouvez aider les routeurs à calculer le coût total d'un chemin en fonction de vos besoins et à sélectionner celui dont le coût est le plus bas. Ce comportement peut contribuer à optimiser les performances du réseau et l'utilisation des ressources.

Sur toute connexion TCP entre deux routeurs, peut mettre en file d'attente les connexions qui n'ont pas encore été transmises au service cible. Les connexions sont mises en file d'attente pour un service lorsque celui-ci est occupé à traiter d'autres connexions et n'est plus en mesure d'en traiter d'autres. Les connexions en file d'attente restent en file d'attente jusqu'à ce que le service ait terminé ses demandes en cours et soit disponible pour en traiter d'autres, auquel cas il commence à traiter la connexion la plus ancienne de la file d'attente.

Lorsqu'il existe plusieurs chemins pour atteindre un service, le routeur sélectionne un chemin en utilisant la somme de la profondeur de la file d'attente de connexion et le coût de la liaison. En bref, tient compte de la congestion du trafic dans sa décision de sélection du chemin.

Par exemple, considérons deux chemins de routage, p1 et p2, de l'application A vers le service B. Le coût de liaison de p1 est de 10. Le coût de liaison de p2 est de 25. Dans un premier temps, le site p1 est sélectionné pour les nouvelles connexions car il s'agit du chemin le moins coûteux. Le chemin p2 n'est sélectionné pour les nouvelles connexions que lorsque le service B sur p1 a 15 connexions en file d'attente. Cela signifie que la somme du coût du lien et des connexions en file d'attente est plus élevée sur p1 que sur p2. Alors que de nouvelles connexions continuent d'arriver et que la somme des connexions en file d'attente et du coût du lien sur p2 devient supérieure à la somme sur p1, p1 est à nouveau sélectionné pour de nouvelles connexions.

Par conséquent, il est important de considérer l'objectif des chemins de routage alternatifs. Si l'objectif est de fournir une capacité supplémentaire pour gérer les connexions, le coût delta entre les chemins alternatifs peut être faible. Si l'objectif est de fournir un chemin de secours, il faut s'assurer que le coût delta entre les chemins alternatifs est important. Un coût delta élevé permet de s'assurer que le chemin alternatif n'est pas choisi, sauf dans de rares circonstances, par exemple si le chemin principal n'est pas disponible.

Si le réseau ne peut pas acheminer une requête sur l'itinéraire présentant le coût de liaison le plus bas, il interrompt la connexion et oblige l'application à créer une nouvelle connexion. Cette nouvelle connexion peut être acheminée sur la nouvelle liaison à coût plus élevé. Même si le chemin à faible coût redevient disponible, le trafic reste sur le chemin à coût élevé jusqu'à ce que l'application ferme la connexion. Par conséquent, les applications qui mettent en cache les connexions de service peuvent avoir besoin de fermer les connexions persistantes afin que les changements dans les chemins d'accès disponibles soient utilisés.

Routage pour les demandes HTTP

Lorsqu'une application envoie plusieurs requêtes HTTP, on peut s'attendre à ce que chaque requête HTTP soit acheminée indépendamment des autres. Ce n'est généralement pas le cas, car les décisions de routage sont prises au moment de la connexion.

HTTP utilise TCP comme moyen de transport de la couche 4 pour les demandes HTTP. HTTP/1.1 et HTTP/2 utilisent des connexions TCP persistantes pour multiplexer plusieurs demandes HTTP sur une seule connexion. Dans ce cas, la décision d'acheminement est prise au début de la connexion TCP, et chaque demande HTTP au cours de cette connexion est acheminée par le même chemin jusqu'à la passerelle de destination. La durée des délais de connexion dépend des systèmes en question, mais peut aller de 5 à 15 secondes.

Certains systèmes plus anciens utilisent l'ancien protocole HTTP/1.0. Ce protocole crée une nouvelle connexion TCP pour chaque demande HTTP. Dans ce cas, chaque demande HTTP est acheminée indépendamment des autres.

Ce comportement est similaire à celui d'un équilibreur de charge réseau (NLB), qui équilibre le trafic sur la base des connexions de la couche 4. Cependant, ce comportement n'est pas similaire à celui d'un équilibreur de charge d'application (ALB), qui équilibre le trafic sur une couche 7 de requêtes.

Points clés pour la conception des chemins d'acheminement

En résumé, il est important de comprendre les points suivants lorsque vous concevez des chemins de routage pour un réseau :

• La répartition de la charge par un routeur particulier dépend de la configuration de votre cluster, mais la sélection d'une instance de service se fait généralement de manière aléatoire ou par un algorithme round-robin.
• Le chemin du routeur à travers le réseau d'application est déterminé lorsque le client établit une connexion TCP.
• Le chemin du routeur sélectionné est le chemin le moins coûteux disponible, en tenant compte à la fois du coût de liaison attribué et de l'encombrement du trafic.
• Plusieurs demandes HTTP au sein d'une connexion persistante empruntent le même chemin de routage.

Il convient donc de tenir compte des meilleures pratiques suivantes lors de la conception des chemins d'acheminement :

• Configurer plus d'un chemin d'accès entre une application et les services qu'elle utilise.
• Colocaliser plusieurs instances de service dans le même espace de noms pour obtenir une haute disponibilité.
• Déployer des instances de service dans plusieurs espaces de noms afin d'assurer la plus grande disponibilité possible.
• Définir les coûts de liaison de manière à ce que le coût du chemin du routeur préféré soit nettement inférieur au coût du chemin du routeur de secours.
• Les applications doivent régulièrement fermer des connexions et en créer de nouvelles, de sorte que lorsque la disponibilité des services ou des itinéraires change, les modifications apportées aux itinéraires disponibles soient utilisées.