GKE Ingress 显示不正常的后端服务

Question

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

编辑： 进一步排查，下到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

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

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

Answer 2

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

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

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

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

---

更多细节：

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

然后有另一个来自代理的/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 3

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

Answer 4

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

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

您可以轻松地测试该理论、扩展到 2 个副本并观察行为。如果第二个副本与第一个副本位于同一节点上，我预计 1 个健康实例，如果第二个副本位于不同节点上，则 2/4 健康。告诉我。