Outbound traffic for a metadata recovery service

[Yannig]

Describe the bug

We deploy our application in Istio and among one of our services, we have a metadata consultation mechanism. This service is used to retrieve information on links that will serve as a resource document.

The problem with this service is that by definition, we are unable to predict in advance which sites will be consulted.

Unfortunately, as I went through the documentation, I did not see any example describing this type of need. To work around the problem I excluded this service with the help of an annotation so that it does not have a side car Istio (using sidecar.istio.io/inject: "false").

My question is whether this is the right solution and if it is not the case, what would be the good one.

Expected behavior

Have a way to let a service communicate outside of the mesh.

Steps to reproduce the bug

Well, this is not a bug but more a question/advice.

Version

Istio version : 1.0.6

Kubernetes :

Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.4", GitCommit:"c27b913fddd1a6c480c229191a087698aa92f0b1", GitTreeState:"clean", BuildDate:"2019-02-28T13:37:52Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.5", GitCommit:"51dd616cdd25d6ee22c83a858773b607328a18ec", GitTreeState:"clean", BuildDate:"2019-01-16T18:14:49Z", GoVersion:"go1.10.7", Compiler:"gc", Platform:"linux/amd64"}

Installation

Installed using helm with following options:

global:
  nodePort: false
  policyCheckFailOpen: true
  defaultResources:
    requests:
      cpu: 100m
    limits:
      cpu: 1000m

  proxy:
    resources:
      requests:
        cpu: 100m
      limits:
        cpu: 200m

ingress:
  enabled: false

kiali:
  enabled: true
  ingress:
    enabled: true
    # Used to create an Ingress record.
    hosts:
      - "kiali.{{ hosted_zone }}"
    annotations:
      # kubernetes.io/ingress.class: nginx
      # kubernetes.io/tls-acme: "true"
    tls:
      - hosts: ["kiali.{{ hosted_zone }}"]
  dashboard:
    jaegerURL: https://jaeger.{{ hosted_zone }}

prometheus:
  enabled: true
  resources:
    limits:
      cpu: 500m
      memory: 2048Mi
    request:
      cpu: 200m
      memory: 1500Mi

pilot:
  traceSampling: 0.0
  resources:
    limits:
      cpu: 2000m
      memory: 4096Mi
    request:
      cpu: 500m
      memory: 2048Mi

sidecarInjectorWebhook:
  enabled: true
  enableNamespacesByDefault: false

grafana:
  enabled: true

tracing:
  enabled: true
  jaeger:
    ingress:
      enabled: true
      # Used to create an Ingress record.
      hosts:
        - "jaeger.{{ hosted_zone }}"
      annotations:
        # kubernetes.io/ingress.class: nginx
        # kubernetes.io/tls-acme: "true"
      tls:
        - hosts: ["jaeger.{{ hosted_zone }}"]

servicegraph:
  enabled: true

galley:
  enabled: true

gateways:
  istio-ingressgateway:
    type: NodePort
    enabled: false

  istio-egressgateway:
    enabled: false

  istio-ilbgateway:
    type: NodePort
    enabled: true
    ports:
      - port: 80
        name: http2
      - port: 443
        name: https

Environment

Cloud: AWS
Cluster installed using kops

Cluster state
istio-dump.tar.gz

[frankbu]

Note that in Istio 1.1 you don't need to remove the sidecar from the service anymore. It will be able to access the external services without Service entries now.

https://istio.io/docs/tasks/traffic-management/egress/#envoy-passthrough-to-external-services

That said, you will still need to add service entries for any service that you want to control/monitor with Istio.

[Yannig]

I can confirme. With Istio 1.1, I was able to use my metadata service scrapper inside the service mesh.