Нет, не пробовал.
Но этот же сервис крутиться в другом энве (без Istio) и на обычный "curl —http2" отвечает без проблем.

+ есть интеграционные тесты к этому сервису.
Естественно на Istio энве падают, а на энве без истио проходят.

https://istio.io/docs/setup/kubernetes/additional-setup/requirements/ требования из первого абзаца по названию портов выполняются?

На сервисах проставлено имя порта с префиксом grpc-<somename>.

а в virtualservice?

А вот тут мог и пропустить

в virtualservice никакой grpc дополнительно указывать не нужно, да и негде, это нужно для serviceentry, перепутал

Это да.
В общем ещё бодаюсь с этим ишью. Имена портов сервисах проверил, containerPort в деплойменте на месте.

попробуй на grpcbin, вот рабочий yaml со всем.
естественно, на ingress-gateway надо 82 порт добавить

apiVersion: v1
kind: Namespace
metadata:
  labels:
    istio-injection: enabled
  name: grpcbin
---
apiVersion: v1
kind: Service
metadata:
  name: grpcbin
  namespace: grpcbin
  labels:
    app: grpcbin
spec:
  ports:
  - name: grpc
    port: 82
    targetPort: 9000
  selector:
    app: grpcbin
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: grpcbin
  namespace: grpcbin
spec:
  replicas: 2
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"
      labels:
        app: grpcbin
        version: v1
    spec:
      containers:
      - image: moul/grpcbin
        imagePullPolicy: IfNotPresent
        name: grpcbin
        ports:
        - containerPort: 9000
          name: grpc
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: grpcbin-gateway
  namespace: grpcbin
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 82
      name: grpc
      protocol: GRPC
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: grpcbin
  namespace: grpcbin
spec:
  hosts:
  - "grpcbin.dev.mesh.mydomain.ru"
  gateways:
  - grpcbin-gateway
  http:
  - match:
    route:
    - destination:
        host: grpcbin
        port:
          number: 82

как минимум, gpcurl напрямую в под должен нормально отрабатывать

$ grpcurl -plaintext pod_ip:9000 list
addsvc.Add
grpc.gateway.examples.examplepb.ABitOfEverythingService
grpc.reflection.v1alpha.ServerReflection
grpcbin.GRPCBin
hello.HelloService

$ grpcurl -plaintext pod_ip:9000 list
addsvc.Add
grpc.gateway.examples.examplepb.ABitOfEverythingService
grpc.reflection.v1alpha.ServerReflection
grpcbin.GRPCBin
hello.HelloService

Окей сейчас попробую и отпишу.

Только вот смущает курл  pod_ip:9000

Курлить с другой поды ? или из самой grpcbin

откуда угодно, а почему смущает? запрос упрется в listener энвоя, все честно

тебе ж затраблшутить надо, сходить напрямую в под - первый этап

потом grpcurl в service ip, потом в ingressgateway с правильным заголовком Host

$ grpcurl -plaintext pod_ip:9000 list
addsvc.Add
grpc.gateway.examples.examplepb.ABitOfEverythingService
grpc.reflection.v1alpha.ServerReflection
grpcbin.GRPCBin
hello.HelloService

По IP поды и ServiceName отработало. Через AWS ELB/IngressGateway откидывает.

Вот манифесты. Которые зааплаил
https://pastebin.com/7waNJ6ER

Порт правда 8082, он открыт на AWS ELB и в сервисе IngressGateway присутствует:
   -
     name: https
     nodePort: 31390
     port: 443
   -
     name: grpc
     nodePort: 30000
     port: 8082
     targetPort: 8082

Совсем что-то растерялся, может потому что хожу вокруг да около уже сутки.

hosts: * в virtualservice лишняя, задай нормальный host