gpt4 book ai didi

ssl - 带有 Nginx-Ingress-Controller 的 AWS 上 EKS 中的 gRPC

转载 作者:行者123 更新时间:2023-12-04 22:36:05 25 4
gpt4 key购买 nike

我在 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,我应该放在这里。

最佳答案

我终于通过 AWS + NLB + EKS 得到了一些东西。我从这个 basic grpc app 开始

用您的 URL(例如 example.com)替换“fortune-teller.stack.build”的所有实例

在入口处,我不得不改变tls -> secret 我之前创建的 tls-secret 的名称 using this guide

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. Listeners 选项卡 -> 选择监听器 (50051) 并单击“编辑”
  2. 将协议(protocol)更改为 TLS,并将端口更改为 443
  3. 在 ALPN 策略下,选择“HTTP2Only”
  4. 在“默认操作 -> 转发至”下保持相同的目标组
  5. 选择一个策略版本(我选择了 ELBSecurityPolicy2016-08,但会升级它)和来自 ACM 的与您的 URL 绑定(bind)的证书
  6. 点击“更新”
  7. 将您的 DNS 名称指向您的 NLB

现在稍等...因为监听器更新似乎需要几分钟时间。

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

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

我犯的错误导致它对我不起作用:

  • 在入口处没有 TLS secret
  • 当 AWS 文档说您的目标组必须是“TLS 目标组”时,请相信他们。如果你按照这个例子,你永远不会交换 TG。 TG 仍作为 TCP TG 继续工作。

关于ssl - 带有 Nginx-Ingress-Controller 的 AWS 上 EKS 中的 gRPC,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/62334832/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com