在GKE上使用Nginx入口控制器时，负载均衡器的节点不正常 [英] Unhealthy nodes for load balancer when using nginx ingress controller on GKE

问题描述

我已经按照本指南.

入口很好，我可以访问defaultbackend服务和我自己的服务.

The ingress works well and I am able to visit the defaultbackend service and my own service as well.

但是，当查看在Google Cloud Console中创建的对象时，尤其是自动创建的负载均衡器对象时，我注意到其他节点的运行状况检查失败:

But when reviewing the objects created in the Google Cloud Console, in particular the load balancer object which was created automatically, I noticed that the health check for the other nodes are failing:

这是因为入口控制器进程仅在一个节点上运行，所以它是唯一通过运行状况检查的节点吗? 如何使其他节点通过?

Is this because the ingress controller process is only running on the one node, and so it's the only one that passes the health check? How do I make the other nodes pass?

推荐答案

您的假设是正确的.健康节点确实是运行nginx pod的节点.

Your assumption is correct. The healthy node is indeed the one running the nginx pod.

您正在使用的指南使用externalTrafficPolicy: Local配置服务.(

The guide you're using configures the service with externalTrafficPolicy: Local.(https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/gce-gke/service.yaml)

该策略将kube-proxy配置为从不将服务的流量路由到其到达的节点之外.因此，当负载均衡器流量到达没有nginx pod的节点时，运行状况检查将失败，负载均衡器将停止向其发送流量.

That policy configures kube-proxy to never route traffic for a service off of the node where it arrives. So, when the load balancer traffic reached the nodes that have no nginx pod, the health check failed and the load balancer stopped sending traffic to them.

此配置的优点是避免了到达nginx pod的额外网络跃点.如果您需要更多节点来处理流量，则可以确保那里也运行着nginx Pod.如果您不介意额外的网络跃点，也可以更改externalTrafficPolicy.

This configuration had the advantage of avoiding an extra network hop to get to the nginx pod. If you need more nodes to handle the traffic, you can ensure that there are nginx pods running there too. If you don't mind the extra network hop, you can change the externalTrafficPolicy too.

这篇关于在GKE上使用Nginx入口控制器时，负载均衡器的节点不正常的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！