Skip to main content

​
Default: cluster-internal access only

Every FalkorDB deployment gets a standard Kubernetes Service and a matching DNS name from the cluster’s CoreDNS, for example:
That name resolves only inside the Kubernetes cluster. Any pod in the same cluster can connect to it; nothing outside the cluster — a different cluster, a VM tier, a peered VPC, the public internet — can resolve or reach it.
Without any of the setup below, the only way to reach a database from outside the cluster is to connect directly to a pod IP, and only if your CNI allocates pod IPs from a routable address space (for example the AWS VPC CNI on EKS, Azure CNI on AKS, or GKE’s VPC-native mode). Overlay networks (kubenet, Flannel VXLAN, Calico IPIP/VXLAN) never make pod IPs reachable from outside the cluster.

​
Making a deployment reachable from outside the cluster

Two independent things both have to be true:
1

Give the deployment an externally resolvable name

In the create or edit wizard, open the Networking step and set the external domain (FQDN) field — for example db.internal.example.com. This sets spec.externalDomain on the cluster, which makes the admin server:
  • Set ANNOUNCE_HOSTNAME_OVERRIDE=$(CURRENT_POD_NAME).<zone> on the FalkorDB (and Sentinel, if enabled) pods, so each pod announces its own external name instead of its in-cluster address. Depending on topology this becomes replica-announce-ip, sentinel announce-ip, or cluster-announce-hostname — see External DNS access for how each topology announces itself.
  • Create a dedicated headless Service per component (clusterIP: None, publishNotReadyAddresses: true), annotated with external-dns.alpha.kubernetes.io/hostname so its endpoints — the pod IPs — get published under that name.
This step alone does not create any DNS records. It only makes the deployment announce a name and expose the Service annotations a DNS controller needs to act on.
2

Publish DNS records for that name

Something has to turn the annotated Service into actual DNS records that resolve to the current pod IPs — ExternalDNS is the recommended and directly supported option, watching the annotated headless Services and publishing records to a private or public DNS zone (Route 53, Cloud DNS, Azure DNS, and other supported providers). Without a controller doing this, the announced name has nothing backing it and will not resolve.
See External DNS access for installing ExternalDNS, the full per-component DNS layout, pod-IP routability requirements per platform, and a CoreDNS-forwarding alternative for clusters that do not want to run ExternalDNS.

​
Other ways to expose a database

The Networking step also supports adding a plain ClusterIP, NodePort, or LoadBalancer Service per component, independent of the external-domain feature above. Use this when you want a conventional load-balanced entry point (one virtual IP in front of all replicas) rather than stable per-pod names — for example a LoadBalancer Service for a standalone database reachable from the internet, or a NodePort for quick access during development. See the Networking step in Standalone, Replicated, Sentinel, and Sharded for per-topology notes.