I am trying to create a ServiceEntry for an external Redis Cache over TLS. The idea is to identify those external hosts, without following the “TLS Origination” way.
We have Istio v1.18.0 installed, a few pods and external Redis Caches on Azure. The goal is to have a ServiceEntry for each Redis instance and visualize/produce metrics for each one of them.
I created a ServiceEntry as per below:
apiVersion: networking.istio.io/v1beta1 kind: ServiceEntry metadata: name: redis1 spec: location: MESH_EXTERNAL resolution: DNS hosts: - redis-1.redis.cache.windows.net ports: - name: tcp-redis number: 6380 protocol: tcp
At first it looked fine and pod1 was able connect to redis1 as expected. But then I realised that pod2 couldn’t connect to its own redis (redis2) due to wrong credentials.
Observing pod2 istio-proxy logs in debug mode, I noticed that every time I was testing pod2, the istio-proxy was trying to resolve redis1 FQDN instead of redis2.
So at that point my assumption was that the ServiceEntry for redis1 worked pretty much like a “catch all” one.
Then I modified the ServiceEntry in several ways, but it failed to behave properly.
Finally I changed the ServiceEntry
.spec.ports.protocol from TCP to TLS and this change seem to be the right one.
Could anyone validate that using TLS protocol in a redis specification is fine?
I tried to find examples and official documentation, but I couldn’t find such implementation.