Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

With External Access & external-dns enabled, internal clients should be able to connect to segment store without external DNS resolution #252

Open
pbelgundi opened this issue Aug 21, 2019 · 1 comment
Assignees
Labels
kind/enhancement Enhancement of an existing feature priority/P3 No direct impact to applications, e.g., typos in documentation or log messages status/needs-investigation Further investigation is required

Comments

@pbelgundi
Copy link
Contributor

Description

When we setup Pravega with External Access and external-dns enabled, segment stores advertise external-dns endpoint to clients. As such, internal pravega clients (in the same K8s cluster as pravega deployment) also get routed via external-dns resolution, when connecting to segment store instances. See related issue #3899. This needs to be avoided so internal clients can directly connect to SegmentStore without going through the external dns resolution.

Importance

Should-have: Optimize access from internal clients

Suggestions for an improvement

One way to implement this can be to have the same dns entry as in external dns server inside kubernetes internal dns server (coredns).

@pbelgundi pbelgundi changed the title With External Access & external-dns enabled operator should route k8s internal clients internally With External Access & external-dns enabled, internal clients should be able to connect to segment store without external DNS resolution Aug 21, 2019
@EronWright
Copy link
Contributor

EronWright commented Aug 22, 2019

@pbelgundi with the suggestion to use DNS to achieve the desired effect, one would need to be careful about SSL hostname verification.

My suggestion is to advertise numerous endpoints per segment store. For example, a given segment store could expose a set of labeled endpoints. The ZK data would resemble:

endpoints:
  segmentstore-1:
    internal: http://ip-172-31-18-160.us-west-2.compute.internal:80
    external: https://ec2-54-191-84-122.us-west-2.compute.amazonaws.com:443

I would suggest that the schema and port vary by endpoint.

On the client, one may use an explicit approach to configure which endpoint to use, e.g. ClientConfig.builder().listener("external"). And/or use a discovery approach where the client attempts to connect to each endpoint in turn.

@pbelgundi pbelgundi added kind/enhancement Enhancement of an existing feature priority/P3 No direct impact to applications, e.g., typos in documentation or log messages status/needs-investigation Further investigation is required labels May 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Enhancement of an existing feature priority/P3 No direct impact to applications, e.g., typos in documentation or log messages status/needs-investigation Further investigation is required
Projects
None yet
Development

No branches or pull requests

3 participants