GKE Ingress 显示不健康的后端服务

Question

我有一个 GKE 集群，在一个实例组中有 4 个节点。我部署了 Ingress 和几个 pods（每个 pod 仅 1 个副本，因此它们仅在 1 个节点上）。我在 Google 控制台（入口详细信息页面）上注意到，尽管运行 pods 上的健康检查正常并且我的应用程序是运行，但所有后端服务仍然不健康。据我了解，它说它是不健康的，因为在 4 个节点中，只有 1 个节点是运行给定 pod 的实例（在后端服务详细信息中它说“4 个实例中的 1 个健康”）。我是对的吗？我应该担心并尝试解决这个问题吗？当应用程序运行...

时接受不健康状态有点奇怪

编辑：进一步排查，下到2个节点，激活healthcheck日志，发现后台服务状态好像是上次执行healthcheck的状态。因此，如果它最后检查托管 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

Answer 1

请检查您的服务的 yaml 文件。如果它显示 externalTrafficPolicy: local，则这是预期的行为。

本地意味着流量将始终流向同一节点上的 pod，而其他所有内容都将被丢弃。因此，如果您的部署只有 1 个正在服务的副本，您将只有一个健康的实例。

您可以轻松地测试该理论，扩展到 2 个副本并观察行为。如果第二个副本落在与第一个副本相同的节点上，我预见到 1 个健康实例；如果第二个副本落在不同节点上，我预见到 2/4 健康实例。让我知道。

Answer 2

我有一个非常相似的问题。我不需要分享我的设置，因为它几乎与 OP 相同。我也像 OP 一样使用 GKE Ingress Controller。我手动将 externalTrafficPolicy: Local 添加到 Ingress Controller 后端服务调用的服务中，当我将 externalTrafficPolicy 从 'Local' 更改为 'Cluster'（根据上面的 dany L）时，Ingress 后端服务立即报告健康。

我从被调用的服务中删除了 'externalTrafficPolicy:' 行，现在我使用容器本机负载平衡设置了 GKE Ingress Controller，所有后端服务都报告健康。

Answer 3

终于找到原因了
我的服务没有提及 externalTrafficPolicy 的任何值，因此应用了 Cluster 的默认值。
但是，我定义了一个 NetworkPolicy，其目标是防止来自其他命名空间的流量，如 here 所述。我按照 doc 中所述添加了负载均衡器探测的 IP，但缺少 允许来自集群中其他节点 IP 的连接。

Answer 4

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

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

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

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

更多详情：

创建 Ingress 时，告诉 GCP 如何配置 Cloud Loadbalancer 的控制器会从 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 用来确定后端是否健康的方法。

然后有另一个请求/ping来自代码为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

两个代理都使用正确的准备探测路径。

Answer 5

遇到了与@jfc 相同的问题。

我在我的 pod 中指定了 livenessProbe 和 readinessProbe 自定义健康检查路径。

足以修复 kube-probe 健康检查，但不足以修复 GoogleHC 健康检查。我必须在 GCP console.

中手动配置 healthchek

GKE Ingress 显示不健康的后端服务

GKE Ingress shows unhealthy backend services

google-kubernetes-engine

kubernetes-ingress