时间戳

首页 > 解决方案 > 使用 Nginx-Ingress-Controller 在 AWS 上的 EKS 中使用 gRPC

ssl - 使用 Nginx-Ingress-Controller 在 AWS 上的 EKS 中使用 gRPC

问题描述

我在 AWS EKS 中设置了 gRPC 服务器，并使用 Nginx-Ingress-Controller 执行负载平衡。我尝试通过将 gRPC 服务器入口设置为 like 来终止 NLB 的 TLS

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/backend-protocol: "GRPC"
  name: my-grpc
  namespace: myspace
spec:
  rules:
    - host: my.test.com
      http:
        paths:
          - path: /
            backend:
              serviceName: grpc-server
              servicePort: 8080

另外，我使用 Amazon Certificate Manager 来管理 NLB 的 TLS，所以我必须将 Nginx-Ingress-Controller Value.yaml 的 Helm Chart 更改为以下字段

controller:
  service:
    enabled: true
    annotations: 
      service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xxxxxxxxxxx
      service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
      service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443,8443"
      service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "3600"
      service.beta.kubernetes.io/aws-load-balancer-type: nlb
      service.beta.kubernetes.io/aws-load-balancer-internal: "true"

    targetPorts:
      http: http
      https: http

问题是，我无法通过 443 端口成功调用并使客户端连接到 gRPC 服务器。

问题发生在 NLB 和 Nginx 之间，但是是什么以及为什么是未知的。任何形式的帮助将不胜感激。

注意：我知道示例ingress-nginx有 TLS 字段，但是如果我使用 ACM，我应该放在这里。

标签： sslnginxgrpc

解决方案

我终于通过 AWS + NLB + EKS 得到了一些东西。我从这个基本的 grpc 应用开始

用您的 URL（例如 example.com）交换“fortune-teller.stack.build”的任何实例

在入口中，我必须将tls -> secret Name 更改为我之前使用本指南 创建的 tls-secret

kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/backend-protocol: "GRPC"
  name: fortune-ingress
  namespace: default
spec:
  rules:
  - host: example.com
    http:
      paths:
      - backend:
          serviceName: fortune-teller-service
          servicePort: grpc
  tls:
  - secretName: tls-secret
    hosts:
      - example.com

在 cert.yaml 中，更改

  1. 规范 -> 我的 URL 的域（example.com）

在 svc.yaml 中，添加注解和“type:LoadBalancer”

apiVersion: v1
kind: Service
metadata:
  name: fortune-teller-service
  namespace: default
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    service.beta.kubernetes.io/aws-load-balancer-internal: "false"
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:<REGION>:<MY ACCOUNT>:certificate/<CERT ID>"
    service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "tcp"
spec:
  type: LoadBalancer
  selector:
    k8s-app: fortune-teller-app
  ports:
  - port: 50051
    targetPort: 50051
    name: grpc

通过自述文件部署所有内容后，在 AWS 控制台中找到 NLB。

  1. 侦听器选项卡 -> 选择侦听器 (50051) 并单击“编辑”
  2. 将协议更改为 TLS，我将端口更改为 443
  3. 在 ALPN 策略下，选择“HTTP2Only”
  4. 在“默认操作 -> 转发到”下保持相同的目标组
  5. 选择一个策略版本（我选择了 ELBSecurityPolicy2016-08，但将对其进行升级）以及与您的 URL 相关联的来自 ACM 的证书
  6. 点击“更新”
  7. 将您的 DNS 名称指向您的 NLB

现在等待...因为侦听器更新似乎需要几分钟。

grpcurl example.com:443 build.stack.fortune.FortuneTeller/Predict

通过交换图像、端口，当然还有名称，我还能够让我的应用程序成功运行。

我犯的错误使它对我不起作用：

  • 入口中没有 TLS 密钥
  • 当 AWS 文档说您的目标组必须是“TLS 目标组”时，请相信他们。如果您遵循此示例，则永远不会交换 TG。TG 保持作为 TCP TG 并且仍然工作。

推荐阅读