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

Question

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

经过长期的调查，包括对节点本身进行shsh处理，对负载均衡器进行实验等，我们仍然不确定问题实际存在于哪一层：在Kubernetes本身中，还是在Amazon EKS（ELB或除此以外）

• 似乎只有节点的实例（数据）端口才是有问题的端口。这些问题似乎是断断续续的，这使我们相信，在我们的kubernetes清单或docker配置中，这并不是显而易见的事情，而在基础架构中却是其他问题。有时服务和吊舱会正常工作，但回来后又会早晨破损。这使我们相信问题出在kubernetes中的Pod的重新分配，可能是由AWS中的某项（负载平衡器更改，自动扩展组更改等）或kubernetes本身中由于其他原因重新分配Pod引起的。
• 在我们已经看到的所有情况下，运行状况检查端口都可以正常运行而不会出现问题，这就是为什么kubernetes和aws都认为一切正常并且不报告任何故障的原因。
• 我们已经看到某个节点上的某些Pod可以工作，而其他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 /端口访问Pod（即应用程序本身）。
  • 实例数据端口上节点本身的10.地址。
  • 应用程序端口上的容器（docker容器）的地址10.。
  • 172.的地址？在应用程序端口上（我们不确定该ip是什么，或者ip路由如何到达它，因为它是与docker0接口的172地址不同的子网）。
• 从另一个节点上的ssh，对于发生故障的Pod，我们无法在任何端口（ERR_EMPTY_RESPONSE）上访问发生故障的Pod。这似乎与服务/负载平衡器的行为相同。

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

Answer 1

经过大量调查后，我们遇到了许多问题： * 我们的应用程序并不总是按照我们预期的方式运行。一定要先检查一下。* 在我们的 Kubernetes 服务清单中，我们设置了externalTrafficPolicy: Local，这可能应该有效，但给我们带来了问题。（这是使用经典负载均衡器时的情况）service.beta.kubernetes.io/aws-load-balancer-type: "clb"。因此，如果您在使用 CLB 时遇到问题，请删除externalTrafficPolicy或将其显式设置为默认的“集群”值。

所以我们的清单现在是： kind: Service apiVersion: v1 metadata: name: apollo-service annotations: service.beta.kubernetes.io/aws-load-balancer-type: "clb" service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:REDACTED" service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443" service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"
spec: externalTrafficPolicy: Cluster selector: app: apollo ports: - name: http protocol: TCP port: 80 targetPort: 80 - name: https protocol: TCP port: 443 targetPort: 80 type: LoadBalancer