KubeBlocks Redis cluster shows tls: true but Redis still serves only plain TCP on 6379 (no TLS listener / no TLS port in Service/Endpoints)

[SyntaxJuggler]

Title: KubeBlocks Redis cluster shows tls: true but Redis still serves only plain TCP on 6379 (no TLS listener / no TLS port in Service/Endpoints)

Describe the bug
I run a Redis cluster managed by KubeBlocks (apps.kubeblocks.io/v1, ClusterDef redis, topology replication). In the Cluster spec, the redis component has tls: true and a UserProvided issuer with secretRef pointing to learnhub-redis-server-tls (keys: ca.crt, tls.crt, tls.key). The cluster reports phase: Running and Ready=True.
However, Redis is still accessible only via plain TCP on port 6379 (it returns NOAUTH on plain connections). Any attempt to connect using TLS to port 6379 hangs until timeout. There is also no separate TLS port exposed (e.g., 6380).
Kubernetes Service/Endpoints for the Redis component expose only port 6379, so TLS cannot be used from clients.

To Reproduce

1. Deploy a KubeBlocks Redis Cluster with:

   • spec.clusterDef: redis
   • spec.componentSpecs[].name: redis
   • spec.componentSpecs[].tls: true
   • spec.componentSpecs[].issuer.name: UserProvided
   • spec.componentSpecs[].issuer.secretRef pointing to a secret with ca.crt, tls.crt, tls.key

2. Verify the cluster becomes Ready=True / phase=Running.

3. Check Service/Endpoints:

   • kubectl -n <ns> get svc <redis-service>
   • kubectl -n <ns> get endpoints <redis-service> -o yaml
     → only port 6379 is present (no TLS port).

4. From a pod in the same namespace, test plain Redis:

   • redis-cli -h <redis-pod-fqdn> -p 6379 PING
     → returns (error) NOAUTH Authentication required. (expected for plain TCP + auth)

5. Test TLS on 6379:

   • redis-cli --tls --cacert <ca.crt> -h <redis-pod-fqdn> -p 6379 PING
     → hangs / times out (e.g., killed by timeout 5).

Expected behavior
When tls: true is set for the Redis component with a valid issuer.secretRef, Redis should actually enable TLS (either):

• serve TLS-only on port 6379, or
• expose a dedicated TLS port (commonly 6380) and publish it through Service/Endpoints.
  In both cases, clients should be able to connect via redis-cli --tls ... successfully.

Actual behavior

• Service/Endpoints expose only 6379.
• Port 6379 behaves as plain TCP (not TLS).
• TLS connection attempts to 6379 hang until timeout.
• No TLS port is available/exposed for clients.

Additional context

• KubeBlocks Cluster:

  • ClusterDef: redis
  • redis componentDef: redis-7-1.0.2
  • serviceVersion: 7.2.4
  • tls: true
  • issuer: UserProvided with secretRef learnhub-redis-server-tls (ca.crt, tls.crt, tls.key)

• Namespace: learnhub

• Endpoints show only:

  • learnhub-redis-redis-redis → port: 6379
  • learnhub-redis-redis-headless → ports: 3501, 9901, 6379, 3502

• Plain connection to 6379 returns NOAUTH, TLS connection to 6379 times out.

[wangyelei]

@SyntaxJuggler tls is not yet supported in redis 1.0.2. you can test it using the main branch from kubeblocks-addon

[shanshanying]

Hi @SyntaxJuggler

I will close the issue for now and should you encounter any issues relevant, feel free to reopen it.