【问题标题】:"ERR_EMPTY_RESPONSE" - ShinyApp hosted over AWS (EC2 / EKS / ShinyProxy) does not work“ERR_EMPTY_RESPONSE” - 通过 AWS(EC2 / EKS / ShinyProxy)托管的 ShinyApp 不起作用
【发布时间】:2021-11-25 14:11:54
【问题描述】:

更新 #2: 我在 Auto Scaling 组中检查了我的实例的健康状态 - 这里实例的标题为“健康”。 (已添加截图)

我从 AWS 关注 this trouble-shooting tutorial - 没有成功:

解决方案:对您的 Auto Scaling 组使用 ELB 运行状况检查。当您使用 ELB 健康检查时,Auto Scaling 通过检查实例状态检查和 ELB 健康检查的结果来确定您的实例的健康状态。有关更多信息,请参阅Amazon EC2 Auto Scaling 用户指南中的Adding health checks to your Auto Scaling group


更新 #1: 我发现这两个节点实例是“OutOfService”(如下面的屏幕截图所示),因为它们无法通过负载均衡器的健康检查 - 这可能是问题吗?又该如何解决呢?

谢谢!


我目前正准备在 AWS 上托管我的 ShinyApp。

为了使托管具有可扩展性,我决定使用 AWS - 更准确地说是 EKS 集群。

对于我按照本教程进行的创作:https://github.com/z0ph/ShinyProxyOnEKS

到目前为止一切正常,除了最后一步:“访问负载均衡器地址和端口时,ShinyProxy的登录界面可以正常显示。

当我尝试使用相应的端口调用负载均衡器时,它会立即给我以下错误消息:ERR_EMPTY_RESPONSE。

我不得不承认,我目前有点迷茫,缺乏可能出错的起点。

我已经能够在集群中托管 Shiny 示例应用程序(教程中的步骤 3.2),所以它一定是由于 Shinyproxy、kubernetes 代理或负载平衡器本身。

我将您链接到以下信息:

  • 概述 EC2 实例(工作区 + 集群节点)
  • 负载均衡器概述
  • 概览存储库
  • Dockerfile ShinyProxy
  • Dockerfile Kubernetes 代理
  • Dockerfile ShinyApp(示例应用程序)

为了安全起见,我已经把一些信息涂掉了——如果有什么重要的,请告诉我。

如果您还需要其他我没有想到的东西,请给我提示!

请原谅令人困惑的问题和格式 - 我只是不知道如何更好地表达/呈现它。对不起!

非常感谢和最好的问候


概述 EC2 实例(工作区 + 集群节点)

负载均衡器概述

概览存储库

Dockerfile ShinyProxy(来源https://github.com/openanalytics/shinyproxy-config-examples/tree/master/03-containerized-kubernetes

Dockerfile Kubernetes 代理(来源 https://github.com/openanalytics/shinyproxy-config-examples/tree/master/03-containerized-kubernetes - Fork)

Dockerfile ShinyApp(示例应用程序)

以下文件是 1:1 的教程:

  1. application.yaml (shinyproxy)
  2. sp-authorization.yaml
  3. sp-deployment.yaml
  4. sp-service.yaml

AutoScaling-Group 中的健康状态

【问题讨论】:

    标签: amazon-web-services docker kubernetes shiny shinyproxy


    【解决方案1】:

    很遗憾,AWS 中存在一个已知问题

    externalTrafficPolicy: Local with Type: LoadBalancer AWS NLB health checks failing · Issue #80579 · kubernetes/kubernetes

    暂时关闭它,因为这是一个已知问题

    根据k8s manual

    .spec.externalTrafficPolicy - 表示此服务是否希望将外部流量路由到节点本地或集群范围的端点。有两个可用选项:Cluster(默认)和LocalCluster 隐藏了客户端源 IP,可能会导致第二次跳转到另一个节点,但应该具有良好的整体负载分布。 Local 保留客户端源 IP 并避免 LoadBalancer 和 NodePort 类型服务的第二个跃点,但可能存在流量传播不平衡的风险。

    但您可以尝试修复本地协议,例如 in this answer

    【讨论】:

      猜你喜欢
      • 2017-10-14
      • 2018-12-19
      • 2020-01-26
      • 2016-06-28
      • 2020-11-03
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多