Troubleshooting Redis Enterprise for Kubernetes Ingress Connectivity

Redis Enterprise for Kubernetes databases can be exposed through Kubernetes Ingress, OpenShift Routes, or other ingress technologies. When connections fail, the problem is typically related to DNS resolution, TLS passthrough configuration, TLS Server Name Indication (SNI), ingress routing, or backend Redis service connectivity.

Use the Quick Fix table to identify the most likely cause, then follow the step-by-step troubleshooting workflow to isolate where the connection is failing.

Quick Fix

Troubleshooting Workflow

Step 1: Verify DNS Resolution

Can the ingress hostname resolve to the load balancer?

dig testdb.apps.example.com

or

nslookup testdb.apps.example.com

Expected result:

• Hostname resolves to the ingress load balancer.

• If DNS does not resolve correctly, fix DNS before continuing.

Step 2: Verify the Database Has TLS Enabled

Check the REDB:

kubectl get redb <database-name> -o yaml

Verify:

spec:
  tlsMode: enabled

If TLS is disabled, ingress TLS passthrough will not work.

Step 3: Verify Ingress TLS Passthrough

Redis requires TLS passthrough because ingress controllers route Redis traffic using TLS SNI.

Verify the ingress configuration includes the appropriate passthrough annotations for your ingress controller.

Common examples:

nginx.ingress.kubernetes.io/ssl-passthrough: "true"

haproxy.org/ssl-passthrough: "true"

Step 4: Verify the Client Sends TLS SNI

The TLS SNI hostname must match the ingress hostname.

Example:

testdb.apps.example.com

Many connection issues occur because the client is connecting through the correct hostname but not sending SNI.

Review your client library documentation to verify SNI behavior.

Step 5: Test Redis Connectivity Through Ingress

Use redis-cli:

redis-cli \
-h testdb.apps.example.com \
-p 443 \
--tls \
--sni testdb.apps.example.com \
--insecure \
ping

Expected results:

Connectivity is working:

(error) NOAUTH Authentication required

or

PONG

Connectivity is not working:

Protocol error, got "H" as reply type byte

This usually indicates that TLS passthrough is not configured correctly, but it can also occur if the ingress hostname is wrong or the ingress resource is deleted/missing. Verify that the ingress exists with the correct hostname with kubectl get ingress. If the ingress exists with the correct hostname, it is likely a TLS passthrough issue.

Step 6: Test with OpenSSL

If redis-cli is unavailable:

openssl s_client \
-connect testdb.apps.example.com:443 \
-servername testdb.apps.example.com

Expected result:

The Redis cluster certificate is returned.

If no certificate is returned or the default ingress controller certificate is returned, focus on DNS, ingress routing, and TLS passthrough configuration.

Step 7: Bypass the Ingress

If connectivity still fails, determine whether the problem is in Redis or in the ingress path.

Create a port-forward:

kubectl port-forward svc/testdb 16441:16441

Then test:

redis-cli \
-h localhost \
-p 16441 \
--tls \
--insecure \
ping

Expected result:

(error) NOAUTH Authentication required

or

PONG

If this works, Redis is healthy and the issue is likely in the load balancer, DNS, or ingress configuration.

Common Root Causes

DNS Does Not Resolve Correctly

The ingress hostname must resolve to the ingress load balancer. Many environments use wildcard DNS records such as:

*.apps.example.com

If wildcard DNS is not allowed, create individual DNS records for each ingress hostname.

TLS Passthrough Is Missing

Redis traffic requires TCP passthrough. If the ingress controller terminates TLS or treats the request as standard HTTPS traffic, Redis connections will fail.

TLS SNI Is Missing

Ingress controllers use TLS SNI to determine which Redis service should receive traffic. If the client does not send SNI, routing cannot occur correctly.

Database TLS Is Disabled

Ingress passthrough requires:

spec:
  tlsMode: enabled

on the REDB.

Advanced Troubleshooting

Review Ingress Controller Logs

kubectl logs <ingress-controller-pod>

Look for:

• TLS passthrough errors

• Backend routing failures

• Ingress reconciliation errors

Capture Network Traffic

When deeper investigation is required, inject a temporary debugging container into the ingress controller and run tcpdump.

kubectl debug -it pod/<ingress-controller-pod> \
--image=nicolaka/netshoot \
--profile=sysadmin

Then:

tcpdump -i eth0 -vvv

Packet captures can help determine whether traffic reaches the ingress controller and can be shared with network teams for additional analysis.