我有一个GKE集群，在一个实例组中有4个节点。我部署了Ingress和几个pod(每个pod只有一个副本，所以它们只在一个节点上(。我在谷歌控制台(Ingress详细信息页面(上注意到，尽管运行中的pod上的健康检查正常，并且我的应用程序正在运行，但所有后端服务仍然不健康。据我所知，它说这是不健康的，因为在4个节点中，只有1个节点正在运行给定pod的实例(在后端服务详细信息中，它说"4个实例中的1个健康"(。我是对的吗？我应该担心并尝试解决这个问题吗？在应用程序运行时接受"不健康"状态有点奇怪。。。
编辑：经过进一步的调查，多达2个节点，并激活健康检查日志，我可以看到后端服务状态似乎是上次执行的健康检查的状态。因此，如果它最后检查承载pod的节点，则它是健康的，否则它是不健康的。
GKE版本：1.16.13-GKE.1
我的入口定义：
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
ingress.gcp.kubernetes.io/pre-shared-cert: mcrt-dc729887-5c67-4388-9327-e4f76baf9eaf
ingress.kubernetes.io/backends: '{"k8s-be-30301--503461913abc33d7":"UNHEALTHY","k8s-be-31206--503461913abc33d7":"HEALTHY","k8s-be-31253--503461913abc33d7":"HEALTHY","k8s-be-31267--503461913abc33d7":"HEALTHY","k8s-be-31432--503461913abc33d7":"UNHEALTHY","k8s-be-32238--503461913abc33d7":"HEALTHY","k8s-be-32577--503461913abc33d7":"UNHEALTHY","k8s-be-32601--503461913abc33d7":"UNHEALTHY"}'
ingress.kubernetes.io/https-forwarding-rule: k8s2-fs-sfdowd2x-city-foobar-cloud-8cfrc00p
ingress.kubernetes.io/https-target-proxy: k8s2-ts-sfdowd2x-city-foobar-cloud-8cfrc00p
ingress.kubernetes.io/ssl-cert: mcrt-dc729887-5c67-4388-9327-e4f76baf9eaf
ingress.kubernetes.io/url-map: k8s2-um-sfdowd2x-city-foobar-cloud-8cfrc00p
kubernetes.io/ingress.allow-http: "false"
kubernetes.io/ingress.global-static-ip-name: city
networking.gke.io/managed-certificates: foobar-cloud
creationTimestamp: "2020-08-06T08:25:18Z"
finalizers:
- networking.gke.io/ingress-finalizer-V2
generation: 1
labels:
app.kubernetes.io/instance: foobar-cloud
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: foobar-cloud
helm.sh/chart: foobar-cloud-0.4.58
name: foobar-cloud
namespace: city
resourceVersion: "37878"
selfLink: /apis/extensions/v1beta1/namespaces/city/ingresses/foobar-cloud
uid: 751f78cf-2344-46e3-b87e-04d6d903acd5
spec:
rules:
- http:
paths:
- backend:
serviceName: foobar-cloud-server
servicePort: 9999
path: /foobar/server
- backend:
serviceName: foobar-cloud-server
servicePort: 9999
path: /foobar/server/*
status:
loadBalancer:
ingress:
- ip: xx.xx.xx.xx
我遇到了类似的问题：GCP网络端点说后端不健康。
在我的案例中，问题是我的应用程序在/中不会返回200，因为它需要身份验证。
确保将livenessProbe和readinessProbe配置为对返回200 OK的路径执行httpGet
livenessProbe:
httpGet:
path: /ping
port: 4180
readinessProbe:
httpGet:
path: /ping
port: 4180
更多详细信息：
创建Ingress时，告诉GCP如何配置云负载平衡器的控制器从Deployment规范中复制有关探测器的信息，这就是它用于确定Google Cloud后端端点的运行状况的信息。
我之所以发现这一点，是因为在部署应用程序时，我没有配置探测器。然后，我编辑了部署并添加了两个探测，但都不起作用。我可以在我的应用程序的日志中看到这一点：
[2021/11/22 18:38:43] [oauthproxy.go:862] No valid authentication in request. Initiating login.
130.211.1.166:32768 - e8d8b7f9-8cc9-419a-aeb8-898260169a2c - - [2021/11/22 18:38:43] 10.56.2.24 GET - "/" HTTP/1.1 "GoogleHC/1.0" 403 8092 0.000
10.56.2.1:45770 - e7a9d52a-ecbe-4e1c-af69-65ddf432d92c - - [2021/11/22 18:38:50] 10.56.2.24:4180 GET - "/ping" HTTP/1.1 "kube-probe/1.20+" 200 2 0.000
正如您所看到的，有一个来自代码为"的代理对/的请求；GoogleHC/1.0"；。这是GCP用来确定后端是否健康的方法。
然后还有另一个来自代码为kube-probe/1.20+的代理对/ping的请求，即Kubernetes中的readinessProbe。
然后我删除了Ingress并重新创建了它，这次它成功了：
130.211.1.180:39854 - d069dd2c-6733-4029-8c9b-fa03917ca2a7 - - [2021/11/22 18:57:32] 10.56.2.27 GET - "/ping" HTTP/1.1 "GoogleHC/1.0" 200 2 0.000
10.56.2.1:35598 - 85eeaf1c-a6e6-4cc8-a6ed-931f504f9493 - - [2021/11/22 18:57:36] 10.56.2.27:4180 GET - "/ping" HTTP/1.1 "kube-probe/1.20+" 200 2 0.000
两个代理都为就绪探测使用正确的路径。
我遇到了一个非常类似的问题。我不需要分享我的设置，因为它几乎与OP完全相同。我使用的GKE入口控制器也和OP一样。我手动将externalTrafficPolicy:Local添加到入口控制器后端服务调用的服务中，当我将external TrafficPolicy从"Local"更改为"Cluster"时(根据上面的dany L(，入口后端服务立即报告正常。
我从调用的服务中删除了"externalTrafficPolicy:"行，现在使用conatainer本机负载平衡设置了GKE入口控制器，所有后端服务都报告正常。
在Google Cloud中必须有一个返回代码200的端点。对于C#.Net Core，您可以在健康检查中看到如何执行操作创建端点后，需要配置两件事：
- 创建一个BackendConfig来定义url(请求路径(
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: http-hc-config
spec:
healthCheck:
checkIntervalSec: 60
port: 80
type: HTTP
requestPath: /health
- 在服务中的注释中定义"cloud.google.com/backend-config">
kind: Service
metadata:
name: app-service
annotations:
cloud.google.com/neg: '{"ingress": true}'
cloud.google.com/backend-config: '{"default": "http-hc-config"}'
spec:
selector:
type: app
ports:
- port: 80
protocol: TCP
targetPort: 80
type: NodePort
对我来说，这项工作。
我终于找到了原因
我的服务没有提到externalTrafficPolicy的任何值，因此应用了Cluster的默认值
但是，我定义了NetworkPolicy，其目标是防止来自其他命名空间的流量，如这里所述。如本文所述，我添加了负载平衡器探测器的IP，但缺少集群中其他节点IP的允许连接
遇到与@jfc相同的问题。
我在我的pod中使用自定义健康检查路径指定了livenessProbe和readinessProbe。
这足以修复kube-probe健康检查，但不足以修复GoogleHC健康检查。我不得不在GCP控制台中手动配置healthchek。
请检查您的服务的yaml文件。如果它显示externalTrafficPolicy:local，则它是预期行为。
本地意味着流量将始终流向同一节点上的一个pod，而其他所有内容都会被丢弃。因此，如果您的部署只有一个副本，那么您将只有一个正常的实例。
您可以很容易地测试该理论，扩展到2个副本并观察行为。如果第二个副本与第一个副本在同一个节点上，我会选择1个健康实例；如果第二次副本在不同的节点上，则我会选择2/4个健康实例。让我知道。