2 posts tagged with "Kubernetes"

Getting a distributed store onto Kubernetes is easy. Getting it there with TLS on, reachable from outside the cluster, and a client that actually connects is where most walkthroughs quietly stop. Zaris ships a Helm chart, and we've validated the whole path — including the secured, externally-reachable configuration — end to end on a local cluster.

This post is that walkthrough. We run it on kind (Kubernetes-in-Docker) so you can reproduce every step on a laptop, and we take the harder road on purpose: TLS enabled, certificates with the right subject alternative names, external access on, and a client connecting over the secured endpoint. We call this the Model B configuration — externally-reachable and secured, versus an internal-only cluster.

One correctness rule snags almost every first deploy, and it has nothing to do with certificates: the store name in your connection string must equal the deployment's clusterId. We'll flag exactly where that bites. Everything else is identical on a production cluster — kind just gives us a clean, disposable place to prove it.

Run Zaris in Kubernetes and the happy path is easy: in-cluster clients reach the pods by their internal addresses — pod IPs and cluster-DNS names like zaris-0.zaris.svc — and everything routes cleanly. The moment a client lives outside the cluster, that breaks. An external application cannot dial zaris-0.zaris.svc or a pod IP; those names and addresses only resolve and route inside the cluster network.

This is not a Zaris quirk — it is the fundamental split between the cluster's internal network and the outside world. It bites hardest with topology-aware clients. A cluster-mode Redis client, or any client that discovers nodes and routes per-key, fetches a topology map from the server and connects to the addresses in it. If those addresses are internal, an external client gets a map full of endpoints it can never reach.

Zaris solves this with advertised addresses, handled as a per-listener "boundary view."