Dans un cluster Kubernetes réparti sur plusieurs zones, le comportement par défaut peut être surprenant. Quand un service doit joindre un autre pod, Kubernetes choisit une destination au hasard. Ce système, connu sous le nom de round-robin, est simple mais souvent inefficace. Il ne tient pas compte de l'emplacement physique des pods.

Votre requête pourrait donc traverser des frontières de zones de disponibilité (AZ) sans aucune raison, même si une réplique du service se trouve juste à côté. Ce trafic inter-zones a deux conséquences majeures : il augmente la latence et, plus important encore, il peut générer des coûts imprévus.

Les fournisseurs de cloud facturent généralement le transfert de données entre différentes zones de disponibilité. Même si ces zones sont dans la même région, chaque gigaoctet qui traverse cette frontière invisible s'ajoute à votre facture. Pour une application à fort trafic, ces frais peuvent rapidement devenir significatifs. Le routage aléatoire ignore complètement cette contrainte économique.

De plus, garder le trafic local réduit la latence. Envoyer une requête à un serveur dans un autre bâtiment est forcément plus lent que de la traiter sur place. Pour les applications où chaque milliseconde compte, le routage local est une nécessité, pas un luxe.

Pour résoudre ce problème, Kubernetes a introduit un concept appelé Topology Aware Hints. L'idée était de fournir des "indices" aux composants réseau pour les encourager à privilégier les points de terminaison locaux. Cette fonctionnalité a mûri et, depuis Kubernetes 1.27, elle a été renommée et stabilisée sous le nom de Topology Aware Routing (TAR).

Le principe reste le même : ajouter une intelligence géographique au routage. Au lieu de choisir un pod au hasard, le système consulte des indices pour déterminer si une destination locale est disponible. Si c'est le cas, il l'utilise en priorité. Le trafic ne quitte la zone que si aucun pod local ne peut traiter la requête.

Ce mécanisme repose sur un contrôleur clé : le contrôleur EndpointSlice. C'est lui qui analyse la distribution des pods d'un service à travers les différentes zones. Si les pods sont répartis de manière inégale, il n'active pas le routage topologique pour éviter de surcharger une zone. Mais si la répartition est équilibrée, il enrichit les objets EndpointSlice avec des indices de zone. Ces indices indiquent aux clients, comme kube-proxy, quels points de terminaison sont locaux, leur permettant ainsi de prendre des décisions de routage plus intelligentes.

L'activation de cette fonctionnalité permet donc de réduire les coûts et d'améliorer les performances sans effort manuel, en alignant simplement la logique réseau de Kubernetes avec la réalité physique de votre infrastructure cloud.

Testez vos connaissances sur le routage topologique.

En résumé, le Topology Aware Routing est un outil puissant pour optimiser les clusters Kubernetes multi-zones, en rendant le réseau à la fois plus rapide et moins cher.