Saltar al contenido principal

Desplegar Zaris en Kubernetes con Helm: un recorrido seguro de extremo a extremo

· 8 min de lectura
Clustron Team
Clustron Team
Ingeniería de Sistemas Distribuidos

Desplegar Zaris en Kubernetes con Helm, asegurado de extremo a extremo

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.

Qué significa "seguro" aquí​

Un despliegue de Zaris son varios nodos más un manager, cada uno alcanzable en un nombre de DNS estable. Activar la seguridad significa que tres cosas se alinean a la vez:

  1. TLS está habilitado en los listeners del nodo y del manager.
  2. Los certificados llevan los SANs correctos — cada nombre que un cliente pueda usar para alcanzar un nodo debe aparecer en el certificado de ese nodo, o la verificación TLS falla.
  3. El acceso externo está configurado para que un cliente fuera del clúster alcance los nodos en un nombre que también esté en el certificado.

El requisito de SAN es el sutil. Un cliente que verifica comprueba el certificado contra el nombre que marcó, de modo que un certificado de un solo SAN que cubra únicamente zaris-0 no validará cuando un cliente se conecte a través de un nombre externo como zaris.example.com. Por eso el camino asegurado usa certificados multi-SAN — un certificado válido para el nombre de servicio dentro del clúster, el nombre por pod y el nombre externo.

Zaris proporciona generación de certificados y herramientas de ejemplo para que este paso sea reproducible en lugar de una maratón artesanal de openssl. Aún puedes hacerlo a mano — la forma está más abajo — pero las herramientas mantienen el conjunto de SANs correcto en todo momento.

Paso 1: un clúster kind​

kind create cluster --name zaris-secure
kubectl cluster-info --context kind-zaris-secure
kubectl create namespace zaris

Ese es todo el sustrato. En un clúster real te saltarías esto y apuntarías kubectl a tu plano de control gestionado; nada aguas abajo cambia.

Paso 2: generar certificados multi-SAN​

Los certificados deben cubrir cada nombre que usará un cliente o un peer: el nombre de servicio dentro del clúster, el nombre estable por pod, y un nombre externo que expondremos. Las herramientas de certificados de Zaris generan una CA y certificados de nodo con exactamente este conjunto de SANs; aquí está la forma equivalente estilo openssl para que veas lo que se está pidiendo:

# 1. A CA the client will trust
openssl req -x509 -newkey rsa:4096 -nodes -days 365 \
  -keyout ca.key -out ca.crt \
  -subj "/CN=Zaris Dev CA"

# 2. A node certificate whose SANs cover EVERY name used to reach it
openssl req -newkey rsa:2048 -nodes \
  -keyout zaris-node.key -out zaris-node.csr \
  -subj "/CN=zaris"

cat > san.cnf <<'EOF'
subjectAltName = @alt
[alt]
DNS.1 = zaris-0.zaris.svc            # per-pod stable name
DNS.2 = zaris.zaris.svc              # in-cluster service name
DNS.3 = zaris.example.com            # external name clients dial
EOF

openssl x509 -req -in zaris-node.csr \
  -CA ca.crt -CAkey ca.key -CAcreateserial \
  -extfile san.cnf -days 365 -out zaris-node.crt

Carga la CA y el par clave/cert del nodo en el namespace como secrets que el chart pueda montar:

kubectl -n zaris create secret generic zaris-ca \
  --from-file=ca.crt=ca.crt

kubectl -n zaris create secret tls zaris-node-tls \
  --cert=zaris-node.crt --key=zaris-node.key

La regla a recordar: si un nombre no está en subjectAltName, un cliente que verifica y marca ese nombre rechaza la conexión. Acierta con la lista de SANs y TLS simplemente funciona; falla y perseguirás un fallo de handshake que parece un problema de red pero no lo es.

Paso 3: el archivo de values (TLS + acceso externo)​

Aquí tienes un boceto de values.yaml para Model B — seguridad activada, acceso externo activado, y los secrets de certificado del paso 2 cableados:

# values.yaml — Model B: secured + externally reachable
clusterId: zaris          # <-- remember this value for the connection string

