kubernetes - 为什么我的 Kubernetes 服务有时只能在 EKS 上运行？

Question

在某些情况下，我们的服务在尝试访问它们时没有得到响应。例如，Chrome 显示 ERR_EMPTY_RESPONSE，偶尔我们也会遇到其他错误，比如 408，我相当肯定它是从 ELB 返回的，而不是我们的应用程序本身。

经过长时间的调查，包括通过 ssh 连接到节点本身、试验负载均衡器等等，我们仍然不确定问题实际存在于哪一层:要么是 Kubernetes 本身，要么是来自 Amazon EKS(ELB 或除此以外)

似乎只有节点的实例(数据)端口是有问题的端口。这些问题似乎时断时续，这让我们相信这在我们的 kubernetes manifest 或 docker 配置中并不明显，而是在底层基础设施中的其他东西。有时服务和 pods 会工作，但回来早上它就会坏掉。这使我们相信问题源于 Kubernetes 中 pod 的重新分配，可能是由 AWS 中的某些东西(负载均衡器更改、自动缩放组更改等)或 Kubernetes 本身在出于其他原因重新分配 pod 时触发的。

在我们所看到的所有情况下，健康检查端口继续正常工作，这就是为什么 Kubernetes 和 aws 都认为一切正常并且不报告任何故障的原因。

我们已经看到一个节点上的一些 pod 可以工作，而另一些则不能在同一个节点上工作。

我们已经验证 kube-proxy 正在运行，并且 iptables-save 输出在两个正在工作的 Pod 之间是“相同的”。 (同样的意思是所有不是唯一的东西，比如 ip 地址和端口都是相同的，并且与它们之间的相对关系一致)。 (我们使用这些说明来帮助这些说明:https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/#is-the-kube-proxy-working

通过节点本身的 ssh，对于失败的 pod，我们可以通过所有可能的 ip/ports 访问该 pod(即应用程序本身)。

10. 节点本身的地址，在实例数据端口上。

10. pod(docker容器)在应用端口上的地址。

172.地址的？？？在应用程序端口上(我们不确定该 ip 是什么，或者 ip 路由如何到达它，因为它与 docker0 接口(interface)的 172 地址是不同的子网)。

从另一个节点上的 ssh，对于失败的 pod，我们无法在任何端口 (ERR_EMPTY_RESPONSE) 上访问失败的 pod。这似乎与服务/负载均衡器的行为相同。

还有什么可能导致这样的行为？

Answer 1

添加

service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"

为我解决了这个问题