GKE大会显示了不健康的后端服务

Question

我有一个GKE集群，在一个实例组中有4个节点。我部署了Ingress和几个荚(每个荚只有一个副本，所以它们只在一个节点上)。我在Google上注意到，所有后端服务都是不健康的，尽管运行的豆荚上的健康检查是正常的，并且我的应用程序正在运行。据我所知，这是不健康的，因为在这4个节点中，只有一个节点正在运行一个给定pod的实例(在后端服务细节上，它写着“4个实例中的一个是健康的”)。我是对的吗?我应该担心并试着解决这个问题吗？当应用程序运行时接受不健康状态有点奇怪.

编辑:经过进一步调查，减少到2个节点，并激活健康检查日志，我可以看到后端服务状态似乎是最后执行的健康检查的状态。所以，如果它检查最后一个承载豆荚的节点，它是健康的，否则是不健康的。

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

Answer 1

我终于找到了原因。

我的服务没有提到externalTrafficPolicy的任何值，所以应用了Cluster的默认值。

但是，我已经定义了一个NetworkPolicy，它的目标是防止来自其他名称空间的通信，正如这里所描述的那样。如本文档中所述，我添加了负载平衡器探测的in，但没有从集群中的其他节点in中获得允许连接。

Answer 2

我也有过类似的问题。我不需要分享我的设置，因为它几乎与OP相同。我使用的GKE大会控制器也像OP一样。我已经手动地将externalTrafficPolicy: Local添加到了由immediately后端服务调用的服务中，并且当我将externalTrafficPolicy从'Local‘更改为’集群‘时(如上面的dany L所示)，reported后端服务立即报告正常。

我从被调用的服务中删除了“externalTrafficPolicy：”行，现在使用conatainer本机负载平衡与所有报告健康的后端服务一起使用GKE进行设置。

Answer 3

我也遇到了类似的问题: GCP网络端点说后端不健康。

在我的例子中，问题是我的应用程序不会在/中返回200，因为它需要身份验证。

确保将livenessProbe和readinessProbe配置为对返回200 OK的路径执行httpGet。就我而言：

livenessProbe:
    httpGet:
        path: /ping
        port: 4180
readinessProbe:
    httpGet:
        path: /ping
        port: 4180

更多详细信息：

当创建Ingress时，告诉GCP如何配置来自Deployment规范的云负载均衡器副本的控制器将获取有关探测的信息，这就是用来确定Google后端端点健康状况的信息。

我发现了这一点，因为当我部署应用程序时，没有配置探测。然后，我编辑了部署，并添加了两个探测，但都没有工作。我可以在我的应用程序日志中看到这个：

[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+的代理的对kube-probe/1.20+的另一个请求，即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

两名特工使用正确的路径进行准备探测。