kubernetes - 无法为 gRPC 打开 Istio 入口网关

Question

这个问题是关于我无法使用 Istio 入口网关将 gRPC 客户端连接到托管在 Kubernetes (AWS EKS) 中的 gRPC 服务。
在 kubernetes 方面:我有一个带有 Go 进程的容器，它在端口 8081 上监听 gRPC。该端口在容器级别公开。我定义了一个 kubernetes 服务并暴露了 8081。我定义了一个 istio 网关，它选择 istio: ingressgateway 并为 gRPC 打开端口 8081。最后，我定义了一个 istio 虚拟服务，其中包含端口 8081 上任何内容的路由。
客户端:我有一个 Go 客户端，它可以向服务发送 gRPC 请求。

当我 kubectl port-forward -n mynamespace service/myservice 8081:8081 时它工作正常并通过 client -url localhost:8081 给我的客户打电话.

当我关闭端口时，用 client -url [redacted]-[redacted].us-west-2.elb.amazonaws.com:8081 调用我的客户端无法连接。 (该 url 是 kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' 的输出，附加了 :8081。

日志:

我看了istio-system/istio-ingressgateway服务日志。我没有看到尝试连接。

在浏览 istio bookinfo 时，我确实看到了我之前建立的 bookinfo 连接。教程。该教程有效，我能够打开浏览器并查看 bookinfo 产品页面，并且 ingressgateway 日志显示 "GET /productpage HTTP/1.1" 200 .所以 Istio ingress-gateway 可以工作，只是我不知道如何为新的 gRPC 端点配置它。

Istio 的 Ingress-Gateway

kubectl describe service -n istio-system istio-ingressgateway

输出以下内容，我怀疑这是问题所在，尽管我努力打开它，但未列出端口 8081。我对默认情况下打开了多少端口感到困惑，我没有打开它们(欢迎评论如何关闭我不使用的端口，但这不是这个问题的原因)

Name:                     istio-ingressgateway
Namespace:                istio-system
Labels:                   [redacted]
Annotations:              [redacted]
Selector:                 app=istio-ingressgateway,istio=ingressgateway
Type:                     LoadBalancer
IP:                       [redacted]
LoadBalancer Ingress:     [redacted]
Port:                     status-port  15021/TCP
TargetPort:               15021/TCP
NodePort:                 status-port  31125/TCP
Endpoints:                192.168.101.136:15021
Port:                     http2  80/TCP
TargetPort:               8080/TCP
NodePort:                 http2  30717/TCP
Endpoints:                192.168.101.136:8080
Port:                     https  443/TCP
TargetPort:               8443/TCP
NodePort:                 https  31317/TCP
Endpoints:                192.168.101.136:8443
Port:                     tcp  31400/TCP
TargetPort:               31400/TCP
NodePort:                 tcp  31102/TCP
Endpoints:                192.168.101.136:31400
Port:                     tls  15443/TCP
TargetPort:               15443/TCP
NodePort:                 tls  30206/TCP
Endpoints:                192.168.101.136:15443
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

所以我认为我没有为 GRPC 正确打开端口 8081。我可以运行哪些其他日志或测试来帮助确定这是从哪里来的？
这是相关的yaml:
Kubernetes Istio 虚拟服务:其意图是将端口 8081 上的任何内容路由到 myservice

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myservice
  namespace: mynamespace
spec:
  hosts:
  - "*" 
  gateways:
  - myservice
  http:
  - match:
    - port: 8081
    route:
    - destination:
        host: myservice

Kubernetes Istio 网关:其意图是为 GRPC 开放端口 8081

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: myservice
  namespace: mynamespace
spec:
  selector:
    istio: ingressgateway 
  servers:
    - name: myservice-plaintext
      port:
        number: 8081
        name: grpc-svc-plaintext
        protocol: GRPC
      hosts:
      - "*"

Kubernetes 服务:显示端口 8081 在服务级别暴露，我在前面提到的端口转发测试中证实了这一点

apiVersion: v1
kind: Service
metadata:
  name: myservice
  namespace: mynamespace
  labels:
    app: myservice
spec:
  selector:
    app: myservice
  ports:
    - protocol: TCP
      port: 8081
      targetPort: 8081
      name: grpc-svc-plaintext

Kubernetes 部署:显示端口 8081 在容器级别暴露，我在前面提到的端口转发测试中证实了这一点

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myservice
  namespace: mynamespace
  labels:
    app: myservice
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myservice
  template:
    metadata:
      labels:
        app: myservice
    spec:
      containers:
      - name: myservice
        image: [redacted]
        ports:
        - containerPort: 8081

重新检查客户端上的 DNS 工作:

getent hosts [redacted]-[redacted].us-west-2.elb.amazonaws.com

输出 3 个 IP，我认为这很好。

[IP_1 redacted]  [redacted]-[redacted].us-west-2.elb.amazonaws.com
[IP_2 redacted]  [redacted]-[redacted].us-west-2.elb.amazonaws.com
[IP_3 redacted]  [redacted]-[redacted].us-west-2.elb.amazonaws.com

检查 Istio Ingressgateway 的路由:

istioctl proxy-status istio-ingressgateway-[pod name]
istioctl proxy-config routes istio-ingressgateway-[pod name]

返回

Clusters Match
Listeners Match
Routes Match (RDS last loaded at Wed, 23 Sep 2020 13:59:41)

NOTE: This output only contains routes loaded via RDS.
NAME          DOMAINS     MATCH                  VIRTUAL SERVICE
http.8081     *           /*                     myservice.mynamespace
              *           /healthz/ready*        
              *           /stats/prometheus*

端口 8081 被路由到 myservice.mynamespace，对我来说似乎很好。
更新 1:
我开始明白我无法使用默认的 istio 入口网关打开端口 8081。该服务不公开该端口，我假设创建网关会在“幕后”更新服务，但事实并非如此。
我可以选择的外部端口是:80、443、31400、15443、15021，我认为我的网关只需要依赖这些。我已经更新了我的网关和虚拟服务以使用端口 80，然后客户端连接到服务器就好了。
这意味着我必须不通过端口来区分多个服务(显然不能从同一个端口路由到两个服务)，但是通过 SNI，我不清楚如何在 gRPC 中做到这一点，我猜我可以添加 Host:[hostname]在 gRPC header 中。不幸的是，如果这就是我可以路由的方式，这意味着需要在网关上读取 header ，并且当我希望在 pod 处终止时，这要求在网关处终止 TLS。

Answer 1

I am starting to understand I can't open port 8081 using the default istio ingress gateway. That service does not expose that port, and I was assuming creating a gateway would update the service "under the hood" but that's not the case. The external ports that I can pick from are: 80, 443, 31400, 15443, 15021 and I think my gateway needs to rely only on those. I've updated my gateway and virtual service to use port 80 and the client then connects to the server just fine.

我不确定您究竟是如何尝试为入口网关添加自定义端口的，但这是可能的。
据我查 here可以通过 3 种方式进行，以下是@A_Suh、@Ryota 和 @peppered 提供的带有示例链接的选项。

Kubectl edit

Helm

Istio Operator

其他资源:

How to create custom istio ingress gateway controller?

How to configure ingress gateway in istio?

That means I have to differentiate between multiple services not by port (can't route from the same port to two services obviously), but by SNI, and I'm unclear how to do that in gRPC, I'm guessing I can add a Host:[hostname] in the gRPC header. Unfortunately, if that's how I can route, it means headers need to be read on the gateway, and that mandates terminating TLS at the gateway when I was hoping to terminate at the pod.

我看到你已经创建了新问题 here ，所以让我们搬到那里去。