replicaCount: 3

tls:
  enabled: true
  # CA clients must trust, and the node key/cert pair
  caSecret: zaris-ca
  certSecret: zaris-node-tls

external:
  enabled: true
  # the name clients outside the cluster will dial —
  # must also be a SAN on the node certificate
  advertisedHost: zaris.example.com

manager:
  tls:
    enabled: true
    caSecret: zaris-ca
    certSecret: zaris-node-tls

Dos campos cargan con el peso. tls.enabled: true activa los listeners asegurados y monta los certificados. external.enabled: true con un advertisedHost hace que los nodos sean alcanzables desde fuera — y advertisedHost es el mismo zaris.example.com que pusimos en los SANs del certificado. Esos dos deben coincidir. Vigila también clusterId: aquí es zaris, y lo necesitarás textualmente en un momento.

Paso 4: helm install​

helm install zaris oci://registry-1.docker.io/clustron/zaris \
  --version 2.0.0 \
  -n zaris \
  -f values.yaml

# watch the nodes come up
kubectl -n zaris rollout status statefulset/zaris
kubectl -n zaris get pods

Cuando los pods estén listos tendrás un clúster de Zaris de tres nodos, con TLS habilitado y con un endpoint externo. En kind, alcánzalo con un port-forward; en un clúster real un Service de tipo LoadBalancer o un ingress toma el relevo.

kubectl -n zaris port-forward svc/zaris 7000:7000

Paso 5: conectar un cliente — y la regla del clusterId​

Ahora la parte que hace tropezar a los primeros despliegues. Una connection string de Zaris nombra el almacén al que te conectas, y contra un despliegue de Helm ese nombre de almacén debe ser igual al clusterId del despliegue. Fijamos clusterId: zaris en values.yaml, así que el nombre del almacén en la connection string es zaris — no my-store, no el nombre del release, no el nombre del Service. El clusterId.

// The store segment MUST match values.yaml clusterId ("zaris").
// zariss:// selects TLS; ?ca= points at the CA we generated.
var connectionString =
    "zariss://zaris.example.com:7000/zaris?ca=file:./ca.crt";

await using var client = await ZarisClient.ConnectAsync(connectionString);
await client.PutAsync("greeting", "hello from a secured cluster");
var value = await client.GetAsync("greeting");

Si el nombre del almacén y el clusterId no concuerdan, la conexión falla — y el error puede leerse como un problema de autenticación o de enrutamiento en lugar de uno de nomenclatura. Cuando un despliegue de Helm asegurado se niega a conectar y los certificados están en orden, esto es lo primero que hay que verificar: nombre de almacén de la connection string == clusterId. Es el fallo de primer despliegue más común que vemos.

Fíjate en el esquema: zariss:// (con la s extra) selecciona el endpoint asegurado, y ?ca=file:./ca.crt le dice al cliente en qué CA confiar — la que acuñamos en el paso 2. El host es el nombre externo, por eso tuvo que ser un SAN.

De kind a producción​

Dos cosas difieren en un clúster real: el acceso externo pasa a ser un Service de tipo LoadBalancer o un ingress con DNS real en lugar de un kubectl port-forward, y los certificados provienen de tu propia CA o de un issuer como cert-manager en lugar de una CA de desarrollo. Lo que no cambia es la parte importante — la regla de SAN (cada nombre que un cliente marque debe estar en el certificado) y la regla de la connection string (nombre del almacén igual a clusterId). Estás cambiando un port-forward por un LoadBalancer y una CA de desarrollo por una real, no rearquitecturando el despliegue.

Adónde ir después​

Ese es un clúster de Zaris asegurado de extremo a extremo: instalado con Helm, TLS activado, certificados multi-SAN, acceso externo, y un cliente conectado por el endpoint cifrado. Para profundizar en el modelo de confianza — Zaris admite múltiples modos de CA para que no tengas que pelearte con la PKI de tu organización — lee Confianza TLS enchufable. Para la referencia completa del chart y los patrones de red de producción, consulta la guía de despliegue en Kubernetes.