Proxies never get ready


Hello, I am trying to get Istio (built locally from master branch) running on Openshift 3.10. I have resolved all the child diseases, allowing the containers run privileged, but when I’ve deployed a basic routing rules the sidecar never gets ready. I’ve added just one gateway, one virtualservice and one destination rule (see below).

The istio-proxy never becomes ready, and in the log I can see:

2019-01-28T15:48:26.261191Z     info    Envoy proxy is NOT ready: 3 errors occurred:

* failed checking application ports. listeners="","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","[fe80::78d9:56ff:fed5:739d]:3333","[fe80::78d9:56ff:fed5:739d]:9999","",""
* envoy missing listener for inbound application port: 0
* envoy missing listener for inbound application port: 8080

I would expect that the application port matching works on which is in the list above. I am also not sure how exactly is the list above generated, but when I exec into the node, the ifconfig gives me different address than one from the list above (those are service IPs, not node IPs):

There’s one more thing that caught my eye: in the envoy log I can see this warning:

[2019-01-28 13:15:17.816][000019][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_mux_subscription_lib/common/config/grpc_mux_subscription_impl.h:70] gRPC config for rejected: cluster: cluster type 'original_dst' may only be used with LB type 'original_dst_lb'

Running neither sidecar with --proxyLogLevel debug neither the pilot with --log_output_level default:debug gave me any further details, though.

The config follows below:

kind: Gateway
  name: app-gateway
  namespace: istio-scale
    istio: ingressgateway
  - hosts:
    - '*'
      name: http
      number: 80
      protocol: HTTP
kind: VirtualService
  name: versionbased
  namespace: istio-scale
  - app-gateway
  - '*'
  - match:
        prefix: app-1/
      uri: /
    - destination:
        host: app
          number: 8080
        subset: app-1
# repeats couple more times for app-2, app-3....
kind: DestinationRule
    name: app-subsets
    namespace: istio-scale
  host: '*'
  - labels:
      deploymentconfig: app-1
    name: app-1
# repeats for app-2, app-3...
      simple: RANDOM


I found what was my issue - I had wrong selector on service and therefore no endpoints were created (I have messed this when reconfiguring the cluster). After fixing the labels the service got bound to the nodes and the proxy got its IP:port in listeners list, and could come up.

Right now I am trying to figure out why the ingressgateway is not routing the request properly but returning 404. I’ve fixed the wildcard hosts in the config above and set FQDN to; without success though.


Finally, after several days of investigation I got it to work. The main problem was in my virtualservice definition: I have used

- match:
    uri: ...

instead of

- match:
  - uri: ...

Took me a while to figure out what exactly is wrong on my definition even after istioctl validate was failing (since it complains that this is not a JSON etc. it’s hard to figure out if it’s working at all).

Another problem was that Gateway must be in the istio-system namespace (in the same namespace as istio-ingress-gateway) - I’ve found this information in sources but not in the docs (might have missed that, though). Virtualservice definition can be either in istio-system or reference the gateway by FQDN: app-gateway.istio-system.svc.cluster.local.

Finding out that I haven’t given anyuid and privileged SCCs to istio-galley-service-account and therefore it can’t open port 443 wasn’t such a problem; I haven’t noticed that it’s not opening that port until I got the virtualservice definition right and validating admission webhook started complaining.