3 articles tagués avec « Kubernetes »

Il existe un raisonnement tentant lorsqu'on déploie un store répliqué sur Kubernetes : j'ai défini replicationFactor: 2, donc chaque partition a une sauvegarde, donc je survis à la perte d'un nœud. Cela semble inattaquable. C'est aussi, pour une taille de cluster étonnamment courante, faux — et faux de la manière silencieuse qui ne se révèle que la première fois qu'un pod meurt réellement.

Zaris sur Kubernetes stocke les données en mémoire et les rend durables par réplication, pas par disque : le volume de données du nœud est un emptyDir, et un pod reprogrammé se reconstruit à partir de la copie détenue par un autre pod. Cette conception est saine — mais elle repose entièrement sur l'existence d'une copie sur un autre pod. Que cette copie existe n'est pas décidé par replicationFactor seul. C'est décidé par l'arithmétique entre votre nombre de pods et votre facteur de réplication, et si vous vous trompez dans cette arithmétique, le store tournera parfaitement, servira chaque lecture et écriture, et détiendra silencieusement une partition qui n'a nulle part où se répliquer.

Mettre un store distribué sur Kubernetes est facile. L'y mettre avec TLS activé, atteignable depuis l'extérieur du cluster, et un client qui se connecte réellement est là où la plupart des tutoriels s'arrêtent discrètement. Zaris fournit un chart Helm, et nous avons validé tout le chemin — y compris la configuration sécurisée et atteignable de l'extérieur — de bout en bout sur un cluster local.

Cet article est ce tutoriel. Nous l'exécutons sur kind (Kubernetes-in-Docker) afin que vous puissiez reproduire chaque étape sur un ordinateur portable, et nous prenons la route la plus difficile à dessein : TLS activé, certificats avec les bons subject alternative names, accès externe activé, et un client se connectant via le point d'accès sécurisé. Nous appelons cela la configuration Model B — atteignable de l'extérieur et sécurisée, par opposition à un cluster interne uniquement.

Une règle d'exactitude accroche presque chaque premier déploiement, et elle n'a rien à voir avec les certificats : le nom du store dans votre chaîne de connexion doit être égal au clusterId du déploiement. Nous signalerons exactement où cela mord. Tout le reste est identique sur un cluster de production — kind nous offre simplement un endroit propre et jetable pour le prouver.

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.