Aller au contenu principal

Atteindre Zaris depuis l'extérieur du cluster : des clients externes sans SDK natif

· 7 minutes de lecture
Clustron Team
Clustron Team
Ingénierie des systèmes distribués

Atteindre Zaris depuis l'extérieur du cluster

Exécutez Zaris dans Kubernetes et le chemin heureux est simple : les clients internes au cluster atteignent les pods par leurs adresses internes — IP de pod et noms DNS du cluster comme zaris-0.zaris.svc — et tout route proprement. Dès qu'un client se trouve à l'extérieur du cluster, cela casse. Une application externe ne peut pas appeler zaris-0.zaris.svc ni une IP de pod ; ces noms et adresses ne se résolvent et ne routent qu'à l'intérieur du réseau du cluster.

Ce n'est pas une bizarrerie de Zaris — c'est la séparation fondamentale entre le réseau interne du cluster et le monde extérieur. Elle mord le plus fort avec les clients conscients de la topologie. Un client Redis en mode cluster, ou tout client qui découvre les nœuds et route par clé, récupère une carte de topologie depuis le serveur et se connecte aux adresses qu'elle contient. Si ces adresses sont internes, un client externe obtient une carte remplie de points d'accès qu'il ne pourra jamais atteindre.

Zaris résout cela avec des adresses annoncées, gérées comme une « vue de frontière » par listener.

Pourquoi les adresses internes au cluster échouent à l'extérieur​

Kubernetes donne à chaque pod une identité interne : une IP de pod sur le réseau du cluster, et des noms DNS stables via un Service headless, tels que zaris-0.zaris.svc. À l'intérieur du cluster, ils routent parfaitement. À l'extérieur, ils n'ont aucun sens — le réseau du client externe n'a aucune route vers une IP de pod et aucun résolveur pour *.svc.

Lorsque Zaris répond à une requête de topologie ou de redirection, il renvoie des adresses. S'il renvoyait toujours ses adresses internes, un client externe recevrait une carte de nœuds auxquels il ne peut pas se connecter. Il récupérerait la topologie, tenterait consciencieusement d'ouvrir des connexions vers les nœuds annoncés, et échouerait sur chacun d'eux — alors même que le cluster est parfaitement sain.

Pourquoi un unique point d'accès LoadBalancer ne suffit pas​

Le premier correctif évident est un unique répartiteur de charge devant tout, et pour les clients simples cela fonctionne. Mais cela ne satisfait pas un client conscient de la topologie qui a besoin d'un adressage par nœud.

Toute la conception d'un client en mode cluster consiste à récupérer la liste des nœuds et à router chaque clé directement vers le nœud qui la possède, en suivant les redirections au fur et à mesure que la propriété se déplace. Pour cela, il a besoin d'une adresse distincte et atteignable pour chaque nœud — et non d'un unique point d'accès partagé qui les masque tous. Une seule IP virtuelle ne donne au client nulle part où envoyer une connexion par nœud ou une redirection. Chaque nœud doit donc être atteignable indépendamment depuis l'extérieur, et les adresses que Zaris annonce aux clients externes doivent être ces adresses par nœud atteignables de l'extérieur.

Adresses annoncées par listener : la vue de frontière​

Voici l'idée centrale. Chaque nœud — plus précisément, chaque listener sur un nœud — peut annoncer une adresse différente aux clients externes de celle qu'il utilise en interne. Zaris traite chaque listener comme une frontière entre deux vues de la topologie, et traduit les adresses qu'il renvoie par listener.

Concrètement : lorsqu'une requête arrive sur le listener interne, Zaris remplit la réponse de topologie (les adresses de nœuds qu'il renvoie dans les réponses de cluster et de redirection) avec des adresses internes. Lorsqu'une requête arrive sur le listener désigné pour les clients externes, il remplit cette même réponse avec l'adresse annoncée en externe de chaque nœud. Chaque réponse de topologie ou de redirection est réécrite pour correspondre à la frontière sur laquelle se trouve le client — on indique toujours à un client externe une adresse qu'il peut atteindre, et un client interne au cluster obtient toujours l'adresse interne, la plus rapide pour lui.

Comme cela se fait par listener, le cluster n'a pas à choisir entre être adressable en interne et adressable en externe — il est les deux à la fois, et chaque client obtient la vue correspondant à l'endroit par lequel il est entré.

Validé en conditions réelles : 200/200, des deux côtés à la fois​

Cela a été validé avec des clients externes et internes s'exécutant simultanément contre le même cluster : 200/200 opérations ont réussi depuis des clients externes et internes en même temps, avec une traduction d'adresse correcte par listener — les clients externes se sont connectés aux adresses annoncées en externe, les clients internes ont utilisé les adresses internes, et aucune des deux vues n'a fuité dans l'autre. Exécuter les deux en concurrence est le but : la frontière doit tenir dans les deux sens à la fois.

Le câblage Kubernetes qui reste à votre charge​

Zaris rend l'adressage correct — il fournit à chaque client une adresse qu'il peut atteindre. Rendre chaque nœud réellement atteignable depuis l'extérieur relève du réseau Kubernetes, et cela reste du travail d'opérateur. Deux éléments comptent.

Services par pod. Comme les clients externes conscients de la topologie ont besoin que chaque nœud soit atteignable indépendamment, vous exposez les nœuds individuellement — un Service par pod, chacun donnant à un nœud sa propre adresse atteignable de l'extérieur, qui est exactement l'adresse que ce nœud annonce sur son listener externe.

apiVersion: v1
kind: Service
metadata:
  name: zaris-0-ext
spec:
  type: LoadBalancer
  selector:
    statefulset.kubernetes.io/pod-name: zaris-0
  ports:
    - name: resp
      port: 6379
      targetPort: 6379

Chaque nœud se voit alors indiquer son adresse annoncée en externe :

kubectl set env statefulset/zaris \
  ZARIS_ADVERTISED_ADDRESS_EXTERNAL="10.0.0.10:6379"

# Confirm an external client is handed reachable, per-node addresses.
redis-cli -h 10.0.0.10 -p 6379 CLUSTER SLOTS

SAN TLS. Lorsque TLS est activé, un client valide le certificat contre le nom auquel il s'est connecté. Puisque les clients externes se connectent aux noms annoncés en externe, ces noms doivent figurer dans les Subject Alternative Names du certificat. Si un nœud annonce 10.0.0.10 (ou un nom comme redis.example.com) mais que son certificat ne couvre que zaris-0.zaris.svc, la poignée de main TLS externe échoue alors même que l'adresse est atteignable. La gestion de ces SAN relève du travail d'opérateur.

La frontière honnête​

La contribution de Zaris est précise : il rend l'adressage correct à travers la frontière cluster/monde extérieur, par listener, de sorte qu'aucun client ne reçoive jamais une adresse qu'il ne peut utiliser. Il ne provisionne pas vos répartiteurs de charge et n'émet pas vos certificats. Les Services par pod et la gestion des SAN TLS restent à votre charge.

C'est la bonne répartition du travail. La partie difficile et facile à rater — traduire chaque réponse de topologie et de redirection vers la vue correcte pour le client qui a demandé — est prise en charge pour vous. Une fois le réseau autour en place, clients externes et internes partagent un seul cluster sans se marcher dessus.