Advice for IP based services

[Stono]

We have numerous applications which talked to clustered state stores by IP, not hostname - and this is a requirement of the data store rather than the client.

Redis is a prime example; take the following HA redis setup. In this example, the client is configured to talk to the sentinel nodes by their hostnames:

• sentinel1.redis-headless.namespace.svc.cluster.local
• sentinel2.redis-headless.namespace.svc.cluster.local
• sentinel3.redis-headless.namespace.svc.cluster.local

And that works fine (ish, bar the port problems with headless services), I can define a ServiceEntry for it. However, sentinel doesn't use hostnames, it maintains the cluster state by IP address and will return an array of the nodes, the client will then attempt to talk to the nodes on their ip and in turn get a 404 from envoy.

I have a couple of solutions at the moment, none of which I really like:

• Sit around and wait for managed redis to be available in my GCP region.
• Architect Redis with a service (perhaps haproxy) in front of it which handles this logic, and have apps connect to that service instead.
• Exclude these apps from Istio all together

Any ideas?

[rshriram]

Have you tried adding some service entries for these pod IPs?

Hosts: 
-redis-1.blah
Addresses: 
-10.x.x.1
resolution: none
ports:
- port: 2379
   protocol: TCP
   name: foo

Hosts: 
-redis-2.blah
Addresses: 
-10.x.x.2
resolution: none
ports:
- port: 2379
   protocol: TCP
   name: foo

and so on

[Stono]

No, because pod IPs are ephemeral 🤷

…

On Mon, 20 Aug 2018, 3:38 pm Shriram Rajagopalan, ***@***.***> wrote: Have you tried adding some service entries for these pod IPs? Hosts: -redis-1.blah Addresses: -10.x.x.1 resolution: none ports: - port: 2379 protocol: TCP name: foo Hosts: -redis-2.blah Addresses: -10.x.x.2 resolution: none ports: - port: 2379 protocol: TCP name: foo and so on — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#8057 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABavicFCjWZrbpXGpdier6wYWn2JkVeZks5uSsnTgaJpZM4WC4n_> .

[LinAnt]

Did you come up with a solution to this? I am facing the same issue with vault/etcd.

[Stono]

@LinAnt nope, it's basically unsupported. In the case of redis I ended up building a HAProxy LB in front of it and used the annotation traffic.sidecar.istio.io/includeOutboundIPRanges: "", to have envoy not intercept any outbound traffic. This only works when the app is not talking to any istio stuff upstream.

[Stono]

Associated: #9632

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[gsf]

We are considering as a stop gap creating a deployed service that will listen for updates from sentinel and update a ServiceEntry to match advertised IP addresses. Could that work?

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it has not had activity in the last month and a half. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.