3 publicaciones etiquetados con "Kubernetes"

Hay una línea de razonamiento tentadora cuando despliegas un almacén replicado en Kubernetes: fijé replicationFactor: 2, así que cada partición tiene un backup, así que sobrevivo a la pérdida de un nodo. Suena hermético. También es, para un tamaño de clúster sorprendentemente común, incorrecto — e incorrecto de la forma silenciosa que solo aparece la primera vez que un pod realmente muere.

Zaris en Kubernetes almacena la data en memoria y la hace durable por replicación, no por disco: el volumen de data del nodo es un emptyDir, y un pod reprogramado reconstruye a partir de la copia que tiene otro pod. Ese diseño es sólido — pero se apoya enteramente en que haya una copia en otro pod. Que esa copia exista no lo decide replicationFactor por sí solo. Lo decide la aritmética entre tu número de pods y tu factor de replicación, y si te equivocas en esa aritmética el almacén correrá perfectamente, servirá cada lectura y escritura, y en silencio sostendrá una partición que no tiene a dónde replicarse.

Llevar un almacén distribuido a Kubernetes es fácil. Llevarlo ahí con TLS activado, alcanzable desde fuera del clúster, y un cliente que realmente se conecta es donde la mayoría de los recorridos se detienen silenciosamente. Zaris incluye un chart de Helm, y hemos validado todo el camino — incluida la configuración asegurada y alcanzable externamente — de extremo a extremo en un clúster local.

Este post es ese recorrido. Lo ejecutamos en kind (Kubernetes-in-Docker) para que puedas reproducir cada paso en una laptop, y tomamos el camino más difícil a propósito: TLS habilitado, certificados con los subject alternative names correctos, acceso externo activado, y un cliente conectándose por el endpoint asegurado. A esto lo llamamos la configuración Model B — alcanzable externamente y asegurada, frente a un clúster solo interno.

Una regla de corrección hace tropezar a casi todos los primeros despliegues, y no tiene nada que ver con los certificados: el nombre del almacén en tu connection string debe ser igual al clusterId del despliegue. Señalaremos exactamente dónde muerde eso. Todo lo demás es idéntico en un clúster de producción — kind solo nos da un lugar limpio y desechable para demostrarlo.

Ejecuta Zaris en Kubernetes y el camino feliz es sencillo: los clientes dentro del clúster alcanzan los pods por sus direcciones internas — IPs de pod y nombres de DNS del clúster como zaris-0.zaris.svc — y todo se enruta limpiamente. En el momento en que un cliente vive fuera del clúster, eso se rompe. Una aplicación externa no puede marcar zaris-0.zaris.svc ni una IP de pod; esos nombres y direcciones solo resuelven y enrutan dentro de la red del clúster.

Esto no es una rareza de Zaris — es la división fundamental entre la red interna del clúster y el mundo exterior. Muerde con más fuerza a los clientes conscientes de la topología. Un cliente Redis en modo cluster, o cualquier cliente que descubre nodos y enruta por clave, obtiene un mapa de topología del servidor y se conecta a las direcciones que contiene. Si esas direcciones son internas, un cliente externo recibe un mapa lleno de endpoints que nunca podrá alcanzar.

Zaris resuelve esto con direcciones anunciadas, gestionadas como una "vista de frontera" por listener.