如何在服务于KubernetesIngress的GCEL7平衡器中获得自定义健康检查路径？

我正在尝试在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

Ingress:

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,一切都会毫无错误地创建.具体来说,Ingress获取一个公共ip4地址,但是使用默认/路径设置了healtcheck 而不是自定义的路径readinessProbe.因此,如果我curl是Ingress的公共ip4地址,我会得到502 .

通过/login在GCE控制台中手动更改探测路径,可以解决此问题.

引自这里:

GLBC要求您在Pod规范中定义端口(在您的情况下为3000).

ports除了添加自定义之外,解决方案是声明用于运行状况检查的端口readinessProbe:

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

随着GLBC插件

您的问题并不十分清楚,但如果您正在使用GCE Load-Balancer Controller (GLBC) Cluster Addon,则可以自定义运行状况检查路径.

目前,所有服务后端必须满足以下任一要求才能传递从GCE负载均衡器发送给它的HTTP(S)运行状况检查:

有回应200的'/'.内容无关紧要.

在支持服务的pod上公开任意URL作为准备探测.

Ingress控制器首先查找兼容的就绪探测,如果找到,则将其作为GCE负载均衡器的HTTP(S)运行状况检查.如果没有就绪探测器,或者就绪探测器需要特殊的HTTP头,则Ingress控制器将GCE负载均衡器的HTTP运行状况检查指向"/".这是一个 Ingress 的示例,它采用来自端点的就绪探测作为其健康检查.

GLBC插件页面在" 限制"部分中提到了这一点:

所有Kubernetes服务必须提供200页面'/',或者您通过GLBC的--health-check-path 论点指定的任何自定义值.

没有GLBC插件

如果您没有使用插件,目前Kubernetes确实要求您为成功运行状况检查的路径上的请求提供服务200,否则后端将不会获得任何流量.GET/

在这个bug中有一些关于这个的背景知识.

Google容器引擎(GKE)

如果您使用的是Google容器引擎(GKE),那么健康检查的默认Kubernetes要求也适用于此.

通过Ingress公开的服务必须提供对路径HTTP 200上的GET请求具有状态的响应/.这用于健康检查.如果您的应用程序不服务HTTP 200上/,后端将被标记为不健康的,将无法获得流量.

说完所有这些,正如你(@mmoya)在你的答案中指出的那样,将用于准备探测的相同端口添加为pod中的一个端口可以解决你的情况问题,因为端口本身没有暴露在外面否则就是吊舱.这导致Kubernetes依赖于健康检查/.