Skip to content

Egress example unnecessarily convoluted? #1

Open
@Datamance

Description

@Datamance

The example in the book seems overly complicated and hacky compared to what's in the istio docs

The way specified by the docs is straightforward, if involved/possibly redundant:

  • set up a ServiceEntry for the external hostname
  • set up a(n Egress) Gateway exposing that same hostname
  • make a simple destination rule pointing to that gateway
  • have a VirtualService route traffic from sidecars (the mesh Gateway) to the Egress Gateway, and from the Egress Gateway to the external hostname.

The way that you guys have outlined in the book is honestly pretty byzantine in comparison:

  • make a ServiceEntry mapping the external hostname to istio-egressgateway as an endpoint
  • make a Gateway exposing the external hostname, which - as you note in the book! - sends requests in a loop
  • to fix this, have a VirtualService route traffic directed at the external hostname to an intermediate ("fake") hostname...
  • ... which is provided for by yet another ServiceEntry that maps that internal hostname back to the external one that we were trying to reach in the first place.

I'm not sure if you guys were trying to prove a point w.r.t. the power of VirtualServices and Gateways, but if that were the case you should have prefaced it with way more language (hopefully diacritic-heavy for emphasis) indicating that this is not necessarily the recommended way of doing egress.

If I'm missing something incredibly basic, please tell me - otherwise, I feel like this is dangerously misleading and discouraging for readers!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions