在 kubernetes 中自动缩放期间某些请求失败
Some requests fails during autoscaling in kubernetes
我在 microk8s 上设置了一个 k8s 集群，并将我的应用程序移植到它上面。我还添加了一个水平自动缩放器，它根据 cpu 负载添加 pods。自动缩放器工作正常，当负载超出目标时它会添加 pods 并且当我在一段时间后删除负载时它会杀死 pods.
问题是我在同一时刻注意到自动缩放器正在创建新的pods一些请求失败：
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
POST Response Code : 502
java.io.IOException: Server returned HTTP response code: 502 for URL: http://10.203.101.61/gateway/compile
POST Response Code : 502
java.io.IOException: Server returned HTTP response code: 502 for URL: http://10.203.101.61/gateway/compile
POST Response Code : 200
POST Response Code : 502
java.io.IOException: Server returned HTTP response code: 502 for URL: http://10.203.101.61/gateway/compile
POST Response Code : 502
java.io.IOException: Server returned HTTP response code: 502 for URL: http://10.203.101.61/gateway/compile
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
我想知道这是什么原因，我该如何解决？
更新：
我认为我最好向您提供有关我的设置的更多信息：
流量来自集群外部，但是k8s节点和生成请求的程序都在一台机器上，所以没有网络问题。有一个自定义的 nginx 组件，它不进行负载平衡，只是充当反向代理并将流量发送到相应的服务。
我 运行 另一个测试给了我更多信息。我 运行 相同的基准测试，但这次我没有将请求发送到反向代理 (nginx)，而是使用了该特定服务的 IP 地址，并且在自动缩放器完成其工作并启动多个时我没有失败的请求pods。不知道是Nginx还是k8s的问题？
当新的 pods 产生时，Kubernetes 立即开始将流量重定向到它们。
但是，通常情况下，pod 需要一些时间才能启动并开始运行（就绪）。
为防止这种情况发生，您可以为 pods 定义一个 Readiness Probe。
K8s 将定期调用您提供的就绪端点上的 pod，以确定此 pod 是否正常运行并准备好接受请求。
K8s 不会将流量重定向到 pod，直到准备端点 returns 成功的结果取决于 type of probe（检查“探测器类型”部分）。
关于您的问题：
I am not sure if the problem is Nginx or k8s?
根据 ingress-nginx 文档：
The NGINX ingress controller does not uses Services to route traffic
to the pods. Instead it uses the Endpoints API in order to bypass
kube-proxy to allow NGINX features like session affinity and custom
load balancing algorithms. It also removes some overhead, such as
conntrack entries for iptables DNAT
所以我认为问题出在 Nginx 中，它没有使用所有 Kubernetes 功能（例如 kube-proxy），并且在它们完全准备好之前将请求发送到 Pods。
但是显然这个 problem was fixed 在 0.23.0 (Feb/2019) 中，所以你应该检查你的版本。
就个人而言，从 Ingress-Nginx 切换到 Ambassador 后，我遇到的问题较少，默认情况下将请求转发到服务（因此 Kubernetes 负责负载平衡并将其发送到适当的 Pod）。
我在 microk8s 上设置了一个 k8s 集群，并将我的应用程序移植到它上面。我还添加了一个水平自动缩放器，它根据 cpu 负载添加 pods。自动缩放器工作正常，当负载超出目标时它会添加 pods 并且当我在一段时间后删除负载时它会杀死 pods.
问题是我在同一时刻注意到自动缩放器正在创建新的pods一些请求失败：
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
POST Response Code : 502
java.io.IOException: Server returned HTTP response code: 502 for URL: http://10.203.101.61/gateway/compile
POST Response Code : 502
java.io.IOException: Server returned HTTP response code: 502 for URL: http://10.203.101.61/gateway/compile
POST Response Code : 200
POST Response Code : 502
java.io.IOException: Server returned HTTP response code: 502 for URL: http://10.203.101.61/gateway/compile
POST Response Code : 502
java.io.IOException: Server returned HTTP response code: 502 for URL: http://10.203.101.61/gateway/compile
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
POST Response Code : 200
我想知道这是什么原因，我该如何解决？
更新： 我认为我最好向您提供有关我的设置的更多信息：
流量来自集群外部，但是k8s节点和生成请求的程序都在一台机器上，所以没有网络问题。有一个自定义的 nginx 组件，它不进行负载平衡，只是充当反向代理并将流量发送到相应的服务。
我 运行 另一个测试给了我更多信息。我 运行 相同的基准测试，但这次我没有将请求发送到反向代理 (nginx)，而是使用了该特定服务的 IP 地址，并且在自动缩放器完成其工作并启动多个时我没有失败的请求pods。不知道是Nginx还是k8s的问题？
当新的 pods 产生时，Kubernetes 立即开始将流量重定向到它们。 但是，通常情况下，pod 需要一些时间才能启动并开始运行（就绪）。
为防止这种情况发生，您可以为 pods 定义一个 Readiness Probe。 K8s 将定期调用您提供的就绪端点上的 pod，以确定此 pod 是否正常运行并准备好接受请求。 K8s 不会将流量重定向到 pod，直到准备端点 returns 成功的结果取决于 type of probe（检查“探测器类型”部分）。
关于您的问题：
I am not sure if the problem is Nginx or k8s?
根据 ingress-nginx 文档：
The NGINX ingress controller does not uses Services to route traffic to the pods. Instead it uses the Endpoints API in order to bypass kube-proxy to allow NGINX features like session affinity and custom load balancing algorithms. It also removes some overhead, such as conntrack entries for iptables DNAT
所以我认为问题出在 Nginx 中，它没有使用所有 Kubernetes 功能（例如 kube-proxy），并且在它们完全准备好之前将请求发送到 Pods。
但是显然这个 problem was fixed 在 0.23.0 (Feb/2019) 中，所以你应该检查你的版本。
就个人而言，从 Ingress-Nginx 切换到 Ambassador 后，我遇到的问题较少，默认情况下将请求转发到服务（因此 Kubernetes 负责负载平衡并将其发送到适当的 Pod）。