FR: Generate config to use egress proxies (for mesh-to-mesh and general egress)

[ZackButcher]

If you're going to route to an external name, you need a combination of service entries and gateway config to route the external name to an egress gateway then out to the final destination. It's tedious to set up but easy to automate. We should add this as a subcommand, e.g. cw external-service https://wikipedia.org, which would spit out the required config.

I'll post example config setup for wikipedia.org shortly.

[mt-inside]

Good idea! I already have a TODO item to route mesh-mesh through an egress gateway (for limited connectivity scenarios, retries, etc), but yes also automating external service config would be great.

[ZackButcher]

# Route traffic for wikipedia.org in the cluster to the istio-egressgateway service
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: https-wikipedia-org
spec:
  hosts:
  - wikipedia.org
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS
  endpoints:
  - address: istio-egressgateway.istio-system.svc.cluster.local
    ports:
      http: 443
---
# Define an egress gateway for wikipedia.org which targets the istio-egressgateway;
# this configures the egress proxy to accept traffic for wikipedia.org (and 
# the VirtualService below routes that traffic).
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: https-wikipedia-org-egress
spec:
  selector:
    istio: egressgateway
  servers:
  - port:
      number: 443
      name: https-wikipedia-org-egress-443
      protocol: TLS # Mark as TLS as we are passing HTTPS through.
    hosts:
    - wikipedia.org
    tls:
      mode: PASSTHROUGH
---
# Routes wikipedia.org to a fake destination egress-wikipedia-org at
# istio-egressgateway only (because it binds to the Gateway we created for
# wikipedia.org).
#
# We use a fake destination because we already have a ServiceEntry for
# wikipedia.org, which routes that host to the egress proxy. We'd be stuck
# in a loop if we didn't rewrite the destination for the egress proxy itself.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: egress-wikipedia-org
spec:
  hosts:
  - wikipedia.org
  gateways:
  - https-wikipedia-org-egress
  tls:
  - match:
    - ports: 443
      sniHosts:
      - wikipedia.org
    route:
    - destination:
        host: egress-wikipedia-org
---
# Create a "fake" ServiceEntry for the egress proxy to use which resolves the
# fake destination into wikipedia.org using DNS - i.e. this ServiceEntry
# allows the egress proxy to resolve wikipedia.org and forward requests to it.
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: egress-https-wikipedia-org
spec:
  hosts:
  - egress-wikipedia-org
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS
  endpoints:
  - address: wikipedia.org
    ports:
      http: 443

[mt-inside]

This seems very complicated for just getting traffic to the internet on a common protocol.
Is this API going to be rationalised soon, or is it worth supporting?

[ZackButcher]

We are working on simplifying the config for this, the fact that it's complicated today is why I want to put it into the tool :). A lot of the things I want to add in the near future is this kind of "recipe" - simple end-user visible task that takes complex config today. Part of the goal is to see what the minimum required info to produce this stuff is to start to feel out what a better API for this stuff will look like.

[mt-inside]

The latest docs make this look marginally simpler @ZackButcher . Is this the same functionality or worse? https://istio.io/docs/tasks/traffic-management/egress/