如何在为Kubernetes入口服务的GCE L7平衡器中获得自定义healthcheck路径？

Question

我试图在GCE中的Kubernetes（服务器1.6.4）中部署一个grafana实例。我正在使用以下清单：

部署（完整版本）：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: grafana
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: grafana
    spec:
      initContainers:
        …                                
      containers:
        - name: grafana
          image: grafana/grafana
          readinessProbe:
            httpGet:
              path: /login
              port: 3000
          …

服务：

apiVersion: v1
kind: Service
metadata:
  name: grafana
spec:
  selector:
    name: grafana
  ports:
    - protocol: TCP
      port: 3000
  type: NodePort

入口：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: grafana
spec:
  tls:
    - secretName: grafana.example.com
  backend:
    serviceName: grafana
    servicePort: 3000

结果表明，grafana的安检为302，而默认的GCE安检为200（来源）。如您所见，部署中有一个自定义readinessProbe（第22行）。

一旦我将这些资源发布到kube apiserver，就会创建出所有内容，不会出错。具体来说，入口获得公共ip4地址，但healtcheck使用默认路径设置，而不是在readinessProbe中配置的自定义路径。因此，如果入口的公共ip4地址为curl，则得到502。

通过在GCE控制台中手动将探测路径更改为登录，可以解决此问题。

Answer 1

创建入口时进行推断健康检查的条件如下

入口backend.service端口引用服务端口，匹配Podsspec.containers[]. readinessProbe.httpGet.port，服务的目标端口引用服务Pod的容器[]。spec.ports.container端口。

2020年年中，GKE引入了注释和自定义资源定义BackendConfig来显式配置健康检查，请参阅概念/入口#health_checks。

警告：如果您再次更改readinessProbe，那么在推断的healthchecks上，GKE不会保持readiness probe和health check同步。只有在入口（重新）创建时才会再次推断。

要直接编辑外部Loadbalancers healthchecks（针对自定义http路径），请使用

gcloud compute backend-services list
gcloud compute backend-services get-health BACKEND_SERVICE_NAME --global
gcloud compute health-checks describe
gcloud compute health-checks update http BACKEND_SERVICE_NAME --request-path=/api/health

Answer 2

您的问题不太清楚，但如果您使用的是GCE Load Balancer Controller（GLBC）群集插件，则可以自定义运行状况检查路径。

当前，所有服务后端必须满足以下任一要求，才能通过GCE loadbalancer发送给它的HTTP（S）健康检查：

• 在“/”上响应200。内容无关紧要
• 将任意url公开为支持服务的POD上的就绪探测

入口控制器首先寻找兼容的就绪探测，如果找到一个，它会将其用作GCE负载均衡器的HTTP（S）健康检查。如果没有就绪探测，或者就绪探测需要特殊的HTTP标头，则入口控制器会将GCE负载均衡器的HTTP健康检查指向“/”。这是一个采用来自endpoint的就绪探测作为健康检查的入口示例。

GLBC加载项页面在限制部分提到了这一点：

所有Kubernetes服务都必须服务于'/'上的200页，或通过GLBC的--运行状况检查路径参数指定的任何自定义值。

如果您没有使用加载项，目前Kubernetes确实要求您在路径上为获取请求提供200个服务，以成功进行健康检查，否则后端将不会获得任何流量。

在这个错误中有一些关于这个的背景。

如果您使用的是Google容器引擎（GKE），那么同样的默认Kubernetes健康检查要求也适用于此。

通过入口公开的服务必须以HTTP 200状态响应路径上的GET请求。这用于健康检查。如果您的应用程序未在上提供HTTP 200，则后端将被标记为不健康，并且不会获得流量。

说到这里，正如您（@mmoya）在回答中指出的那样，添加用于就绪探测的同一端口作为pod中的一个端口可以解决您的问题，因为该端口本身不会暴露在pod之外。这导致Kubernetes转而依赖于来自的健康检查。

Answer 3

此处引用：

GLBC要求您在Pod规范中定义端口（在您的情况下为3000）。

解决方案是除了添加自定义readinessProbe之外，还要在port中声明用于健康检查的端口：

containers:
  - name: grafana
    readinessProbe:
      httpGet:
        path: /login
        port: 3000
    ports:
      - name: grafana
        containerPort: 3000
    …