{
  "id": "database-connectivity",
  "title": "Database connectivity",
  "url": "https://redis.io/docs/latest/operate/kubernetes/8.0.18/networking/database-connectivity/",
  "summary": "Connect applications to Redis Enterprise databases in Kubernetes clusters with in-cluster and external access patterns.",
  "content": "\nConnecting applications to Redis Enterprise databases in Kubernetes involves understanding service discovery, credentials management, and access patterns. This guide covers the essential connectivity aspects unique to Kubernetes deployments.\n\n## Service types and access patterns\n\nWhen you create a RedisEnterpriseDatabase (REDB), the Redis Enterprise operator automatically creates Kubernetes services to route traffic to your database. Understanding these service types is crucial for proper connectivity.\n\n### Default service creation\n\nBy default, the operator creates two services for each database:\n\n- ClusterIP service - Provides a stable cluster-internal IP address.\n- Headless service - Enables direct pod-to-pod communication and service discovery.\n\nBoth services are created in the same namespace as your database and follow predictable naming conventions.\n\n### Service types\n\nRedis Enterprise supports three service types for database access:\n\n| Service Type | Rigger Spec Exact Name | Access Scope | Use Case |\n|--------------|--------------|--------------|----------|\n| `ClusterIP` | `cluster_ip` | Cluster-internal only | Applications running within the same Kubernetes cluster |\n| `headless` | `headless` | Cluster-internal only | Direct pod access, service discovery, StatefulSet scenarios |\n| `LoadBalancer` | `load_balancer` | External access | Applications outside the Kubernetes cluster |\n\nTo configure the service type, use the `databaseServiceType` field in your REC's `servicesRiggerSpec`.\n\nFor example, to enable the three Service options, you may use:\n```\n  {\"spec\":{\"servicesRiggerSpec\":{\"databaseServiceType\":\"cluster_ip,headless,load_balancer\"}}}\n```\n\n## In-cluster database access\n\nFor applications running within your Kubernetes cluster, use the automatically created services to connect to your databases.\n\n### Retrieve connection information\n\nDatabase connection details are stored in a Kubernetes secret maintained by the database controller. This secret contains:\n\n- Database port (`port`)\n- Service names (`service_names`) \n- Database password (`password`)\n\n1. Get the secret name from your database resource:\n\n   ```sh\n   kubectl get redb \u003cdatabase-name\u003e -o jsonpath=\"{.spec.databaseSecretName}\"\n   ```\n\n   The secret name typically follows the pattern `redb-\u003cdatabase-name\u003e`.\n\n2. Retrieve the database port:\n\n   ```sh\n   kubectl get secret redb-\u003cdatabase-name\u003e -o jsonpath=\"{.data.port}\" | base64 --decode\n   ```\n\n3. Get available service names:\n\n   ```sh\n   kubectl get secret redb-\u003cdatabase-name\u003e -o jsonpath=\"{.data.service_names}\" | base64 --decode\n   ```\n\n4. Retrieve the database password:\n\n   ```sh\n   kubectl get secret redb-\u003cdatabase-name\u003e -o jsonpath=\"{.data.password}\" | base64 --decode\n   ```\n\n### Service naming and DNS resolution\n\nServices follow standard Kubernetes DNS naming conventions:\n\n- Service FQDN: `\u003cservice-name\u003e.\u003cnamespace\u003e.svc.cluster.local`\n- Short name: `\u003cservice-name\u003e` (within the same namespace)\n\nFor a database named `mydb` in namespace `production`, the service names would be:\n- ClusterIP service: `mydb.production.svc.cluster.local`\n- Headless service: `mydb-headless.production.svc.cluster.local`\n\n### Connect from within the cluster\n\nUse any service name from the `service_names` list to connect:\n\n```sh\nredis-cli -h \u003cservice-name\u003e -p \u003cport\u003e\n```\n\nThen authenticate with the retrieved password:\n\n```sh\nauth \u003cpassword\u003e\n```\n\n## External database access\n\nTo access databases from outside the Kubernetes cluster, you need to configure external routing. Currently supported methods for external access are ingress controllers or OpenShift routes.\n\n### Ingress controllers\n\nRedis Enterprise for Kubernetes only supports the following ingress controllers for external database access:\n\n- NGINX Ingress - Supports SSL passthrough for Redis connections\n- HAProxy Ingress - Built-in SSL passthrough support  \n- Istio Gateway - Service mesh integration with advanced traffic management\n\nSee [Ingress routing](https://redis.io/docs/latest/operate/kubernetes/networking/ingress) for detailed configuration steps.\n\n### OpenShift routes\n\nOpenShift users can leverage routes for external access:\n\n```yaml\napiVersion: route.openshift.io/v1\nkind: Route\nmetadata:\n  name: redis-route\nspec:\n  to:\n    kind: Service\n    name: \u003cdatabase-service-name\u003e\n  port:\n    targetPort: redis\n  tls:\n    termination: passthrough\n```\n\nSee [OpenShift routes](https://redis.io/docs/latest/operate/kubernetes/networking/routes) for complete setup instructions.\n\n## Service ports and configuration\n\n### Default port behavior\n\n- Redis Enterprise databases use dynamic port allocation.\n- Port numbers are assigned automatically during database creation.\n- The actual port is stored in the database secret.\n\n### Custom port configuration\n\nYou can specify custom ports using the `databasePort` field in your REDB specification:\n\n```yaml\napiVersion: app.redislabs.com/v1alpha1\nkind: RedisEnterpriseDatabase\nmetadata:\n  name: mydb\nspec:\n  memorySize: 256MB\n  databasePort: 6379\n```\n\nCustom ports replace the default service port and are reflected in the database secret.\n\n## Credentials and secrets management\n\n### Database secrets structure\n\nEach database has an associated Kubernetes secret containing connection details:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redb-\u003cdatabase-name\u003e\ntype: Opaque\ndata:\n  port: \u003cbase64-encoded-port\u003e\n  service_names: \u003cbase64-encoded-service-list\u003e\n  password: \u003cbase64-encoded-password\u003e\n```\n\n### Using secrets in applications\n\nReference database secrets in your application deployments:\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: my-app\nspec:\n  template:\n    spec:\n      containers:\n      - name: app\n        image: my-app:latest\n        env:\n        - name: REDIS_HOST\n          value: \"\u003cservice-name\u003e\"\n        - name: REDIS_PORT\n          valueFrom:\n            secretKeyRef:\n              name: redb-\u003cdatabase-name\u003e\n              key: port\n        - name: REDIS_PASSWORD\n          valueFrom:\n            secretKeyRef:\n              name: redb-\u003cdatabase-name\u003e\n              key: password\n```\n\n### Default user configuration\n\nBy default, databases create a default user with full access. You can disable this behavior:\n\n```yaml\napiVersion: app.redislabs.com/v1alpha1\nkind: RedisEnterpriseDatabase\nmetadata:\n  name: mydb\nspec:\n  memorySize: 256MB\n  defaultUser: false\n```\n\nWhen `defaultUser` is disabled, the database secret is not created, and you must configure custom authentication.\n\n## Connection examples\n\n### Python application\n\n```python\nimport redis\nimport base64\nimport os\n\n# Read from Kubernetes secret (mounted as environment variables)\nhost = os.getenv('REDIS_HOST')\nport = int(os.getenv('REDIS_PORT'))\npassword = os.getenv('REDIS_PASSWORD')\n\n# Create Redis connection\nr = redis.Redis(host=host, port=port, password=password, decode_responses=True)\n\n# Test connection\nr.ping()\n```\n\n### Node.js application\n\n```javascript\nconst redis = require('redis');\n\nconst client = redis.createClient({\n  host: process.env.REDIS_HOST,\n  port: process.env.REDIS_PORT,\n  password: process.env.REDIS_PASSWORD\n});\n\nclient.on('connect', () =\u003e {\n  console.log('Connected to Redis');\n});\n```\n\n## Troubleshooting connectivity\n\n### Common issues\n\n1. Connection refused - Verify service names and ports from the database secret.\n2. Authentication failed - Check password encoding and special characters.\n3. DNS resolution - Ensure applications use correct service FQDNs.\n4. Network policies - Verify Kubernetes network policies allow traffic.\n\n### Debugging steps\n\n1. Verify service creation:\n   ```sh\n   kubectl get services -l app=redis-enterprise\n   ```\n\n2. Check service endpoints:\n   ```sh\n   kubectl get endpoints \u003cservice-name\u003e\n   ```\n\n3. Test connectivity from within cluster:\n   ```sh\n   kubectl run redis-test --image=redis:latest -it --rm -- redis-cli -h \u003cservice-name\u003e -p \u003cport\u003e\n   ```\n\n## Related topics\n\n- [Ingress routing](https://redis.io/docs/latest/operate/kubernetes/networking/ingress) - Configure external access with ingress controllers\n- [OpenShift routes](https://redis.io/docs/latest/operate/kubernetes/networking/routes) - External access using OpenShift routes  \n- [Database controller](https://redis.io/docs/latest/operate/kubernetes/re-databases/db-controller) - Database lifecycle management\n- [Security](https://redis.io/docs/latest/operate/kubernetes/security) - TLS configuration and access control\n",
  "tags": ["docs","operate","kubernetes"],
  "last_updated": "2026-06-04T14:49:57+01:00"
}