当后端返回404/422时,GKE基本入口间歇性地返回502



我有一个入口,为GKE上运行的两个微服务提供路由,当微服务间歇性返回404/422时,入口返回502。

这是我的入口定义:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: basic-ingress
annotations:
kubernetes.io/ingress.global-static-ip-name: develop-static-ip
ingress.gcp.kubernetes.io/pre-shared-cert: dev-ssl-cert
spec:
rules:
- http:
paths:
- path: /*
backend:
serviceName: srv
servicePort: 80
- path: /c/*
backend:
serviceName: collection
servicePort: 80
- path: /w/*
backend:
serviceName: collection
servicePort: 80

我运行的测试到达srv后端,在那里我期望404或422响应。当我直接访问srv后端(绕过入口(时,我已经验证了服务是否正确响应404/422。

当我通过入口发出相同的请求时,入口将间歇性地以502响应,而不是来自后端的404/422。

如何让入口从后端返回404/422响应?

下面是一些示例代码来演示我所看到的行为(预期状态为404(:

>>> for i in range(10):
resp = requests.get('https://<server>/a/v0.11/accounts/junk', cookies=<token>)
print(resp.status_code)
502
502
404
502
502
404
404
502
404
404

以下是从pod内的python提示符发出的相同请求,即绕过入口:

>>> for i in range(10):
...     resp = requests.get('http://0.0.0.0/a/v0.11/accounts/junk', cookies=<token>)
...     print(resp.status_code)
...
404
404
404
404
404
404
404
404
404
404

以下是kubectl命令的输出,以证明负载均衡器设置正确(我从未从微服务获得2xx/3xx响应的502(:

$ kubectl get pods -o wide
NAME                          READY   STATUS    RESTARTS   AGE   IP          NODE                                     NOMINATED NODE   READINESS GATES
srv-799976fbcb-4dxs7          2/2     Running   0          19m   10.24.3.8   gke-develop-default-pool-ea507abc-43h7   <none>           <none>
srv-799976fbcb-5lh9m          2/2     Running   0          19m   10.24.1.7   gke-develop-default-pool-ea507abc-q0j3   <none>           <none>
srv-799976fbcb-5zvmv          2/2     Running   0          19m   10.24.2.9   gke-develop-default-pool-ea507abc-jjzg   <none>           <none>
collection-5d9f8586d8-4zngz   2/2     Running   0          19m   10.24.1.6   gke-develop-default-pool-ea507abc-q0j3   <none>           <none>
collection-5d9f8586d8-cxvgb   2/2     Running   0          19m   10.24.2.7   gke-develop-default-pool-ea507abc-jjzg   <none>           <none>
collection-5d9f8586d8-tzwjc   2/2     Running   0          19m   10.24.2.8   gke-develop-default-pool-ea507abc-jjzg   <none>           <none>
parser-7df86f57bb-9qzpn       1/1     Running   0          19m   10.24.0.8   gke-develop-parser-pool-5931b06f-6mcq    <none>           <none>
parser-7df86f57bb-g6d4q       1/1     Running   0          19m   10.24.5.5   gke-develop-parser-pool-5931b06f-9xd5    <none>           <none>
parser-7df86f57bb-jchjv       1/1     Running   0          19m   10.24.0.9   gke-develop-parser-pool-5931b06f-6mcq    <none>           <none>
$ kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
srv          NodePort    10.0.2.110   <none>        80:30141/TCP   129d
collection   NodePort    10.0.4.237   <none>        80:30270/TCP   129d
kubernetes   ClusterIP   10.0.0.1     <none>        443/TCP        130d
$ kubectl get endpoints
NAME         ENDPOINTS                                AGE
srv          10.24.1.7:80,10.24.2.9:80,10.24.3.8:80   129d
collection   10.24.1.6:80,10.24.2.7:80,10.24.2.8:80   129d
kubernetes   35.237.239.186:443                       130d

tl;dr:GCP LoadBalancer/GKE Ingress将502,如果来自后端的404/422没有响应体。

查看LoadBalancer日志,我会看到以下错误:

502: backend_connection_closed_before_data_sent_to_client
404: backend_connection_closed_after_partial_response_sent

由于一切都配置正确(甚至LoadBalancer也说后端是健康的(——后端按预期工作,没有失败的健康检查——我尝试了一些东西,注意到我的404个响应都是空的。

Sooo,我在404和422的回复中添加了一个正文,瞧,再也没有502了!

502是一个棘手的状态代码,它可能意味着客户端取消了上下文,或者只是您试图访问的服务器的坏网关。在kubernetes中,502通常意味着您无法访问该服务。因此,我将调试您的服务和部署文档。

使用kubectl get pods -o wide获取您的srv吊舱;检查其clusterIP IP。然后确保服务正在对srv部署进行负载平衡。要完成此操作,请运行kubectl get svc并查找srv服务。最后运行kubectl get endpoints,获取分配给srv端点的IP,并将其与从pod获得的IP进行匹配。如果这一切都正常,那么您就可以正确地对后端进行负载平衡。

当您的后端服务返回4xx错误时,预计会出现502个错误。如果后端返回4xx,则运行状况检查将失败。如果所有后端都出现故障,则负载均衡器将没有可用的后端来向其发送流量,并且将返回502。

对于负载平衡器返回的任何502错误,我强烈建议检查HTTP负载平衡器的stackdriver日志。任何502错误都将包括与502响应一起输出的消息。该消息应澄清502被重新使用的原因(原因有很多(。

在您当前的情况下,502错误日志应该提到"failed_to_pick_backend"或"failed_to_connect_to_backend",诸如此类。如果您使用的是nginxingress,可以看到类似的行为,但502错误消息可能会说一些不同的东西。

相关内容

  • 没有找到相关文章

最新更新